Как стать автором
Обновить

Комментарии 41

Вы правы, надо как-нибудь перерисовать и выложить в опенсорс сразу.
Анализируете ли вы по результатам теста server side метрики? Время выполнения sql-запросов, утилизация диска, процессора?
Если да, то как их получаете? Есть ли единый инструмент сбора, или с миру по нитки? :)
Присоединяюсь к вопросу.
Еще бывает интересно насколько изменилась (и изменилиась ли вообще) производительность/отзывчивость сервиса при обновлении ядра, системных пакетов, зависимостей и т.п.
Второй пункт — это все тоже регрессионное тестирование как и в случае нового релиза. Так что это вопрос не технологий, а желания заказчика тестирования. Исходя из описанного, это происходит в большинстве автоматически.
Регрессионное тестирование, это все же отслеживание метрик производительности на большом временном интервале с большим количеством релизов. Он нужен с целью понять тренд производительности.

Если нужно понять насколько изменилась производительность со сменой ядра, версии библиотеки, то это тесты не на регрессию, а на сравнение и исследование.

Кроме того, бывают такие ситуации, когда в попытках исследовать версии библиотек в итоге откатываешься на более древнюю версию ради производительности. Это уже мало на регрессию похоже.

Необходимо просто сделать несколько тестов, сравнить метрики производительности (пропускная способность / время ответа и их распределение / конкуренция). Сравнить системные и софтовые метрики.
Это все и есть регресс. Миша, то что ты описал, лишь уровень анализа.
Данила, я разделяю эти понятия, т.к. в них разные цели тестирования.
Мне так проще:) Разделяю т.к. исследования нельзя автоматизировать, а вот регрессию разных релизов можно.
В том и дело, что цель, «сравнить версии систем», одна, а вот задачи в рамках достижения цели отличаются.

Уровень автоматизации в данном случае (полагаем состав профиля постоянным) зависит от глубины анализа. Само скриптогоняние от этого не должно меняться, меняется только система.
В yandex-tank есть отдельный модуль мониторинга.

В начале теста 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. Сейчас появился какой-нибудь гуй или интерфейс?
Раньше мы все писали в клубике clubs.ya.ru/yandex-tank/, в software-testing — software-testing.ru/forum/index.php?/topic/24249/, рассказываем на каждом YAC и тд.

Нет, Яндекс.Танк без GUI, он специально заточен под консоль. Я бы не сказал, что там все запутанно простейший конфиг состоит из 4 строчек. Задавайте вопросы, будем отвечать или писать статьи.
А с какими нагрузками обычно приходится сталкиваться в яндексе? и какой максимум может выдать ваш инструмент?
От единиц rps, до миллионов rps. При тестировании через свитч, с минимальным оверхэдом без keep-alive получаем 40000rps со средней машинки (8..16 ядер), с keep-alive — за 100к. Тюнинг физической машинки при предельных нагрузках обязателен.
Интересно… У меня следующие вопросы:
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, есть встроенные мониторинги, автостопы и куча всяких плюшек.

Спасибо, очень интересно. Я тоже занимался нагрузочным тестированием в университете, как раз защищаюсь на следующей неделе. Если вам интересно, посмотрите мой диплом, там я описываю метод автоматического определения регрессий в результатах нагрузочного тестирования. Ну и заодно там же обзор литературы по теме и описание репозитория для хранения и сравнения разных тестов. Может быть, какие-то мысли покажутся полезными.
Диплом по нагрузочному тестированию это очень круто! Обязательно посмотрим, и удачи в защите!
*Глядя на КДПВ* Кастет в виде танка?
Конкретное тестирование.
Чисто конкретно грузанул)
Как Яндекс.Танки понимают, что страницы готова для пользователя? Ведь на некоторых страницах, возможно, идет догрузка контента через AJAX, например? И не смотря на быстро время ответа сервера, страница будет догружаться еще длительное время. Или диагностика такого рода проблем не входит в задачи команды?

В блоге O'Reilly наткнулся на следующий пост, где даётся совет использовать технику «ручного» логирования времени загрузки каждой важной страницы. Не используется ли в Яндексе подобное решение?
Яндекс.Танки не оперируют понятиями пользователя, они оперируют на уровне ниже, на уровне HTTP протокола. Когда пользователь открывает страницу, он делает ряд http-запросов в сторону сервиса, и не важно что клиент для этого использует ajax, actionscript,flash,java-апплет. Важно что он делает именно http-запрос.

Яндекс.Танк не имеет внутри никакого браузерного движка, и он не пытается построить страницу чтобы понять какие еще запросы выполнить для построения страницы.

Человек, который управляет танком, сам выбирает какими запросами тестировать и в итоге можно смотреть на производительность отдельных процессов построения большой страницы целиком:)
Спасибо за ответ. Ситуация резко прояснилась :)
Задача Яндекс.Танка — создать нагрузку на сервер и померить именно время отклика самого сервера на каждый запрос. Танк ничего не знает о том, как страничка отображается в браузере. Если вы запишете трафик между браузером и сервером (tcpdump, логи сервера — смотря что вам нужно) — вы увидите все запросы: и ajax, и actionscript, и остальные — если только вы знаете, по какому порту и протоколу они идут. Если это HTTP — вам повезло и вы довольно просто сможете сервис обстрелять Танком или JMeter. Если нет — то придется подумать, как его распарсить, параметризовать и воспроизвести (хотя например HP LoadRunner умеет записывать и другие протоколы).

С другой стороны, может быть у вас задача именно в том, чтобы померить, за сколько страничка полностью загрузится у пользователя в браузере. В этом случае используются другие инструменты, о том, как это делается в Яндексе — рассказывала Марина Широчкина.
Спасибо за объяснения и ссылку!
Путаница в моей голове возникла еще при первой встрече с Яндекс.Танками, когда смотрел презентацию, и там было про использование Phantom. Перепутал с PhantomJS, который как раз используется для анализа времени загрузки фронтэнда.
Может кому пригодится, написал Gentoo ebuild'ы для phantom и yandex-tank.
Установка и работа проверена с Python2.7.
Качество написания ebuild'ов, возможно оставляет желать лучшего)))

Леша, промахнулся и минусанул. На самом деле ты очень крутой, спасибо тебе!
как нибудь можно подсунуть я.танку свой парсер который получает новые урлы из ответов сервера чтобы танк также эти урлы дергал?
Вы сейчас говорите о сценари или диалоге. Лучше для этого использовать Jmeter. И если это нужно автоматизировать, то можно использовать Яндекс.Танк для запуска этого jmeter тест-плана.
можно выдать танку сразу всё богатство урлов в нужной пропорции
Я сначала тоже подумал, но перечитал " новые урлы из ответов сервера ". Не зная ответов, урлы заранее не наклепаешь. Сценарий.
спасибо, да, урлы генерятся на сервере, заранее неизвестны.
Насчет сценариев 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%. Но тсунг отлично скейлится. Вся статистика собирается на мастере.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий