Комментарии 181
Очень интересная статья, спасибо.
Не думал что на таких высоконагруженных серверах используются серверные Windows :)
Не думал что на таких высоконагруженных серверах используются серверные Windows :)
Особенно не думалось что используется связка Win + Apache
Под Win работает только MSSQL сервера, Apache Tomcat — под Linux
Очень странная связка.
Обычно я слышу про MySQL+php, Oracle+java, MSSQL+ASP.NET
Но в чем эффективность такого решения? Я понимаю, что «так исторически сложилось», но все-таки разработчики, которые первыми продумывали архитектурные решения, чем-то мотивировали свой выбор?
Обычно я слышу про MySQL+php, Oracle+java, MSSQL+ASP.NET
Но в чем эффективность такого решения? Я понимаю, что «так исторически сложилось», но все-таки разработчики, которые первыми продумывали архитектурные решения, чем-то мотивировали свой выбор?
очень интересные цифры, вызывает уважение, несмотря на то, что одноклассниками не особо пользуюсь, я не из таргет группы, но красиво — 150К запросов в секунду.
правда интересно, ничего не имею против MS SQL, но как то в энтерпрайз джава мире принято использовать всякие oracle\sybase (не будет помянут всуе). интересно, были ли какие то проблемы специфические для MS SQL, просто любопытно, каковы впечатления?
и еще очень интересно — а кэши ваши самописные, неужто никакие стандартные решения не подошли типа coherence\ehcache\hibernate? или просто сложилось исторически?
правда интересно, ничего не имею против MS SQL, но как то в энтерпрайз джава мире принято использовать всякие oracle\sybase (не будет помянут всуе). интересно, были ли какие то проблемы специфические для MS SQL, просто любопытно, каковы впечатления?
и еще очень интересно — а кэши ваши самописные, неужто никакие стандартные решения не подошли типа coherence\ehcache\hibernate? или просто сложилось исторически?
А почему никто не произности postgresql? Говорят, что ей можно заменить MS SQL и работает опять же везде.
Если используют Java, то думаю все равно под какой системой запускать, JVM отрабатывает одинаково.
SQL операторы DELETE также используются с осторожностью — это самая тяжелая операция из DML. Стараемся не удалять данные лишний раз или используем удаление через маркер — запись сначала отмечается как удаленная, а потом удаляется фоновым процессом из таблицы.
И что, и с аккаунтами пользователей так? Или просто помечаете, как удаленные?
7,5 миллиардов запросов в день (150 000 запросов в секунду в часы пик)
2 400 серверов, систем хранения данных
Сетевой трафик в час пик: 32 Gb/s
После простых рассчетов получаем:
62,5 запроса/сек на сервер в часы пик
13 мб/с на сервер.
А теперь вопрос — вы специально гоняете аппаратуру вхолостую или в этом есть сакральный смысл (т.е. возможен вариант лавинообразного роста)
Или в описания закралась ошибка?
2 400 серверов, систем хранения данных
Сетевой трафик в час пик: 32 Gb/s
После простых рассчетов получаем:
62,5 запроса/сек на сервер в часы пик
13 мб/с на сервер.
А теперь вопрос — вы специально гоняете аппаратуру вхолостую или в этом есть сакральный смысл (т.е. возможен вариант лавинообразного роста)
Или в описания закралась ошибка?
Не все сервера одинаковые, поэтому делить 150 тыс/ на общее число серверов некорректно.
Скажем так «не совсем корректно»
Количество обрабатываемых запросов в секунду, деленное на количество серверов — это скорее не количественная, а качественная характеристика.
Приведу пример — на один сервер «вконтакте» приходится около 500 запросов/сек и до 600 в часы пик.
На один сервер facebook после введения Hip-hop приходится около 800 запросов/сек
Т.е. минимум в 8 раз больше.
Наврядли характер нагрузки этих проектов сильно отличается от характера нагрузки «одноклассников»
Кроме того, эти проекты написаны на php, а о его быстродействии большинству здесь уже известно.
Кроме того, команда «вконтакте» на данный момент — это 40 человек (против 70 у Вас)
В итоге делаем вывод, что или эффективность вашей архитектуры низка сама по себе, или вы специально не позволяете загрузке уходить дальше 15% рубежа.
Количество обрабатываемых запросов в секунду, деленное на количество серверов — это скорее не количественная, а качественная характеристика.
Приведу пример — на один сервер «вконтакте» приходится около 500 запросов/сек и до 600 в часы пик.
На один сервер facebook после введения Hip-hop приходится около 800 запросов/сек
Т.е. минимум в 8 раз больше.
Наврядли характер нагрузки этих проектов сильно отличается от характера нагрузки «одноклассников»
Кроме того, эти проекты написаны на php, а о его быстродействии большинству здесь уже известно.
Кроме того, команда «вконтакте» на данный момент — это 40 человек (против 70 у Вас)
В итоге делаем вывод, что или эффективность вашей архитектуры низка сама по себе, или вы специально не позволяете загрузке уходить дальше 15% рубежа.
В фейсбуке PHP транслируется в С++ код, а затем С++ компилируется. За счёт этого и достигается такая высокая продуктивность кода
Да, но вы же понимаете, что компилируется он в очень высокоуровневый C++-код, который от интерпретатора не так сильно отличается?
Интерпретатор всегда _намного_ медленнее за компилируемый код + в Фейсбуке используют только некоторые из возможностей PHP (источник не помню).
Несколько цитат из: developers.facebook.com/blog/post/358/
>> With HipHop we've reduced the CPU usage on our Web servers on average by about fifty percent, depending on the page
>> PHP is a scripting language with dynamic, weak typing. <...> Whenever possible our generated code uses static binding for functions and variables. We also use type inference to pick the most specific type possible for our variables and thus save memory.
Несколько цитат из: developers.facebook.com/blog/post/358/
>> With HipHop we've reduced the CPU usage on our Web servers on average by about fifty percent, depending on the page
>> PHP is a scripting language with dynamic, weak typing. <...> Whenever possible our generated code uses static binding for functions and variables. We also use type inference to pick the most specific type possible for our variables and thus save memory.
Но тем не менее интерпретатор выполняет код на ходу, а c++ уже готовый бинарный код — разница как минимум должна быть заметна невооруженным глазом.
> Но тем не менее интерпретатор выполняет код на ходу, а c++ уже готовый бинарный код
Готовый бинарный код, который делает все на ходу)
Готовый бинарный код, который делает все на ходу)
Ну вы поняли что я хотел сказать) Только HipHop велосипед еще тот. Только такой монстр как facebook мог себе позволить такой велосипед. На других проектах проще было бы переписать на python/ java/ c++/ etc. и не парится.
В том-то и дело, что не очень. То есть там все очень от реализации зависит. Можно сделать сверхабстракции для универсальных переменных на всех типах, да еще чтоб ошибки вменяемые выдавало, но боюсь, что этот код будет куда медленнее интерпретатора. Так что наверняка прирост в скорости за счет каких-то ограничений, благодаря которым код на плюсах не слишком абстрактный, а не просто за счет компиляции.
что-то мне кажется, что Facebook давно уже все критичные к производительности компоненты переписал на C++
несмотря на все громкие заявления про дополивание PHP, наверняка он по большей части работает как шаблонизатор/компоновщик
несмотря на все громкие заявления про дополивание PHP, наверняка он по большей части работает как шаблонизатор/компоновщик
Под количеством запросов имелись ввиду запросы, приходящие от пользователей к нашим фронтендам (HTTP + AJAX). Фронтендов в данный момент у нас порядка 150
Но кроме фронт-энд серверов у Вас имеется целая инфраструктура, созданная для качественного увеличения показателя запросы/сек? Просто если весь удар приходится только на эти 150 серверов, то смысл держать остальные 2000 машин? просто «на всякий случай»?
Просто я не вижу смысла содержать столь огромный парк серверов для довольно средних показателей, и я хочу узнать — может Вы совершаете еще какие-то операции, о которых не указано в статье?
Просто я не вижу смысла содержать столь огромный парк серверов для довольно средних показателей, и я хочу узнать — может Вы совершаете еще какие-то операции, о которых не указано в статье?
У нас 150 фронтэндов и 150 000 запросов в сек. Т.е. 1000 запросов/сек рендеринга на сервер.
Осталные сервера — базы данных, статистика, кеши, специфические сервисы…
Я думаю у вас нет сомнений, что в выше упомянутых проектах кроме веб серверов с PHP есть и другая инфраструктура.
Осталные сервера — базы данных, статистика, кеши, специфические сервисы…
Я думаю у вас нет сомнений, что в выше упомянутых проектах кроме веб серверов с PHP есть и другая инфраструктура.
Верно, но я выше написал, что даже при инфраструктуре больших размеров «вконтакте» обрабатывает большее количество запросов на сервер, минимум в 8 раз при сходном характере нагрузки.
Кроме того, они также ведут статистику, логгируют действия пользователей, и у них уже давно запущен и работает видеохостинг, который дает нехилую нагрузку.
Наш спор заходит в тупик, и я думаю пора резюмировать:
Ваша стратегия развития состоит не в интенсификации существующих мощностей, а просто в количественном увеличении серверов. Такая стратегия тоже имеет право жить.
Спасибо за статью.
Кроме того, они также ведут статистику, логгируют действия пользователей, и у них уже давно запущен и работает видеохостинг, который дает нехилую нагрузку.
Наш спор заходит в тупик, и я думаю пора резюмировать:
Ваша стратегия развития состоит не в интенсификации существующих мощностей, а просто в количественном увеличении серверов. Такая стратегия тоже имеет право жить.
Спасибо за статью.
Если есть желание сравнить инфраструктуры разных соц. сетей, приводите объективные критерии и желательно цифры основанные на каких-то более менне достоверных источниках.
Например, та информация, которая доступна по facebook и вконтакте мне лично говорит об обратном. Например для facebook фигурировала усреденная оценка количество запросов страниц к колеству севреров в месяц — 7млн. В нашем случае ~ 90 млн. Так же не в пользу вами выше упомянутых проектов отношение пользователей к количеству серверов.
Так что не очень понятно, откуда такие оценки.
Например, та информация, которая доступна по facebook и вконтакте мне лично говорит об обратном. Например для facebook фигурировала усреденная оценка количество запросов страниц к колеству севреров в месяц — 7млн. В нашем случае ~ 90 млн. Так же не в пользу вами выше упомянутых проектов отношение пользователей к количеству серверов.
Так что не очень понятно, откуда такие оценки.
Мы привели показатель количества запросов в нашей статье сознательно как раз для того, чтобы можно было сравнить нагрузку на нашу инфраструктуру, с нагрузкой на других сайтах. На каждый запрос нужно подготовить и отослать ответ. По той информации, которую можно найти в Интернете, количество подобных запросов у Вконтакте — 11 миллиардов в день, у Twitter-а 6 миллиардов запросов в день к API, LinkedIn — 40 миллионов просмотров страниц в день, Facebook — 200 миллиардов просмотров страниц в месяц. Каждый пользовательский запрос на просмотр страницы конечно порождает различное количество запросов внутри инфраструктуры. Количество этих запросов сравнивать нельзя так как оно зависит от пострения платформы. А платформы у разных сайтов разные.
Просто если весь удар приходится только на эти 150 серверов, то смысл держать остальные 2000 машин? просто «на всякий случай»?
Вы оправдываете свой ник
Совершенно с вами согласен. Цифра 2400 сразу бросается в глаза и хочется узнать зачем так много…
Ну, кто-то оптимизирует код, запросы, структуру БД, а кто-то покупает сервера.
Что умеют, то и делают.
Что умеют, то и делают.
вы так говорите, будто смасштабировать нагрузку на две с половиной тыщи машин — это проще, чем оптимизировать код.
покупать сервера межу прочим очень дешевый способ, так что это очень логично.
дешевле не значит лучше. Да и всему есть предел.
А о качестве кода прямо и косвенно говорит:
во-первых, приведенный пример в топике (обычно хвастаются самым лучшим)
и во вторых, откровенно тормозной интерфейс (чему там тормозить-то? но ведь тормозит)
А о качестве кода прямо и косвенно говорит:
во-первых, приведенный пример в топике (обычно хвастаются самым лучшим)
и во вторых, откровенно тормозной интерфейс (чему там тормозить-то? но ведь тормозит)
Слушайте, вы делаете какие-то далекоидущие выводы на основе псевдокода, что не очень-то хорошо характеризирует именно вас. Не нравится Одноклассники и хочется об этом сказать всем, так и напишите, зачем такие сложные логические цепочки: «пример не понятный, но лучше думать что гавно, значит у них весь код гавно, значит там работают идиоты, делают проект гавно и пользуются им идиоты, а я такой в белом»? Кому от таких размышлений станет лучше? И так хабр мусорными комментариями забит.
Зачем придираться к иллюстрации к статье? Для того чтобы передать идею хватило, а как именно эта строка должна выглядеть даже не важно. Было бы это узким местом его бы уже исправили, значит есть приоритеты повыше.
Мне статья нравится, ее написал такой же компьютерщик как и я, не всегда получается хорошо и доходчиво, но ход мысли архитекторов стал понятнее. Выложить информацию о внутренней стороне на профильном сайте правильное решение.
Не знаю что тормозит в интерфейсе, не видел после первой версии, сделайте исследование, выложите на хабр, может вас пригласят на работу.
Зачем придираться к иллюстрации к статье? Для того чтобы передать идею хватило, а как именно эта строка должна выглядеть даже не важно. Было бы это узким местом его бы уже исправили, значит есть приоритеты повыше.
Мне статья нравится, ее написал такой же компьютерщик как и я, не всегда получается хорошо и доходчиво, но ход мысли архитекторов стал понятнее. Выложить информацию о внутренней стороне на профильном сайте правильное решение.
Не знаю что тормозит в интерфейсе, не видел после первой версии, сделайте исследование, выложите на хабр, может вас пригласят на работу.
А Ваш комментарий не «мусорный»? не думали его в виде личного сообщения отправить?
Теперь по теме:
Приведенный код не говорит об «узком месте», он говорит о подходе — когда исключения скрываются и вызывающий код ничего не знает о результате вызова.
Далее: я обеими руками «за» увеличение производительности системы любыми доступными способами, в том числе и за счет увеличения количества однотипных серверов.
В какой-то момент времени увеличение производительности системы (за счет оптимизации кода) даже на 1% — даст высвобождение десятков серверов.
А уже обсосанное здесь со всех сторон число запросов на 1 сервер дает нам понять что либо сервера не нагружены (а это не рентабельно, а значит маловероятно), либо код далеко не оптимален.
Теперь по теме:
Приведенный код не говорит об «узком месте», он говорит о подходе — когда исключения скрываются и вызывающий код ничего не знает о результате вызова.
Далее: я обеими руками «за» увеличение производительности системы любыми доступными способами, в том числе и за счет увеличения количества однотипных серверов.
В какой-то момент времени увеличение производительности системы (за счет оптимизации кода) даже на 1% — даст высвобождение десятков серверов.
А уже обсосанное здесь со всех сторон число запросов на 1 сервер дает нам понять что либо сервера не нагружены (а это не рентабельно, а значит маловероятно), либо код далеко не оптимален.
А зачем оптимизировать на 1%, если это требует работы программистов? Сравните стоимость оптимизации и цену на сервера. Сравните с тем, что если бы код оптимизировался на 3 месяца дольше, то новая фунциональность появилась бы на 3 месяца позже. Например если бы платные приложения появились позже, то за эти месяцы компания не получила бы прибыль, а программисты кушать таки просили. Вот и получится цена оптимизации.
Еще раз, стоимость железа — это самая маленькая часть проекта, обычно до 10% в IT компаниях, если больше то уже вызывает вопросы.
Еще раз, стоимость железа — это самая маленькая часть проекта, обычно до 10% в IT компаниях, если больше то уже вызывает вопросы.
Возмем 1% от 2400 сферических серверов в вакууме. Получим 24.
24 даже самых дешевых сервера это сколько программисто-месяцев? Так что целесообразность даже в этом случае есть.
На счет недополучения прибыли Вы не совсем правы. Процесс оптимизации может идти параллельно разработке; он может проводится (а в некоторых случаях должен) проводиться неким третьим лицом. Чтобы был так сказать «взгляд со стороны» на проблему.
откуда цифра 10%? имхо это больше относится к компаниям разрабатывающим софт, а не оказывающим услугу. Или у хостеров тоже до 10%?
24 даже самых дешевых сервера это сколько программисто-месяцев? Так что целесообразность даже в этом случае есть.
На счет недополучения прибыли Вы не совсем правы. Процесс оптимизации может идти параллельно разработке; он может проводится (а в некоторых случаях должен) проводиться неким третьим лицом. Чтобы был так сказать «взгляд со стороны» на проблему.
откуда цифра 10%? имхо это больше относится к компаниям разрабатывающим софт, а не оказывающим услугу. Или у хостеров тоже до 10%?
Вы готовы предоставить точные цифры для подтверждения своих слов, или просто потелепать языком хотите? Если первое, то начните с этого, а если не в теме, то лучше не телепать языком зря. Я думаю в одноклассниках подумали над оптимизацией, прикинули что выгодней, а не сломя голову побежали покупать сервера.
ключевой слово и у Вас и у меня: «я думаю».
про 10% Вы так и не ответили.
про 10% Вы так и не ответили.
Дешево, конечно, но правило «больше связей, выше вероятность отказа» до сих пор работает.
А если еще вспомнить про первый закон Мерфи, то 502 ошибка может стать нередким явлением по вечерам.
А если еще вспомнить про первый закон Мерфи, то 502 ошибка может стать нередким явлением по вечерам.
Весь ваш организм это большое количество связей, но он был изначально так спроектирован и продолжает работать. Если архитектура построена с нацелом на связи то она может так работать долго и успешно. Мне как раз больше не понравилась иерархия типов серверов, 25 разных видов — это наверное ад для администрирования и выстраивания взаимодействий, похоже людям как раз за это и платят деньги.
Архитектура в которой можно для увеличения производительности воткнуть еще пару сотен серверов самая правильная. Законы Мерфи цитировать в треде об архитектуре, уж простите, но моветон.
Архитектура в которой можно для увеличения производительности воткнуть еще пару сотен серверов самая правильная. Законы Мерфи цитировать в треде об архитектуре, уж простите, но моветон.
В вопросах построения архитектуры я тоже руководствуюсь принципом «чем проще, тем дольше проработает»
Мощный оффтоп:
Человеческий организм — очень хрупкая система, отличающаяся от компьютерных систем возможностью полной регенерации органов и тем, что если вдруг отказывает один орган, остальные не смогут выполнять его функции. Кроме того, есть такая штука как иммунитет, отвергающая чужеродные объекты. Также у человека очень ограниченные рамки генетических изменений — скажем, у народов крайнего севера не вырастает шерсть, потому что они живут в холоде.
Все это — плата за сложность и за то, что каждая часть выполняет только свою узкую функцию.
Топология связей человеческого тела — это сильноветвящееся дерево, где опорными узлами являются спинной и головной мозг.
Кроме этого абсолютно все операции приходится проводить на продакшене, и никакой версионности.
Поэтому, как организм, человек совершенен, но как компьютерная система он ужасен.
Мощный оффтоп:
Человеческий организм — очень хрупкая система, отличающаяся от компьютерных систем возможностью полной регенерации органов и тем, что если вдруг отказывает один орган, остальные не смогут выполнять его функции. Кроме того, есть такая штука как иммунитет, отвергающая чужеродные объекты. Также у человека очень ограниченные рамки генетических изменений — скажем, у народов крайнего севера не вырастает шерсть, потому что они живут в холоде.
Все это — плата за сложность и за то, что каждая часть выполняет только свою узкую функцию.
Топология связей человеческого тела — это сильноветвящееся дерево, где опорными узлами являются спинной и головной мозг.
Кроме этого абсолютно все операции приходится проводить на продакшене, и никакой версионности.
Поэтому, как организм, человек совершенен, но как компьютерная система он ужасен.
способ дешевле (в перспективе) — сделать всё по уму и сокращать количество железа :)
Это только запросы со стороны конечного пользователя. Сереверов много для обеспечения работы разных сервисов/компонентов. Если интересны данные по запросам по всем серверам, то такое тоже есть — Прошелся по серверам EJB/Cache/SQL/BDB/WEB/Remote Service/Components и получилос 5'026'666 запросов/сек в час пик. На сервер получается ~2000 запросов/сек в час пик.
Серверов много, так что данные примерные. Есть опасения, что что-то мог упустить.
Так-же и разброс на количеству запросов на тип сервера тоже большой. К примеру на граф приходится ~16K запросов.
Серверов много, так что данные примерные. Есть опасения, что что-то мог упустить.
Так-же и разброс на количеству запросов на тип сервера тоже большой. К примеру на граф приходится ~16K запросов.
Т.е. количество внутренних запросов в десятки раз больше (а именно примерно в 30 раз)?
Таким образом в среднем необходимо выполнить 30 запросов к разным серверам для выдачи одного рендера?
Вы считаете это приемлемым?
Меня бы за такое сначала капитально вздрючили, а потом повесили мою фотку над кофеваркой с подписью «Этот человек — основная причина скоропостижной смерти серверов».
Таким образом в среднем необходимо выполнить 30 запросов к разным серверам для выдачи одного рендера?
Вы считаете это приемлемым?
Меня бы за такое сначала капитально вздрючили, а потом повесили мою фотку над кофеваркой с подписью «Этот человек — основная причина скоропостижной смерти серверов».
Какое кол-во запросов на один физический сервер будет нормальным при нашем объме информации и какаю будет конфигурация данного сервера?
Удовлетворительное значение — не более 15 запросов ( в среднем ).
При этом точность попадания в кеш должна быть не ниже 60%
Вероятность использования данных, генерированных заранее, но не попавших в кеш из-за относительно редкого использования не менее 20%, все остальное может генерироваться.
Первый уровень — ngnix с агрессивной системой кеширования, второй уровень — база данных + memcache, третий уровень — это сервера — сборщики, получающие данные с максимального количества источников параллельно.
В этом плане к идеалу максимально приблизился facebook
Подчерпнуть сжатую информацию об его архитектуре можно в заметке www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/
При этом точность попадания в кеш должна быть не ниже 60%
Вероятность использования данных, генерированных заранее, но не попавших в кеш из-за относительно редкого использования не менее 20%, все остальное может генерироваться.
Первый уровень — ngnix с агрессивной системой кеширования, второй уровень — база данных + memcache, третий уровень — это сервера — сборщики, получающие данные с максимального количества источников параллельно.
В этом плане к идеалу максимально приблизился facebook
Подчерпнуть сжатую информацию об его архитектуре можно в заметке www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/
А кто сказал, что у нас запросы выполняются последовательно? Если действительно есть необходимость и есть возможность, то запросы идут параллельно. Так что я бы не утверждал, что на пользовательский запрос требуется 30 последовательных запросов по внутренней инфраструктуре.
Данные естественно кешируются — от экранных портлетов до конкретных сущностей. Попадание в кеш >75%. К примеру кластер кеша метаинформации по фотографии работает 130000/5833 запросов/сек. (где 5833 запроса в базу за недостающими данными).
Данные естественно кешируются — от экранных портлетов до конкретных сущностей. Попадание в кеш >75%. К примеру кластер кеша метаинформации по фотографии работает 130000/5833 запросов/сек. (где 5833 запроса в базу за недостающими данными).
Запросы принимают несколько серверов, которые смотрят наружу.
Абсолютные цифры смотрятся внушительно, наверное на это и был расчет. А как дело в сравнении с другими? Чем ваш подход, ваша система лучше/быстрее/надежнее/… чем..., ну скажем так другие системы?
Вопрос не совсем технический, больше политический. Что происходит с удалёнными учётными записями после их удаления?
Странный пример кода. Как код, вызывающий функцию sendMessage(String message) узнает об успехе/неудаче при отправке сообщения?
1. факапы часто бывают? ;)
2. про тестирование не написали. оно есть?
2. про тестирование не написали. оно есть?
Месяц назад пытался зарегистрироваться, СМС так и не пришла. Раз 5 пытался запросить сообщение повторно, но его так и нет до сих пор. Оператор Билайн.
Заинтересовал ваш фреймворк:
«Используем свой фреймворк, позволяющий строить композицию страниц на языке JAVA, используя собственные GUI фабрики (оформление текста, списки, таблицы, портлеты).»
Он когда-нибудь появится в open source?
Если слишком наглый вопрос, простите =)
«Используем свой фреймворк, позволяющий строить композицию страниц на языке JAVA, используя собственные GUI фабрики (оформление текста, списки, таблицы, портлеты).»
Он когда-нибудь появится в open source?
Если слишком наглый вопрос, простите =)
риторический вопрос: когда у вас будет всё нормально и стабильно работать? )
зачем?
Даже на быстрых соединениях сайт тормозит. Пробывал с разных браузерах.
Подробнее, что именно тормозит? Загрузка страницы, переход по внутренним страницам, отправка сообщений или комментариев...?
НЛО прилетело и опубликовало эту надпись здесь
сообщения, переход по страницам, просмотр фотографий…
Не знаю как сейчас, но когда у меня стоял 1.6 GHz Athlon 1GB ОЗУ, то открытие страницы вешалось на несколько секунд джавакскриптом. Я люблю открывать несколько вкладок одного сайта, но такой функционал я не мог выносить…
Поэтому я купил себе новый комп )))
Поэтому я купил себе новый комп )))
Пожелние организационное: многие знакомые периодически теряют аккаунты, пусть даже они сами пароли забывали, это не проблема, проблема в том что процедура восстановления пароля не срабатывала, сам несколько раз пробывал, в смс приходит проверочный код из 3 цифр, а нужно ввести 4.
Возможно этот пост не к месту, извиняюсь… мне как бы уже все равно, с момента попытки восстановить пароль уже прошло слишком много времени, может кому другому это поможет. (Писал в письма даже в поддержку корпорации, но там накормили завтраками и забили.)
Возможно этот пост не к месту, извиняюсь… мне как бы уже все равно, с момента попытки восстановить пароль уже прошло слишком много времени, может кому другому это поможет. (Писал в письма даже в поддержку корпорации, но там накормили завтраками и забили.)
Масштабно!
А для организации очередей что используете?
бабушек
Пропускаем очередь через Berkeley DB — QUEUE. Далее есть кластер java серверов для обработки заданий. На каждом из этих java серверов запущено N потоков. Каждый поток обрабатывает свою партицию из очереди.
Спасибо за ответ, а про раздачу статики можете поподробней рассказать? Судя по заголовкам используется Resin — в чем его приемущества перед тем же nginx?
А как добиваетесь отказоустойчивости очереди Berkeley DB?
Каковы требования по надежности, насколько плохо потерять задание, которое попало в очередь? Потерять в результате фэйла железяки/ОС и т.д.
Каковы требования по надежности, насколько плохо потерять задание, которое попало в очередь? Потерять в результате фэйла железяки/ОС и т.д.
Для надежности данных используется родная Berkeley DB master-slave репликация базы. Особых проблем с QUEUE базой не наблюдалось.
Если задание попало в очередь, то потерять данные будет уже сложно (пока не теряли). Пишутся логи на диск и постоянно идет реплика на другой сервер. Надежность на 100% не ожидаем (специфика сервиса работающего с данной очередью).
В худшем случае при «hardware fail» на мастер сервере потеря составит <1 минуты работы сервиса. При этом значительного эффекта на систему не ожидаем. Сама система переходит в синхронный режим работы, пока проблемы с очередью не будут решены.
В случае же транзакций по платным сервисам ожидаем 0% потери данных. Тут уже процесс реализован на основе MS SQL.
Если задание попало в очередь, то потерять данные будет уже сложно (пока не теряли). Пишутся логи на диск и постоянно идет реплика на другой сервер. Надежность на 100% не ожидаем (специфика сервиса работающего с данной очередью).
В худшем случае при «hardware fail» на мастер сервере потеря составит <1 минуты работы сервиса. При этом значительного эффекта на систему не ожидаем. Сама система переходит в синхронный режим работы, пока проблемы с очередью не будут решены.
В случае же транзакций по платным сервисам ожидаем 0% потери данных. Тут уже процесс реализован на основе MS SQL.
Опишите, пожалуйста, более подробно, как вы добиваетесь посредством MS SQL 100% сохранение данных и высокой доступности одновременно! Это жутко интересно. Репликация данных осуществляется за счет приложения или стандарных инструментов MS SQL? Синхронно или асинхронно? В общем, чем больше подробностей, тем круче.
И да, спасибо за статью!
И да, спасибо за статью!
Скучновато немного — добавить бы пару графиков, диаграмм соединений серверов например, было бы значительно интереснее. Так получилось интересным только глубоко техническим специалистам.
Но все равно спасибо
Но все равно спасибо
Интересная статья. Спасибо.
А можно узнать, что примерно хранится в MS SQL а что в BerkleyDB? На первом, я так понимаю, статистика и отчеты бегают.
public void sendMessage(String message) {
long startTime = LoggerUtil.getMeasureStartTime();
try {
/**
* business logic - send message
*/
LoggerUtil.operationSuccess(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
} catch (Exception e) {
LoggerUtil.operationFailure(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
}
}вот молодцы, как константы хорошо пределяют. Кстати, в чем крутость этого кода?
это, видимо, лучшая часть кода была :)
Никакой крутости. Все как раз очень просто. Этот код привели как пример того, как просто мы сохраняем статистику по времени выполнения операции, ее успешном (или неуспешном) завершении.
убогое решение:
1. Dы глотаете исключения — никто и никогда не узнает в чем же была ошибка.
2. название LoggerUtil никак не ассоциируется с сбором статистики
поддерживать и не дай бог делать рефакторинг для этого кода крайне не удобно, более удобныеб гибки
1. Dы глотаете исключения — никто и никогда не узнает в чем же была ошибка.
2. название LoggerUtil никак не ассоциируется с сбором статистики
поддерживать и не дай бог делать рефакторинг для этого кода крайне не удобно, более удобныеб гибки
сори, случайно запостился недописаный комент
должно быть так
убогое решение:
1. Вы глотаете исключения — никто и никогда не узнает в чем же была ошибка.
2. название LoggerUtil никак не ассоциируется с сбором статистики
3. Поддерживать и не дай бог делать рефакторинг для этого кода крайне не удобно
4. Более удобные и гибкие решения уже написаны до вас, поэтому мне кажется, что вы изобрели тругольное колесо
должно быть так
убогое решение:
1. Вы глотаете исключения — никто и никогда не узнает в чем же была ошибка.
2. название LoggerUtil никак не ассоциируется с сбором статистики
3. Поддерживать и не дай бог делать рефакторинг для этого кода крайне не удобно
4. Более удобные и гибкие решения уже написаны до вас, поэтому мне кажется, что вы изобрели тругольное колесо
Категоричное суждение. Возможно вы слишком буквально восприняли наш пример.
Конечно же это не готовый кусок кода. Там например нет объявления класса, импорта необходимых пакетов и т.п.
LoggerUtil — это наш внутренний класс, которому просто надо передать что сохранить, а он сам знает куда сохранить и как это сделать.
Я абсолютно согласен с вами что удобные и гибкие решения для логирования написаны до нас. Как написано в статье, мы как раз используем одно из них: библиотеку log4j (http://logging.apache.org/log4j/ или www.log4j.ru/)
Конечно же это не готовый кусок кода. Там например нет объявления класса, импорта необходимых пакетов и т.п.
LoggerUtil — это наш внутренний класс, которому просто надо передать что сохранить, а он сам знает куда сохранить и как это сделать.
Я абсолютно согласен с вами что удобные и гибкие решения для логирования написаны до нас. Как написано в статье, мы как раз используем одно из них: библиотеку log4j (http://logging.apache.org/log4j/ или www.log4j.ru/)
А еще тут нет названия класса, не указан java packaga и непонятные Log* классы, которые не описаны в приведенном коде.
Это ведь просто пример, что для сбора статистики просто делаем 1,2,3.
Это ведь просто пример, что для сбора статистики просто делаем 1,2,3.
Логирование выглядит странно. Очень экстенсивно я бы сказал. Наверное применение AOP было бы здесь в самый раз. Да и наружу ошибка у вас не выдается.
> В разработке новое решение для хранения данных. Нам необходим еще более быстрый и надежный доступ к данным.
А не поделитесь, какое?
А не поделитесь, какое?
Не могли бы Вы пояснить одну странную штуку?
Вроде как все популярные интернет-проекты стараются по максимуму использовать геолокацию.
В правилах же Одноклассников есть такая штука, как Принципы рассмотрения приложений, где один из пунктов гласит:
Вроде как все популярные интернет-проекты стараются по максимуму использовать геолокацию.
В правилах же Одноклассников есть такая штука, как Принципы рассмотрения приложений, где один из пунктов гласит:
Geo-location services — Не принимаемЭто пережиток прошлого или какая-то своя политика?
чето какая то сборная солянка: java c++ mssql bercleydb windows linux + куча своих костылей наработок, для полноты не хватает серверов на разных архитектура, *bsd, php, nosql уж в кучу… не знаю как сейчас у вас, но раньше было просто мега тормознуто
Исходники выложите?
public void sendMessage(String message) {
long startTime = LoggerUtil.getMeasureStartTime();
try {
/**
* business logic - send message
*/
LoggerUtil.operationSuccess(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
} catch (Exception e) {
LoggerUtil.operationFailure(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
}
}Уже выложили :D
Ни одной картинки :(
Коли о слоях говорите приложили бы что-нибудь для более быстрого понятия. Тем более в таком случае куда интересней сетевая взаимосвязь между слоями.
Коли о слоях говорите приложили бы что-нибудь для более быстрого понятия. Тем более в таком случае куда интересней сетевая взаимосвязь между слоями.
Теперь понимаю почему в одноклассниках все тормозит и очень долго открывается.
На дешевых тарифах в инет(до мегабита) даже зайти сложно.
На дешевых тарифах в инет(до мегабита) даже зайти сложно.
Описание красивое. Выглядит так, что описание Бурана или Шаттла какого-нибудь блекнет. Кажется, что это вершина ИТ и того, что с ней может сделать человек.
По факту: самый неудобный, ужасно спроектированный, медленный, постоянно неработающий сайт, который я когда-либо видел в интернете за 15 лет. Первые годы это был вообще леденящий душу п-ц. И до сих пор им страшно пользоваться.
Столь нелюбимый здесь ВКонтактик просто образец удобства, скорости и надежности по сравнению с Одноклассниками. А уж непомерная жадность метко прозванных Жадноклассников и общее самодурство системы — это уже притча во языцех. Ну да ладно, оставим это на совести эффективных бизнесменов.
Прошу вас, сделайте просто нормальный, удобный и быстрый сайт.
Простите, конечно, если обидел.
По факту: самый неудобный, ужасно спроектированный, медленный, постоянно неработающий сайт, который я когда-либо видел в интернете за 15 лет. Первые годы это был вообще леденящий душу п-ц. И до сих пор им страшно пользоваться.
Столь нелюбимый здесь ВКонтактик просто образец удобства, скорости и надежности по сравнению с Одноклассниками. А уж непомерная жадность метко прозванных Жадноклассников и общее самодурство системы — это уже притча во языцех. Ну да ладно, оставим это на совести эффективных бизнесменов.
Прошу вас, сделайте просто нормальный, удобный и быстрый сайт.
Простите, конечно, если обидел.
индусы нервно курят в сторонке…
Знакомая помогала мужу с регистрацией в одноклассниках и по глупости указала email своего аккаунта. Регистрация прошла успешно, а вот доступ к своему аккаунту оказался потерян. Техподдержка просто ничего не ответила.
А что одноклассники еще не загнулись? :3
А почему вы не используете JSF 2.0 вместо GWT и настоящую кластерную СУБД с распределением нагрузки, а не жалкое её подобие MS SQL Server?
Место упомянутого Вами JSF у нас занимает тот самый фреймворк, генерирующий UI компоненты HTML.
GWT же придаёт динамику на странице, а также на нём реализована функциональность Сообщений, Обсуждений и Оповещений.
GWT же придаёт динамику на странице, а также на нём реализована функциональность Сообщений, Обсуждений и Оповещений.
>Место упомянутого Вами JSF у нас занимает тот самый фреймворк, генерирующий UI компоненты HTML.
Это я понял. Но я спросил: «почему?».
Ответ, видимо, будет в духе:
1) остановились на этом фреймворке, потому что это модно;
2) традиционно игнорируем стандартные фреймворки Java входящие в JavaEE;
3) команде разработчиков лень переучиваться и осваивать что-то новое, она занимается обслуживанием того, что уже сделано.
Да и про СУБД хотелось бы услышать ответ на вопрос: почему не используются нормальные кластерные решения с прозрачным распределением нагрузки на несколько серверов.
Это я понял. Но я спросил: «почему?».
Ответ, видимо, будет в духе:
1) остановились на этом фреймворке, потому что это модно;
2) традиционно игнорируем стандартные фреймворки Java входящие в JavaEE;
3) команде разработчиков лень переучиваться и осваивать что-то новое, она занимается обслуживанием того, что уже сделано.
Да и про СУБД хотелось бы услышать ответ на вопрос: почему не используются нормальные кластерные решения с прозрачным распределением нагрузки на несколько серверов.
>почему не используются нормальные кластерные решения с прозрачным распределением нагрузки на несколько серверов.
Разве такие решение существуют? А можно ссылочку?
Разве такие решение существуют? А можно ссылочку?
Пример: PGCluster – синхронизирующаяся репликационная система с мультимастерной композиционной схемой для PostgreSQL.
Можно пожалуйста пример продукта работающий на данном решении? Желательно с дополнительной информацией: сколько машин в кластере, какая нагрузка на одну машину, объем данных.
www.opennet.ru/openforum/vsluhforumID13/337.html#5
Сообщение от Синн on 11-Май-07, 09:06
что могу сказать
столкнулись с той же проблемой. Нагрузка на базу при начальных условиях была около 3,000,000 транзакций в день.
Поняли сразу что без кластера и loadbalance'ра не обойтись
Тестировались PGCluster и slony.
Первый был очень удобен, синхронизировал всё сам вплоть до создания таблиц и сам же делал балансировку, но как только уронили кластер с 16 млн. записей, система не встала. Минус был в том, что на кластер пришлось затратить, 2 дата ноды, 2 репликатора, 2 failover балансировщика на carp инхерфейсах.
Сейчас тестируется slony, нагрузка таже. база уже 38 млн. записей. ронялась 2 раза, 1 раз система встала колом на 1 день, мастер обогнал слэйва на 10 млн. записей, после устранения проблемы на слэйве, система заработала на полную через 30 минут. при этом всё транзакции продолжали фиксироваться. Минус как известно в конфигурировании.
сейчас закупаем оборудование для построения кластера уже на ксеонах.
Вывод: Мы выбрали слона, как более устойчивую систему от сбоев. Удобство администрирования было отодвинуто на последнее место.
Сообщение от Синн on 11-Май-07, 09:06
что могу сказать
столкнулись с той же проблемой. Нагрузка на базу при начальных условиях была около 3,000,000 транзакций в день.
Поняли сразу что без кластера и loadbalance'ра не обойтись
Тестировались PGCluster и slony.
Первый был очень удобен, синхронизировал всё сам вплоть до создания таблиц и сам же делал балансировку, но как только уронили кластер с 16 млн. записей, система не встала. Минус был в том, что на кластер пришлось затратить, 2 дата ноды, 2 репликатора, 2 failover балансировщика на carp инхерфейсах.
Сейчас тестируется slony, нагрузка таже. база уже 38 млн. записей. ронялась 2 раза, 1 раз система встала колом на 1 день, мастер обогнал слэйва на 10 млн. записей, после устранения проблемы на слэйве, система заработала на полную через 30 минут. при этом всё транзакции продолжали фиксироваться. Минус как известно в конфигурировании.
сейчас закупаем оборудование для построения кластера уже на ксеонах.
Вывод: Мы выбрали слона, как более устойчивую систему от сбоев. Удобство администрирования было отодвинуто на последнее место.
Слоны — это не кластер, используем его на работе. Это ассинхронная мастер-слейв репликация. PGCluster — сплошной гемор, это ясно. А у ребят из одноклассников полноценный кластер БД. Так что ничего удивительного.
Как это не кластер? Тогда какую роль выполняет Load Balancer по-вашему?
>А у ребят из одноклассников полноценный кластер БД.
Ну, да. Один MS SQL Server работает, другой на подхвате, если первый грохнется. :))
>А у ребят из одноклассников полноценный кластер БД.
Ну, да. Один MS SQL Server работает, другой на подхвате, если первый грохнется. :))
Насчет MS SQL, вот цитирую:
>вертикальное и горизонтальное партиционирование данных как в базах данных
Работая со Slony slav-ы будут немного отставать от мастера. У них же все синхронно за счет выбора реплики на клиенте. Да и на сколько я понимаю, со Slony можно писать только в master. А читать с реплик и то немного устаревшие данные. Недокластер какой-то.
>вертикальное и горизонтальное партиционирование данных как в базах данных
Работая со Slony slav-ы будут немного отставать от мастера. У них же все синхронно за счет выбора реплики на клиенте. Да и на сколько я понимаю, со Slony можно писать только в master. А читать с реплик и то немного устаревшие данные. Недокластер какой-то.
>жалкое её подобие MS SQL Server
Ойой, а вот и гуру по базам данных подтянулись :D
Посмеши нас
Ойой, а вот и гуру по базам данных подтянулись :D
Посмеши нас
google chrome под macOS
при открытии своей страничке не возможно попасть в сообщения. Это бывает часто в вечерние часы. Возможно это баг Хрома. Возможно ява скрипт подвисает. Но по клику не возможно загрузить сообщения и др. кнопки вверху не работают. Но если открыть в новой вкладке, то все ок.
при открытии своей страничке не возможно попасть в сообщения. Это бывает часто в вечерние часы. Возможно это баг Хрома. Возможно ява скрипт подвисает. Но по клику не возможно загрузить сообщения и др. кнопки вверху не работают. Но если открыть в новой вкладке, то все ок.
Отличная статья. Переведите на инглиш и обязательно отправьте на highscalability.com/
Мне интересно используется ли long polling или вебсокеты? Или асинхронные запросы пингуют сервера?
А как интересно предпродакшн организован? Я имею ввиду откуда берется аудитория для предпрода?
когда можно будет ожидать поддержку IE9? и JumpList например?
Если можно, прокомментируйте подробнее эту строчку: «Встроенный в СУБД аппарат партиционирования не используется — вся логика располагается на уровне бизнес сервисов.» Какие минусы партицирования на уровне СУБД?
Также хочется понять почему вы не используете хранимые процедуры? Каким образом прямые запросы в БД уменьшают нагрузку на CPU?
Также хочется понять почему вы не используете хранимые процедуры? Каким образом прямые запросы в БД уменьшают нагрузку на CPU?
В системах с такой нагрузкой как у одноклассников обычно самым узким местом являются БД. Вы либо упираетесть в CPU либо в диск. Причем БД масштабируются хуже всего.
Поэтому мы стараемся снять нагрузку с базы данных как можно больше. Для снятия нагрузки на диск при чтении используются кеши. Для снятия нагрузки на CPU мы стараемся не использовать хранимые процедуры и сложные запросы.
Уровень бизнес логики масштабируется намного проще, поэтому часть логики переносится туда.
По поводу встроенных механизмов в СУБД. Кластерные решения СУБД не способны масштабироваться до такого предела и очень дороги. Большинство высоконагруженных систем используют горизонтальное и вертикальное масштабирование на уровне бизнес логики.
Поэтому мы стараемся снять нагрузку с базы данных как можно больше. Для снятия нагрузки на диск при чтении используются кеши. Для снятия нагрузки на CPU мы стараемся не использовать хранимые процедуры и сложные запросы.
Уровень бизнес логики масштабируется намного проще, поэтому часть логики переносится туда.
По поводу встроенных механизмов в СУБД. Кластерные решения СУБД не способны масштабироваться до такого предела и очень дороги. Большинство высоконагруженных систем используют горизонтальное и вертикальное масштабирование на уровне бизнес логики.
Я конечно не эксперт в javascript, но с этой кухней немного знаком. Вот если честно, что происходит в момент, когда введены данные для входа на сайт и нажата кнопка Войти? Фаерфокс виснет намертво на 1-2 секунды. Может вам нужно подыскать джаваскриптера с прямыми руками? :)
Спасибо, что приоткрыли завесу тайны :)
А почему в Одноклассниках не используют нагрузочное тестирование? Тогда бы и выкладка была бы спокйонее и жизнь проще.
А почему в Одноклассниках не используют нагрузочное тестирование? Тогда бы и выкладка была бы спокйонее и жизнь проще.
Нагрузочное тестирование есть, но в основном на стадии внедрения каких либо новых технологических решений или при запуске нового сервиса с нестандартными решениями.
Делать синтетическое нагрузочное тестирование при каждом update на всю систему давольно накладно по времени. Своего рода нагрузочное тестирование происходит на тестовой группе серверов с реальными пользователями.
Делать синтетическое нагрузочное тестирование при каждом update на всю систему давольно накладно по времени. Своего рода нагрузочное тестирование происходит на тестовой группе серверов с реальными пользователями.
А по нашим оценкам при должной постановке процесса покрывать регресионными нагрузочными автоматическими тестами большую часть изменяющихся компонентов сервисов в стратегическом плане оказывается очень выгодным. И админам очень нравится :)
Александр, а кто занимается нагрузочным тестированием? Если я правильно понимаю ситуацию, то сами разработчики? А какими инструментами пользуетесь?
Александр, а кто занимается нагрузочным тестированием? Если я правильно понимаю ситуацию, то сами разработчики? А какими инструментами пользуетесь?
Специально выделенных людей нет. Ответственный разработчик за разработку нового продукта занимается нагрузочным тестированием.
Тестируем в основном разного рода «back end» системы. Иногда при тестировании используем JMeter, но
в большинстве случаев это просто консольное java приложение, которое генерит нагрузку на систему.
Первый этап тестирования — это синтетика. Примерно прикидываем предпологаемую нагрузку и запускаем тест. Как показала практика синтетический тест зачастую очень далек от реальности (сложно предугадать в тесте реальное поведение массы людей). Поэтому второй этап нагрузочного тестирования проходит в реальных условиях на реальных пользователях, которые об этом даже не подозревают.
Для примера: при тестировании новой системы хранения данных мы параллельно сохраняли данные в старую и новую систему. При чтении данных сравнивали результат из обоих систем. После устранения всех узких мест и ошибок начинали переход на новую систему хранения данных. Логика написанная для тестрования в конечном итоге использовалась для плавного перехода на новую систему хранения данных.
Тестируем в основном разного рода «back end» системы. Иногда при тестировании используем JMeter, но
в большинстве случаев это просто консольное java приложение, которое генерит нагрузку на систему.
Первый этап тестирования — это синтетика. Примерно прикидываем предпологаемую нагрузку и запускаем тест. Как показала практика синтетический тест зачастую очень далек от реальности (сложно предугадать в тесте реальное поведение массы людей). Поэтому второй этап нагрузочного тестирования проходит в реальных условиях на реальных пользователях, которые об этом даже не подозревают.
Для примера: при тестировании новой системы хранения данных мы параллельно сохраняли данные в старую и новую систему. При чтении данных сравнивали результат из обоих систем. После устранения всех узких мест и ошибок начинали переход на новую систему хранения данных. Логика написанная для тестрования в конечном итоге использовалась для плавного перехода на новую систему хранения данных.
Здравствуйте, а не хотите ли попробовать раздавать статику Одноклассников (CSS/JS и иконки) через CDN? Это может ускорить выдачу, особенно в СНГ и в городах за Уралом. Если интересно — пишите!
Все системы проходят тщательное нагрузочное тестирование. Тестировние проводиться с учетом особенностей эксплуатации и по возможности реальных данных. Во время тестов за системами внимательно наблюдают, все что вызывает подозрения изучается.
Но, даже 3х и более кратная синтетическая нагрузка не всегда выявляет все проблемы, особенно связанные с длительной эксплуатацией. Иногда проблемы возникают в результате незначительных изменений уже работающего функционала. Тогда, если есть возможность то откатываемся, если нет то стараемся чтобы пользователи это не почуствовали.
Но, даже 3х и более кратная синтетическая нагрузка не всегда выявляет все проблемы, особенно связанные с длительной эксплуатацией. Иногда проблемы возникают в результате незначительных изменений уже работающего функционала. Тогда, если есть возможность то откатываемся, если нет то стараемся чтобы пользователи это не почуствовали.
Всё круто, кроме исходного кода страницы.
Рискну начать холивар.
PHP — говно. Java — круто. С точки зрения тру-программистов — однозначно.
НО!
Вконтакте — рулез. Одноклассники — говно. С точки зрения бизнеса — однозначно.
Не говоря про фейсбук.
Вот и говори потом людям, которые хотят все делать на PHP, что Java — это АОП, IoC, Spring, Hibernate, и вообще written once — run anywhere. Ведь Facebook-то на ПХП!
ПХП — это, несомненно, круто, по соотношению цена-качество. Куда лучше чем дотнеты всякие, хотя бы потому, что не привязано к одному производителю.
В общем, надо писать сайты на плюсах.
PHP — говно. Java — круто. С точки зрения тру-программистов — однозначно.
НО!
Вконтакте — рулез. Одноклассники — говно. С точки зрения бизнеса — однозначно.
Не говоря про фейсбук.
Вот и говори потом людям, которые хотят все делать на PHP, что Java — это АОП, IoC, Spring, Hibernate, и вообще written once — run anywhere. Ведь Facebook-то на ПХП!
ПХП — это, несомненно, круто, по соотношению цена-качество. Куда лучше чем дотнеты всякие, хотя бы потому, что не привязано к одному производителю.
В общем, надо писать сайты на плюсах.
Как пользователь Одноклассников, хотя и очень редкий, хочу сказать спасибо за недавноее обновление UI. Месяца 2 назад и ранее — открытие каждой страницы вешало браузер на пару секунд. Поэтому невозможно было открывать сразу несколько вкладок. Но сейчас это исправлено.
Было просто жутко))
Было просто жутко))
Извините, а можно поподробнее рассказать о роли JBoss в данной архитектуре?
Какую роль он выполняет? Что из его внутренностей используется?
Спасибо.
Какую роль он выполняет? Что из его внутренностей используется?
Спасибо.
На практике мы используем очень мало возможностей JBoss: транзакции, пул конекций к ДБ и ремоутинг
JBoss выполняет роль контейнера компонентов бизнес логики. На него поступают бизнес запросы и бизнес операции от фронтендов, которые он и выполняет, запрашивая данные при необходимости от других сервисов — БД, ремотные кеши, другие специализированные сервисы.
На этих компонентах также реализована логика партиционирования данных по серверам MSSQL.
Кроме упомянутого Сашей, еще используются stateless beans, для простых сущьностей используются entity beans с bean managed persistance.
На этих компонентах также реализована логика партиционирования данных по серверам MSSQL.
Кроме упомянутого Сашей, еще используются stateless beans, для простых сущьностей используются entity beans с bean managed persistance.
Нужно было писать на Perl!
Какая версия Zabbix используется? Код стандартный или используются какие то специфичные патчи? Если до то какие? Используется распределенная система мониторинга? Какая БД используется для хранения данных системы мониторинга? Какое количество хостов итемов и триггеров? «Требуемое значение быстродействия сервера»? Конфигурация сервера(ов) мониторинга?
Взяли бы еще хорошего дизайнера интерфейсов в команду…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура и платформа проекта Одноклассники