Нагрузочное тестирование для новых технических решений проводим обязательно. И не только на синтетических тестах, а так же и на реальной нагрузке, включая систему в параллельном режиме.
Одноклассники состоят из примерно 150 подсистем (различные базы данных, серверы бизнес-логики, кэши, графы, фронтэнды, системы конфигурации и т.д.). И работоспособность практически каждой подсистемы зависит от доступности других.
Так 150 подсистем не означает 150 точек отказа всей системы. В идеальной системе все части должны быть не зависимы. В этом случае отказ одной из 150 частей не окажет влияния на остальные и пострадает небольшая часть функционала.
Можно иметь 1 большое хранилище данных и при его отказе из за бага потерять весь сайт, а можно иметь 50 и потерять 1/50.
При этом для обслуживания текущей нагрузки серверов будет примерно столько же, т.е. количество железных точек отказа будет одинаковое.
С другой стороны количество програмных точек отказа скорее связано с объёмом кода, сложностью задач, уровнем квалификации. И скорее всего багов в системе которая разделена на модули будет меньше, чем в одном большом.
В реальности конечно нельзя построить такую идеальную систему, где нет взаимосвязей, но к этому надо стремиться. Одноклассники как раз пытаются сделать так, что бы эффект от програмных и железных отказов был как можно более локализован.
Сервер может взять на обработку несколько роликов. Есть контроль загрузки ядер.
Приблизительно это выглядит так, что сервер может взять не более 4 роликов на обработку при условии, что есть свободные ядра.
Я точно не скажу. Были 2 вида проблем: ffmpeg просто падает и сжирает память или процессор. Обычно это связано с конкретным видео файлом, который сжат или упакован с ошибками.
Ffprobe мы то же используем так как поддерживаем не только MP4 контейнеры. Первичную информацию о файле мы как раз получаем с помощью ffprobe.
MP4Parser используется для тоого, что бы получить и проанализировать специализированные атомы, например GPS координаты с IPhone или Android, тэги Quick Time и т.д.
Странно и не приятно, что на хабре в коментариях столько негатива. Решил посмотреть, что же это за люди, которым Одноклассники (одна из крупнейших соц. сетей) кажется унылым проектом.
Наверно они занимаются очень сложными и интересными вещами. Если просторный чистый светлый удобный офис кажется им скучным и унылым, то наверно они очень интересные люди, которых окружает красота и яркие краски, в том числе на работе.
Исключительно из любопытства посмотрел твиты, страницы в соц. сетях и проекты в интернете, на которые Вы все можете найти ссылки в профиле Хабра.
После этого очень захотелось сказать этим людям «НЕ ЗАВИДУЙТЕ !». Вы еще можете сделать свою жизнь такой же интересной и комфортной как в Одноклассниках.
Евгений, я постараюсь прояснить в чем дело.
1. Вы были одним из первых, кто начал пользоватся OAuth. И в документации явно написано, что это beta версия. Поэтому вполне возможно были проблемы в тот момент.
2. Как вы понимаете, разработчиков не мало, и решение подобных проблем занимает приличное время. Что бы ответить на ваш вопрос «в чем проблема» нам нужно повторить все возможные ошибки при подсчете подписи и найти именно вашу.
3. Мы стараемся по мере возможности быстро реагировать на проблемы. Что бы доказать, я приведу выжимку первой части переписки, которую вы забыли опубликовать:
Evgeny Rumyantsev added a comment - 28/Feb/11 6:10 PM
Возникла проблема с OAuth
................
Edgars Strods added a comment - 28/Feb/11 6:15 PM
redirect_uri, а не redirect_url
Evgeny Rumyantsev added a comment - 28/Feb/11 11:09 PM
У меня возникло несколько вопросов. Мы успешно получаем access_token и refresh_token
.............
Evgeny Rumyantsev added a comment - 28/Feb/11 11:56 PM
Второй вопрос немного поменялся.
.....
Aleksandr Kuznetsov added a comment - 01/Mar/11 4:04 PM
access_token в формировании подписи при вызове метода не участвует. access_token при вызове методов API заменяет session_key
...........
По-моему вам оперативно отчвечали 2 человека. На последний вопрос действительно вам лично не ответили — наша вина.
4. Что касается конкретно вашей проблемы, в документации жирным выделено:
sig = md5( request_params_composed_string+ md5(access_token + application_secret_key) )
Вы же подписываете так:
sig = md5( request_params_composed_string+ md5(application_secret_key) )
Как уже писали ранее: «Работает — не трогай». Не видим смысла.
У нас по старинке: один EAR или WAR на инстанс JBoss'а. Всё выкладывается специальном скриптом, который используется для всех компонентов. Работает отлично.
Наши кеши «интеллектуальные» и содержат в себе специфическую логику например: для уменьшения ненужного трафика, для синхронизации с базой, для более оптимальной чистки устаревших данных и т.д. в зависимости от задачи.
Что каксается coherence — он стоит не малых денег.
В системах с такой нагрузкой как у одноклассников обычно самым узким местом являются БД. Вы либо упираетесть в CPU либо в диск. Причем БД масштабируются хуже всего.
Поэтому мы стараемся снять нагрузку с базы данных как можно больше. Для снятия нагрузки на диск при чтении используются кеши. Для снятия нагрузки на CPU мы стараемся не использовать хранимые процедуры и сложные запросы.
Уровень бизнес логики масштабируется намного проще, поэтому часть логики переносится туда.
По поводу встроенных механизмов в СУБД. Кластерные решения СУБД не способны масштабироваться до такого предела и очень дороги. Большинство высоконагруженных систем используют горизонтальное и вертикальное масштабирование на уровне бизнес логики.
Если есть желание сравнить инфраструктуры разных соц. сетей, приводите объективные критерии и желательно цифры основанные на каких-то более менне достоверных источниках.
Например, та информация, которая доступна по facebook и вконтакте мне лично говорит об обратном. Например для facebook фигурировала усреденная оценка количество запросов страниц к колеству севреров в месяц — 7млн. В нашем случае ~ 90 млн. Так же не в пользу вами выше упомянутых проектов отношение пользователей к количеству серверов.
Так что не очень понятно, откуда такие оценки.
У нас 150 фронтэндов и 150 000 запросов в сек. Т.е. 1000 запросов/сек рендеринга на сервер.
Осталные сервера — базы данных, статистика, кеши, специфические сервисы…
Я думаю у вас нет сомнений, что в выше упомянутых проектах кроме веб серверов с PHP есть и другая инфраструктура.
Так 150 подсистем не означает 150 точек отказа всей системы. В идеальной системе все части должны быть не зависимы. В этом случае отказ одной из 150 частей не окажет влияния на остальные и пострадает небольшая часть функционала.
Можно иметь 1 большое хранилище данных и при его отказе из за бага потерять весь сайт, а можно иметь 50 и потерять 1/50.
При этом для обслуживания текущей нагрузки серверов будет примерно столько же, т.е. количество железных точек отказа будет одинаковое.
С другой стороны количество програмных точек отказа скорее связано с объёмом кода, сложностью задач, уровнем квалификации. И скорее всего багов в системе которая разделена на модули будет меньше, чем в одном большом.
В реальности конечно нельзя построить такую идеальную систему, где нет взаимосвязей, но к этому надо стремиться. Одноклассники как раз пытаются сделать так, что бы эффект от програмных и железных отказов был как можно более локализован.
Приблизительно это выглядит так, что сервер может взять не более 4 роликов на обработку при условии, что есть свободные ядра.
MP4Parser используется для тоого, что бы получить и проанализировать специализированные атомы, например GPS координаты с IPhone или Android, тэги Quick Time и т.д.
Наверно они занимаются очень сложными и интересными вещами. Если просторный чистый светлый удобный офис кажется им скучным и унылым, то наверно они очень интересные люди, которых окружает красота и яркие краски, в том числе на работе.
Исключительно из любопытства посмотрел твиты, страницы в соц. сетях и проекты в интернете, на которые Вы все можете найти ссылки в профиле Хабра.
После этого очень захотелось сказать этим людям «НЕ ЗАВИДУЙТЕ !». Вы еще можете сделать свою жизнь такой же интересной и комфортной как в Одноклассниках.
1. Вы были одним из первых, кто начал пользоватся OAuth. И в документации явно написано, что это beta версия. Поэтому вполне возможно были проблемы в тот момент.
2. Как вы понимаете, разработчиков не мало, и решение подобных проблем занимает приличное время. Что бы ответить на ваш вопрос «в чем проблема» нам нужно повторить все возможные ошибки при подсчете подписи и найти именно вашу.
3. Мы стараемся по мере возможности быстро реагировать на проблемы. Что бы доказать, я приведу выжимку первой части переписки, которую вы забыли опубликовать:
Evgeny Rumyantsev added a comment - 28/Feb/11 6:10 PM
Возникла проблема с OAuth
................
Edgars Strods added a comment - 28/Feb/11 6:15 PM
redirect_uri, а не redirect_url
Evgeny Rumyantsev added a comment - 28/Feb/11 11:09 PM
У меня возникло несколько вопросов. Мы успешно получаем access_token и refresh_token
.............
Evgeny Rumyantsev added a comment - 28/Feb/11 11:56 PM
Второй вопрос немного поменялся.
.....
Aleksandr Kuznetsov added a comment - 01/Mar/11 4:04 PM
access_token в формировании подписи при вызове метода не участвует. access_token при вызове методов API заменяет session_key
...........
По-моему вам оперативно отчвечали 2 человека. На последний вопрос действительно вам лично не ответили — наша вина.
4. Что касается конкретно вашей проблемы, в документации жирным выделено:
sig = md5( request_params_composed_string+ md5(access_token + application_secret_key) )
Вы же подписываете так:
sig = md5( request_params_composed_string+ md5(application_secret_key) )
У нас по старинке: один EAR или WAR на инстанс JBoss'а. Всё выкладывается специальном скриптом, который используется для всех компонентов. Работает отлично.
Что каксается coherence — он стоит не малых денег.
Поэтому мы стараемся снять нагрузку с базы данных как можно больше. Для снятия нагрузки на диск при чтении используются кеши. Для снятия нагрузки на CPU мы стараемся не использовать хранимые процедуры и сложные запросы.
Уровень бизнес логики масштабируется намного проще, поэтому часть логики переносится туда.
По поводу встроенных механизмов в СУБД. Кластерные решения СУБД не способны масштабироваться до такого предела и очень дороги. Большинство высоконагруженных систем используют горизонтальное и вертикальное масштабирование на уровне бизнес логики.
Например, та информация, которая доступна по facebook и вконтакте мне лично говорит об обратном. Например для facebook фигурировала усреденная оценка количество запросов страниц к колеству севреров в месяц — 7млн. В нашем случае ~ 90 млн. Так же не в пользу вами выше упомянутых проектов отношение пользователей к количеству серверов.
Так что не очень понятно, откуда такие оценки.
Осталные сервера — базы данных, статистика, кеши, специфические сервисы…
Я думаю у вас нет сомнений, что в выше упомянутых проектах кроме веб серверов с PHP есть и другая инфраструктура.