Комментарии 41
Бейджики из 4sq…
Анализируете ли вы по результатам теста server side метрики? Время выполнения sql-запросов, утилизация диска, процессора?
Если да, то как их получаете? Есть ли единый инструмент сбора, или с миру по нитки? :)
Если да, то как их получаете? Есть ли единый инструмент сбора, или с миру по нитки? :)
Присоединяюсь к вопросу.
Еще бывает интересно насколько изменилась (и изменилиась ли вообще) производительность/отзывчивость сервиса при обновлении ядра, системных пакетов, зависимостей и т.п.
Еще бывает интересно насколько изменилась (и изменилиась ли вообще) производительность/отзывчивость сервиса при обновлении ядра, системных пакетов, зависимостей и т.п.
Второй пункт — это все тоже регрессионное тестирование как и в случае нового релиза. Так что это вопрос не технологий, а желания заказчика тестирования. Исходя из описанного, это происходит в большинстве автоматически.
Регрессионное тестирование, это все же отслеживание метрик производительности на большом временном интервале с большим количеством релизов. Он нужен с целью понять тренд производительности.
Если нужно понять насколько изменилась производительность со сменой ядра, версии библиотеки, то это тесты не на регрессию, а на сравнение и исследование.
Кроме того, бывают такие ситуации, когда в попытках исследовать версии библиотек в итоге откатываешься на более древнюю версию ради производительности. Это уже мало на регрессию похоже.
Необходимо просто сделать несколько тестов, сравнить метрики производительности (пропускная способность / время ответа и их распределение / конкуренция). Сравнить системные и софтовые метрики.
Если нужно понять насколько изменилась производительность со сменой ядра, версии библиотеки, то это тесты не на регрессию, а на сравнение и исследование.
Кроме того, бывают такие ситуации, когда в попытках исследовать версии библиотек в итоге откатываешься на более древнюю версию ради производительности. Это уже мало на регрессию похоже.
Необходимо просто сделать несколько тестов, сравнить метрики производительности (пропускная способность / время ответа и их распределение / конкуренция). Сравнить системные и софтовые метрики.
В yandex-tank есть отдельный модуль мониторинга.
В начале теста yandex-tank заходит по ssh на указанные машины и снимает системные метрики. Есть возможность указания кастомных метрик.
Конфиг мониторинга выглядит примерно так. Для наглядности добавил кастомную метрику количества всех TCP-сокетов на системе.
В начале теста yandex-tank заходит по ssh на указанные машины и снимает системные метрики. Есть возможность указания кастомных метрик.
Конфиг мониторинга выглядит примерно так. Для наглядности добавил кастомную метрику количества всех TCP-сокетов на системе.
<Monitoring>
<Host address="xxx.load.net">
<CPU measure="user,system,iowait"/>
<System measure="csw,int"/>
<Memory measure="free,used"/>
<Disk measure="read,write"/>
<Net measure="recv,send"/>
<Custom measure="call">ss -s | grep estab | awk '{print $2}'</Custom>
</Host>
</Monitoring>
Где же вы были раньше и почему раньше ничего не писали по нагрузочному тестиронию, в начале года пришлось перекопать очень много документации по этой теме. С удовольствием почитаю, обязательно продолжайте писать.
Яндекс танк пробовал в начале года, не понравилось, слишком все запутанно и не очевидно было на тот момент для меня по сравнению с JMeter. Сейчас появился какой-нибудь гуй или интерфейс?
Яндекс танк пробовал в начале года, не понравилось, слишком все запутанно и не очевидно было на тот момент для меня по сравнению с JMeter. Сейчас появился какой-нибудь гуй или интерфейс?
Раньше мы все писали в клубике clubs.ya.ru/yandex-tank/, в software-testing — software-testing.ru/forum/index.php?/topic/24249/, рассказываем на каждом YAC и тд.
Нет, Яндекс.Танк без GUI, он специально заточен под консоль. Я бы не сказал, что там все запутанно простейший конфиг состоит из 4 строчек. Задавайте вопросы, будем отвечать или писать статьи.
Нет, Яндекс.Танк без GUI, он специально заточен под консоль. Я бы не сказал, что там все запутанно простейший конфиг состоит из 4 строчек. Задавайте вопросы, будем отвечать или писать статьи.
А с какими нагрузками обычно приходится сталкиваться в яндексе? и какой максимум может выдать ваш инструмент?
Интересно… У меня следующие вопросы:
0) Правильно ли я понял — нагрузку можно создавать из нескольких машин и получать результаты на одной?
1) Какую максимальную нагрузку можно создать с одной машины, например — количество http реквестов в секунду в 1 поток, 100, 500 (можно любую из ваших в пример)?
2) Какое максимальное количество потоков можно создать на одной машине для имитации конкурентных пользователей?
3) Есть ли поддержка https?
0) Правильно ли я понял — нагрузку можно создавать из нескольких машин и получать результаты на одной?
1) Какую максимальную нагрузку можно создать с одной машины, например — количество http реквестов в секунду в 1 поток, 100, 500 (можно любую из ваших в пример)?
2) Какое максимальное количество потоков можно создать на одной машине для имитации конкурентных пользователей?
3) Есть ли поддержка https?
0) Для агрегации данных с нескольких танков мы используем закрытый пока tank api. Дело в том, что для нагрузочного тестирования обычных сервисов — типа интернет магазинов, порталов, блогов — хватит одного сервера для достижения десятков тысяч хитов. Многохостовая конфигурация по сути не нужна. Но если вы предложите кейс, когда такой нагрузки не хватает, мы подумаем над выкладкой API в опенсорс.
1) В 1 поток можно подать столько запросов сколько позволит время ответа. Например, если сервер отвечает за 1 секунду, то грубо говоря в один поток влезит 1 запрос в секунду. Если сервер отвечает за 1ms, то 1000 rps. Если мы увеличиваем число потоков, то соответственно танк получает большую свободу и может выдавать все более высокую нагрузку, используя свободные потоки.
2) По дефолту на машинке можно уткнуться в число дискрипторов 1024, поэтому вам надо снять лимиты — yandextank.readthedocs.org/en/latest/install.html#tuning.
После снятия лимитов, вы можете работать с десятками тысяч потоков.
Заметьте, что вы можете упереться в число открытых иходящих портов, поэтому есть такой режим — yandextank.readthedocs.org/en/latest/tutorial.html#gatling, который позволяет навесить исходящие порты на виртуальные IP и вы можете увеличить число открытых портов. Но через некоторое время процессору танка будет тяжело обслуживать большое количество корутин и производительность его уткнется в некий предел.
3) Есть поддержка https/ipv6, есть встроенные мониторинги, автостопы и куча всяких плюшек.
1) В 1 поток можно подать столько запросов сколько позволит время ответа. Например, если сервер отвечает за 1 секунду, то грубо говоря в один поток влезит 1 запрос в секунду. Если сервер отвечает за 1ms, то 1000 rps. Если мы увеличиваем число потоков, то соответственно танк получает большую свободу и может выдавать все более высокую нагрузку, используя свободные потоки.
2) По дефолту на машинке можно уткнуться в число дискрипторов 1024, поэтому вам надо снять лимиты — yandextank.readthedocs.org/en/latest/install.html#tuning.
После снятия лимитов, вы можете работать с десятками тысяч потоков.
Заметьте, что вы можете упереться в число открытых иходящих портов, поэтому есть такой режим — yandextank.readthedocs.org/en/latest/tutorial.html#gatling, который позволяет навесить исходящие порты на виртуальные IP и вы можете увеличить число открытых портов. Но через некоторое время процессору танка будет тяжело обслуживать большое количество корутин и производительность его уткнется в некий предел.
3) Есть поддержка https/ipv6, есть встроенные мониторинги, автостопы и куча всяких плюшек.
Спасибо, очень интересно. Я тоже занимался нагрузочным тестированием в университете, как раз защищаюсь на следующей неделе. Если вам интересно, посмотрите мой диплом, там я описываю метод автоматического определения регрессий в результатах нагрузочного тестирования. Ну и заодно там же обзор литературы по теме и описание репозитория для хранения и сравнения разных тестов. Может быть, какие-то мысли покажутся полезными.
*Глядя на КДПВ* Кастет в виде танка?
Как Яндекс.Танки понимают, что страницы готова для пользователя? Ведь на некоторых страницах, возможно, идет догрузка контента через AJAX, например? И не смотря на быстро время ответа сервера, страница будет догружаться еще длительное время. Или диагностика такого рода проблем не входит в задачи команды?
В блоге O'Reilly наткнулся на следующий пост, где даётся совет использовать технику «ручного» логирования времени загрузки каждой важной страницы. Не используется ли в Яндексе подобное решение?
В блоге O'Reilly наткнулся на следующий пост, где даётся совет использовать технику «ручного» логирования времени загрузки каждой важной страницы. Не используется ли в Яндексе подобное решение?
Яндекс.Танки не оперируют понятиями пользователя, они оперируют на уровне ниже, на уровне HTTP протокола. Когда пользователь открывает страницу, он делает ряд http-запросов в сторону сервиса, и не важно что клиент для этого использует ajax, actionscript,flash,java-апплет. Важно что он делает именно http-запрос.
Яндекс.Танк не имеет внутри никакого браузерного движка, и он не пытается построить страницу чтобы понять какие еще запросы выполнить для построения страницы.
Человек, который управляет танком, сам выбирает какими запросами тестировать и в итоге можно смотреть на производительность отдельных процессов построения большой страницы целиком:)
Яндекс.Танк не имеет внутри никакого браузерного движка, и он не пытается построить страницу чтобы понять какие еще запросы выполнить для построения страницы.
Человек, который управляет танком, сам выбирает какими запросами тестировать и в итоге можно смотреть на производительность отдельных процессов построения большой страницы целиком:)
Задача Яндекс.Танка — создать нагрузку на сервер и померить именно время отклика самого сервера на каждый запрос. Танк ничего не знает о том, как страничка отображается в браузере. Если вы запишете трафик между браузером и сервером (tcpdump, логи сервера — смотря что вам нужно) — вы увидите все запросы: и ajax, и actionscript, и остальные — если только вы знаете, по какому порту и протоколу они идут. Если это HTTP — вам повезло и вы довольно просто сможете сервис обстрелять Танком или JMeter. Если нет — то придется подумать, как его распарсить, параметризовать и воспроизвести (хотя например HP LoadRunner умеет записывать и другие протоколы).
С другой стороны, может быть у вас задача именно в том, чтобы померить, за сколько страничка полностью загрузится у пользователя в браузере. В этом случае используются другие инструменты, о том, как это делается в Яндексе — рассказывала Марина Широчкина.
С другой стороны, может быть у вас задача именно в том, чтобы померить, за сколько страничка полностью загрузится у пользователя в браузере. В этом случае используются другие инструменты, о том, как это делается в Яндексе — рассказывала Марина Широчкина.
Может кому пригодится, написал Gentoo ebuild'ы для phantom и yandex-tank.
Установка и работа проверена с Python2.7.
Качество написания ebuild'ов, возможно оставляет желать лучшего)))
Установка и работа проверена с Python2.7.
Качество написания ebuild'ов, возможно оставляет желать лучшего)))
как нибудь можно подсунуть я.танку свой парсер который получает новые урлы из ответов сервера чтобы танк также эти урлы дергал?
Вы сейчас говорите о сценари или диалоге. Лучше для этого использовать Jmeter. И если это нужно автоматизировать, то можно использовать Яндекс.Танк для запуска этого jmeter тест-плана.
можно выдать танку сразу всё богатство урлов в нужной пропорции
Я сначала тоже подумал, но перечитал " новые урлы из ответов сервера ". Не зная ответов, урлы заранее не наклепаешь. Сценарий.
спасибо, да, урлы генерятся на сервере, заранее неизвестны.
Насчет сценариев jmeter понятно, а с быстродействием у такой схемы как?
планируется стресс 10К rps делать, один сервак jmeter/tank со средним железом столько выдаст?
Насчет сценариев jmeter понятно, а с быстродействием у такой схемы как?
планируется стресс 10К rps делать, один сервак jmeter/tank со средним железом столько выдаст?
Возможно, вам стоит обратить внимание на что-то типа wrk, он поддерживает луа скрипты которыми и можно парсить ответ от сервера и подставлять в следующий запрос
думаю, если максимально облегчить jmeter, выкинув тяжелые лиснеры, то можно попробовать разогнать.
ясно, спасибо, т.е. jmeter обычно дает около тысячи rps с одной тачки, а если в танке нужно больше то фантом?
Но фантом не поддерживает такие диалоги?
Но фантом не поддерживает такие диалоги?
Нет, фантом это не поддерживает.
т.е. jmeter обычно дает около тысячи rps с одной тачки
В нашем сценарии целых 300 реквестов =). А нам надо лоад в 20к рек/сек. Заюзали Tsung, он умеет делать то, что вам нужно.
Наш сценарий — Post request, парсим результат, в зависимости от результата дергаем нужную урлу новым Get request.
Заюзали Tsung, он умеет делать то, что вам нужно.
Наш сценарий — Post request, парсим результат, в зависимости от результата дергаем нужную урлу новым Get request.
Так понял имеется ввиду это?
И вы используете значение которое распарсили из ответа в параметрах этого нового get запроса?
И 20К — это tsung с одной тачки стока посылает?
Так понял имеется ввиду это?
Почти — JSONPath.
И вы используете значение которое распарсили из ответа в параметрах этого нового get запроса?
Да.
И 20К — это tsung с одной тачки стока посылает?
С 2-х. При 10к рек/сек у нас полностью забивается сеть в 100 мб/c на одной машине, процессора еще остается около 20%. Но тсунг отлично скейлится. Вся статистика собирается на мастере.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наши танки. История нагрузочного тестирования в Яндексе