Нагрузочное тестирование в Яндексе

Мы не практикуем удаленную работу для разработчиков и тестировщиков. И есть исключения, подтверждающие эти правила :)

Расскажешь причину? Раз есть исключения, которые подтвердили правила - с чем Яндекс столкнулся, что Вы отказываетесь от удаленных работников?

Это не про нагрузочное тестирование в Яндексе :) У нас в компании всегда принято договариваться. Вокруг работают умные и хорошие люди, а два хороших человека всегда смогут договориться.

Интересует тестирования Яндекс Видео, проводилось ли оно ? Если да, то как и чем эммулировалось большое количество видео стримов ?

Любой сервис, который мы запускаем проходит обязательный этап нагрузочного тестирования. Яндекс.Видео тут конечно же не исключение. Грубо говоря Видео — это сами интерфейсы + поиск + хранилище + стримминг. Для тестирования именно стримовой части использовали JMeter — его для этой задачи было более чем достаточно.

А можно подробнее о данном проекте
Как именно определяли максимальную нагрузку? меня интересует именно механизм запроса к видеоконтенту для проигрывания
Также интересует upload и download
Какие примерно ресурсы для этого пришлось использовать?

Как спланировать нагрузку, которая придет на сервис? В данном случае, число одновременных стримов? Вообще вопрос планирования нагрузки — это отдельная колоссальная тема для разговора. В самом общем случаем вместе с командой сервиса планируем характер трафика. Тут очень много разных подходов может быть. Начиная от чуйки и экспертизы заканчивая большими исследованиями рынка.

Какие именно ресурсы? Если про тестовый стенд, то собрали единицу кластера, протестировали её, а дальше масштабировали горизонтально, благо в этом месте с этим всё в общем просто.

Добрый день!

Очень рад был этой теме так как накопилось много вопросов, а задать некому. Итак:

1. Используете ли при анализе результатов мат. статистику? Если да, то что посоветуете почитать на эту тему (имеется в виду не книги по мат. статистики :), а книги по нагрузке где активно используется мат. статистика)
2. Какие книги посоветуете почитать по нагрузке?
3. Какой интервал берете при сборе показателей системы - 1сек, 5сек, etc. Например как часто следует мониторить утилизацию диска. Ведь если брать интервал в 1 сек, то например за 10 часов будет такое кол-во данных что график либо не отрисуется, либо будет сильно лагать.

В вашей презентации Вы говорили, что когда искали средства для построения графиков ваш выбор пал на flot. Почему тогда чуть выше был озвучен amcharts? Справляется ли он с загрузкой большого кол-ва данных?

Заранее благодарен за ответы.

3. Какой интервал берете при сборе показателей системы - 1сек, 5сек, etc. Например как часто следует мониторить утилизацию диска. Ведь если брать интервал в 1 сек, то например за 10 часов будет такое кол-во данных что график либо не отрисуется, либо будет сильно лагать.

10 часов по секунде это всего 36к кортежей, если все в одну кучу. Ну если расстараться то больше, но линейно и не сильно, почти наверняка. Это плюш, честно.
К тому же 10 часов на один тест это совсем не торт. Много такого редко надо. А после прогона можно результаты и обработать как следует.

зы: для анализа еще матмоды ок.

Будучи железнодорожником симпатизирую Вашему Аэрокосмическому образованию.
Вопросы:
1. Сталкиваетесь ли Вы, Андрей BaAbaKa, с бюрократическими сложностями по работе, интересны примеры и пути решения.
2. Есть ли в команде сильные знаниями по трудовому праву работники, не перерабатывающие, не берущие постоянное увеличение нагрузки и прочие плюшки по загрузке от руководителей, при этом сохраняя очень хорошие отношения с Вами - руководителем (это чьи-то родственники?).
3. Что за белая лошадь на фото вконтакте у Вас в руках. Играете в шахматы?

Добрый день!

Очень рад был этой теме так как накопилось много вопросов, а задать некому. Итак:

1. Используете ли при анализе результатов мат. статистику? Если да, то что посоветуете почитать на эту тему (имеется в виду не книги по мат. статистики :), а книги по нагрузке где активно используется мат. статистика)
2. Какие книги посоветуете почитать по нагрузке?
3. Какой интервал берете при сборе показателей системы - 1сек, 5сек, etc. Например как часто следует мониторить утилизацию диска. Ведь если брать интервал в 1 сек, то например за 10 часов будет такое кол-во данных что график либо не отрисуется, либо будет сильно лагать.

В вашей презентации Вы говорили, что когда искали средства для построения графиков ваш выбор пал на flot. Почему тогда чуть выше был озвучен amcharts? Справляется ли он с загрузкой большого кол-ва данных?

Заранее благодарен за ответы.

1) даже не знаю как ответить. Без знания и понимания как минимум основных тестов будет очень непросто. Так что да. При этом для каждого теста мы не делаем больших вероятностных выкладок — всё равно очень сильно ошибемся. Так что если подразумевать под мат. статистикой то-то серьезное, то скорее нет. Но в данных ковыряемся очень много. Вот прямо сегодня копали в очень интересную сторону :)
Вообще в интренете, особенно применительно к трафику очень сложно делать какие-либо прогнозы — ссылка с главной страницы яндекса добавляет несколько сотен тысяч переходов в сутки и вся ваша мат. модель разъезжается.
2) Хороших книжек, учащих аккуратному и правильному (с точки зрения крупных вебсервисов) нагрузочному тестированию на русском языке, к сожалению нет. И статей нет (меня не погонят отсюда за такое? ) У меня в моемкруге (http://baabaka.moikrug.ru/) слева перечислены рекомендуемые книжки (собственно это все недостаточно старые и достаточно внятные книжки о тестировании производительности и планировании нагрузки). Ссылки давать не буду, но если сами не найдете — пишите ;)
3) минимальный квант времени, которым мы оперируем — 1 секунда, больше нельзя, а меньше почти никогда смысла нет. Агрегируя данных хотя бы до 5 секунд, вы очень многого можете не заметить. Недавно много возились с багом в ядре, которое лочилось на несколько сот миллисекунд, что для сервиса со временем ответа в единицы-десятки миллисекунд и нагрузкой в несколько тысяч запросов в секунду очень заметно. Самые толстые данные, которые получаются за время теста (исключая дампы ответов) — это времена ответов сервисов. Мы не храним каждое значение. Для каждой секунды строим гистограмму из 15-25 диапазонов и храним только её. Плюс храним честно вычисленные квантили времен ответов (например, время, в которое уложились 95% запросов). И квантили, и гистограммы можно детализировать в рамках секунды на отдельные классы запросов (мы их называем гильзами). Для вывода в график мы агрегируем данные, при этом есть возможность зазумиться и посмотреть неагрегированные. Плюс кэширование xml-ек с данными для уже построенных графиков, чтобы заново не ходить в базу для уже завершившихся тестов. Пока никаких проблем с производительностью нет.
4) ну YaC давно был :) Недавно вышла-таки js-версия amcharts, скорее всего переедем на неё. flot тоже подрос с тех пор, но что-то как-то amcharts всё-таки намного более функционален.

3. Какой интервал берете при сборе показателей системы - 1сек, 5сек, etc. Например как часто следует мониторить утилизацию диска. Ведь если брать интервал в 1 сек, то например за 10 часов будет такое кол-во данных что график либо не отрисуется, либо будет сильно лагать.

10 часов по секунде это всего 36к кортежей, если все в одну кучу. Ну если расстараться то больше, но линейно и не сильно, почти наверняка. Это плюш, честно.
К тому же 10 часов на один тест это совсем не торт. Много такого редко надо. А после прогона можно результаты и обработать как следует.

зы: для анализа еще матмоды ок.

Yep. Спасибо, Сирожа. Всё верно.

Будучи железнодорожником симпатизирую Вашему Аэрокосмическому образованию.
Вопросы:
1. Сталкиваетесь ли Вы, Андрей BaAbaKa, с бюрократическими сложностями по работе, интересны примеры и пути решения.
2. Есть ли в команде сильные знаниями по трудовому праву работники, не перерабатывающие, не берущие постоянное увеличение нагрузки и прочие плюшки по загрузке от руководителей, при этом сохраняя очень хорошие отношения с Вами - руководителем (это чьи-то родственники?).
3. Что за белая лошадь на фото вконтакте у Вас в руках. Играете в шахматы?

Ах, Ярославль :) У нас в Яндексе есть true-железнодорожники в команде Яндекс.Расписаний — наимилейшие люди! :)

1) у нас в Яндексе этого очень мало, так что их нет. Если появятся, то путь один — договариваться и убеждать. У нас административные меры не работают :)
2) мы все уже как родственники :) график гибкий, работать можно когда угодно. Важны 2 принципа: дела должны делаться и люди не должны тебя искать (договорились — сдержи обещание). Никто за какой-нибудь "отработкой часов не следит".
3) на одном из балконов у нас есть гигантская шахматная доска — этот конь какбэ с неё. Играю редко :)

1) Amcharts невероятно гибкий инструмент для визуализации данных. Очень удобно. После недавнего выхода js-версии теперь можно сделать вообще невероятные вещи) Зачем писать своё, поддерживать, если есть готовое и очень хорошее? Чуть подробнее о том, что пробовали и почему остановились на AmCharts я рассказывал на YaC, тут выше ссылка уже была.

Вот здесь Вы говорили обратное, в чем подвох?.
Мы тоже рассматривали для одного из наших проектов репортинг с помощью amcharts и отказались по причине медленной обработки большого количества значений.

1) Amcharts невероятно гибкий инструмент для визуализации данных. Очень удобно. После недавнего выхода js-версии теперь можно сделать вообще невероятные вещи) Зачем писать своё, поддерживать, если есть готовое и очень хорошее? Чуть подробнее о том, что пробовали и почему остановились на AmCharts я рассказывал на YaC, тут выше ссылка уже была.

Вот http://company.yande...c/materials.xml Вы говорили обратное, в чем подвох?.
Мы тоже рассматривали для одного из наших проектов репортинг с помощью amcharts и отказались по причине неудворительной обработки большого количества значений.

Подвох в том, что на YaC я говорил про flash-amcharts, а тут про js-amcharts, который вышел совсем недавно. Второй существенно быстрее. Ну и не стоит отображать большое колличество значений — агрегируйте, а при зуме показывайте всё.

1) Amcharts невероятно гибкий инструмент для визуализации данных. Очень удобно. После недавнего выхода js-версии теперь можно сделать вообще невероятные вещи) Зачем писать своё, поддерживать, если есть готовое и очень хорошее? Чуть подробнее о том, что пробовали и почему остановились на AmCharts я рассказывал на YaC, тут выше ссылка уже была.

Вот здесь Вы говорили обратное, в чем подвох?.
Мы тоже рассматривали для одного из наших проектов репортинг с помощью amcharts и отказались по причине медленной обработки большого количества значений.

Если не секрет что стали иcпользовать?

1) Amcharts невероятно гибкий инструмент для визуализации данных. Очень удобно. После недавнего выхода js-версии теперь можно сделать вообще невероятные вещи) Зачем писать своё, поддерживать, если есть готовое и очень хорошее? Чуть подробнее о том, что пробовали и почему остановились на AmCharts я рассказывал на YaC, тут выше ссылка уже была.

Вот здесь Вы говорили обратное, в чем подвох?.
Мы тоже рассматривали для одного из наших проектов репортинг с помощью amcharts и отказались по причине медленной обработки большого количества значений.

Если не секрет что стали иcпользовать?

Сделали кастомный репортинг.

Ну и не стоит отображать большое колличество значений — агрегируйте, а при зуме показывайте всё.

А данные какими инстурментами агрегируете?

Ну и не стоит отображать большое колличество значений — агрегируйте, а при зуме показывайте всё.

А данные какими инстурментами агрегируете?

Phantom (генератор нагрузки) отдает время ответа для каждого запроса. Они передаются в модуль, который для каждой секунды теста аггрегирует времена ответов и строит гистограмму. Все модули изначально были написаны на perl, сейчас рефакторятся и постепенно переводятся на python. Так что если этот элемент системы можно назвать инструментом :), то он у нас самописный.

Добрый день!

Андрей, расскажите пожалуйста как устроена ваша "пушка". Нам видимо придется отказатся от Load Runner и писать свой LoadIbjector, так как LR достаточно глючноват (так и не удалось на нем завести IP Spoofing), не поддерживает нужные нам протоколы (сразу скажу я знаю что его можно расширять, но это мрак), врет на скоростях больше 300 Мб и т.д. Изначально была идея написать все на Ruby или Python, но после немногих экспериментов стало понятно, что из них малым железом не выжать гигабитный трафик. Как это делали Вы? На чем написан генератор, использовали ли open source библиотеки, как выгружаете статистику, с какими трудностями столкнулись при реализации? Заранее благодарен за ответ.

Добрый день!

Андрей, расскажите пожалуйста как устроена ваша "пушка". Нам видимо придется отказатся от Load Runner и писать свой LoadIbjector, так как LR достаточно глючноват (так и не удалось на нем завести IP Spoofing), не поддерживает нужные нам протоколы (сразу скажу я знаю что его можно расширять, но это мрак), врет на скоростях больше 300 Мб и т.д. Изначально была идея написать все на Ruby или Python, но после немногих экспериментов стало понятно, что из них малым железом не выжать гигабитный трафик. Как это делали Вы? На чем написан генератор, использовали ли open source библиотеки, как выгружаете статистику, с какими трудностями столкнулись при реализации? Заранее благодарен за ответ.

Ага, прекрасно вас понимаю :) А про почти всё это Влад Селиверстов хорошо на YaC рассказал — http://company.yande...c/materials.xml Он рассказывал про веб-сервер phantom, который в один прекрасный день развернули и сделали генератором нагрузки. Давайте сделаем так — вы посмотрите, а потом поспрашиваете уже конкретику. Ок?

Андрей, кстати, было бы круто если бы кто-нибудь (например ты %)) собрал все эти материалы в одном месте и еще чтобы с камментами, картинками, линкой на то чтобы скачать лунапарк и все такое)

Андрей, кстати, было бы круто если бы кто-нибудь (например ты %)) собрал все эти материалы в одном месте и еще чтобы с камментами, картинками, линкой на то чтобы скачать лунапарк и все такое)

Да, было бы хорошо :)

Все эти материалы это какие? Ну и главный вопрос: чтобы что? ;)

У вас (не только у тебя, Андрей, а вообще) было много презентаций на тему того как у вас все устроено, как оно работает и как вы планируете с этим жить. Видео, слайды и прочая. Я думаю было бы очень классно, если бы их не надо было собирать по закромам разных конференций, а все они лежали в одном месте. Тем более что часто слышу и вижу ответы вида "а посмотрите вот это вот видео, потом может понятнее станет".

Я понимаю что вопросов сильно меньше не станет, но в меру ленивому мне было бы удобно. Ну а в целом для ознакомления публики, т.к. очень круто искать когда ты знаешь что искать тебе надо, но я готов поспорить что вопросы по прошлогоднему докладу из Ебурга про мяско просто так далеко не всем в голову придут.

У вас (не только у тебя, Андрей, а вообще) было много презентаций на тему того как у вас все устроено, как оно работает и как вы планируете с этим жить. Видео, слайды и прочая. Я думаю было бы очень классно, если бы их не надо было собирать по закромам разных конференций, а все они лежали в одном месте. Тем более что часто слышу и вижу ответы вида "а посмотрите вот это вот видео, потом может понятнее станет".

Я понимаю что вопросов сильно меньше не станет, но в меру ленивому мне было бы удобно. Ну а в целом для ознакомления публики, т.к. очень круто искать когда ты знаешь что искать тебе надо, но я готов поспорить что вопросы по прошлогоднему докладу из Ебурга про мяско просто так далеко не всем в голову придут.

Мы (Яндекс) стараемся все наши высступления собирать вот здесь: http://company.yande...ences/?view=all Но мир не совершенен и того же мясного рассказа Димы Никоненко тут не оказалось (сейчас узнаю почему и добавим). Мы (нагрузочное тестирование) сейчас хотим сделать отдельную площадку о рассказах, но пока не сделали, обещать не будем :) А так да, конечно же вы правы.