Подводные камни в нагрузочном тестировании

© Netcracker 2016 1

Нагрузочные тесты и JMeterВладимир Ситников


• Владимир Ситников• Инженер производительности в Netcracker• JMeter committer• [email protected]@VladimirSitnikv@vlsi

Кто на сцене?


Проводим идеальные нагрузочные тесты

План


Расскажу почему JMeterэто лучший инструмент

План


•Скрытые проблемы нагрузочных инструментов•На что обращать внимание•Coordinated omission

План


О чём будем говорить



Браузер APP DB

Нагрузка



Нагрузка


•Нужен «личный кабинет»•Там будет «смена тарифного плана»•Будет 100 запросов в час •И работать должно за 5 секунд

Клиент такой


Надо? Измерим!

Операция Кол-во Среднеевремя, сек

Домашняя страница 100 1,45

Личный кабинет 100 0,42

Смена тарифа 100 0,93< 5сек


⏱+⏱+…+⏱N

Среднее значение

=⏱


⏱+⏱+⏳+⏱N


=?


•Измерить среднее невозможно•Плохо отражает ощущаемую производительность

•Любой выброс может кардинально изменить среднее

Проблемы


•Случайная величина•Используется для ухода в астрал

• http://latencytipoftheday.blogspot.ru/2014/06/latencytipoftheday-average-random.html



«Разумеется», измеряем квантили (~90%)


Облако точек


Плотность распределения


Убираем 5% худших и 5% лучших, усредняем

ОК?


На самом деле, убираем 10% худших

90%


•90%•95%•99%•100%

И что измерять?

50/50?


•Счастье, это когда требования удовлетворяются

•Сам собой код не ускорится•За чей счёт будем достигать 99%?

Не в замерах счастье


•90% +1 человеко-месяц•95% +5 человеко-месяцев•99% +100 человеко-месяцев•100% +100500 человеко-месяцев

Поддержка требований требует ресурсы, ваш КО


•90% ß норм для начала•95% ß для бывалых•99% ß для крутых•100% ß для маньяков

И что же выбрать?


Времена попали в требования, результаты хорошие?


Всё же хорошо?

Операция Кол-во 90%, секДомашняя страница 100 1,45


Смена тарифа 100 0,93


Типичный результат замера

(x, y) = { (10,0; 8,04), (8,0; 6,95), (13,0; 7,58), (9,0; 8,81), (11,0; 8,33), (14,0; 9,96), (…


Усредним

Операция РезультатСреднее значение X 9.0

Дисперсия X 10.0

Среднее Y 7.5

Дисперсия Y 3.75

Прямая лин. регрессии y=x/2+3

Повторим замер ещё несколько раз


Усредним

Операция A B C DСреднее значение X 9.0 9.0 9.0 9.0

Дисперсия X 10.0 10.0 10.0 10.0

Среднее Y 7.5 7.5 7.5 7.5

Дисперсия Y 3.75 3.75 3.75 3.75

Прямая лин. регрессии

y=x/2+3 y=x/2+3 y=x/2+3 y=x/2+3


Квартет Энскомба


Времена отклика курильщика


Времена отклика здорового человека


Нужно ли бороться с разбросом результатов?


Конечно, да!

Нужно ли бороться с разбросом?


•Высокая точность результатов•Высокая повторяемость результатов*

* Вы пробовали два одинаковых замера подряд?

Признаки хорошего теста


Немного теории

Чем меньше дисперсия* – тем лучше тест

* Колонка stdev в summary report


Чем меньше дисперсия* – тем лучше тестLabel # Samples Average Min Max Std. Dev.Домашняя страница 4 145 143 147 0,8

Личный кабинет 4 42 9 45 2,3

Смена тарифа 4 93 9 172 78,4


Откуда берётся разброс?Label # Samples Average Min Max Std. Dev.Домашняя страница 4 145 143 147 0,8

Личный кабинет 4 42 9 45 2,3

Смена тарифа 4 93 9 172 78,4


Откуда берётся разброс?Label # Samples Average Min Max Error %Домашняя страница 4 145 143 147 0

Личный кабинет 4 42 9 45 0

Смена тарифа 4 93 9 172 80


Ошибки это…

• HTTP: 401, 402, 403, 404, … 500, …• java.net.SocketException: Connection reset• Прочее


Случай из жизни

• Результат замера: 50 ± 2 мс• Ошибок: 0%• Обычно было 2 секунды• Причина: “302 Moved Temporary: /login.jsp”


А рабочий ли вообще тест?

Обязательно указываем assertions, иначе узнавать о падениях будем только через логи сервера*

* Кто-нибудь их вообще читает?


•Время отклика•Количество запусков•% ошибок

Обязательные результаты тестирования


Assertions возвращаются

Если assertions указаны, то следим за количеством ошибок

• В результате 90% line учитываются иуспешные и неуспешные результаты

• https://bz.apache.org/bugzilla/show_bug.cgi?id=57545


.*Error.*

.*/login.jsp

Регулярные выражения наносят ответный удар


Регулярные выражения

.* может очень сильно тормозить• Либо не пишем сложных regexp’ов• Либо учим матчасть:

http://2015.jpoint.ru/talks/sitnikov/


View Results in Tree


“View OOM Tree”

View Results in Tree приходится использовать для отладки• Для нагрузки этот компонент нужно отключать, иначе будет OutOfMemoryError в JMeter


“View OOM Tree”

• OutOfMemory в нагрузочном инструменте?

• Запросто!• Поэтому нужно снимать метрики и с него самого


GC логи с JMeter

Открываем лог в GCViewer и видим


Замеряем


Подаём нагрузку

90% line


Если просто подать нагрузку, то будет гидроудар


• Иногда тест на гидроудар нужен• Но обычно тестируют «обычный» режим


Как избежать гидроудара

• Перезапуск системы• Прогрев (меньшая нагрузка, длителность) • Замер


Подаём нагрузку


А если сценариев несколько?


Ramp-up delay

• И как настраивать ramp-up у 10+ сценариев?


Constant Throughput Timer


Таймеры в JMeter

• Таймеры «наследуются по иерархии вниз»• Поэтому получим не 4 разных

конференции в год• А только одну в год L


Чиним таймеры в JMeter


Constant throughput timer

Смотрим загрузку CPU и видим sin(x):

0 2,5 5 7,5 10 12,5 15 17,5

25

50

75

100


Constant throughput timer

• Смотрим загрузку CPU и видим sin(x)• Оказалось:

• Итерации стартуют каждую минуту ровно в 00 секунд

• И так в каждой thread group


Клиент: хочу 100 операций в час


Нужно 100 операций в час






Как получить ровно 100?






Добавить «think times»?


Think times

• И как подбирать задержки?


Exponential* Timer

* От слова «процесс Пуассона»


Exponential Timer

Exponential Timer соблюдает нагрузку.Если сказано 146 в час, то будет 146:


Требования на подачу нагрузки

Если в NFR сказано 146 в час, то должно быть 146 в час• Вне зависимости от количества потоков

• Вне зависимости от think time


И где брать exp timer?Тут: https://github.com/apache/jmeter/pull/231


И какое получится расписание?


Пример пуассоновского запуска

Запускаем «1 заказ в минуту» на протяжении 10-и минут:


Хотим «1 заказ в минуту в среднем»


Польза Exponential Timer

• Даже при низкой нагрузке захватываем случай «два sample почти одновременно»

• Поставил(а) и забыл(а)


А должно ли это расписание повторяться каждый раз?


Должен ли тест быть повторимым?


Конечно, да!

Должен ли тест быть повторимым?


Exponential Timer

• Задержки должны быть случайны и повторимы. Такое есть у нас:

• Раз от раза задержки будут одинаковые


Микроавтобусы

Можно нагружать «автобусами», т.е. подавать пачками по 16 samples:







Ну как так??


Пример времён отклика

• 1 sec• 1 sec• 120 sec• 1 sec


Нагружающие потоки

• На больших временах отклика нагрузочный инструмент залипает

• И перестаёт подавать нагрузку!


Пропажа нагрузки


Если нагрузочный инструмент недоподал нагрузку, то это coordinated omission


Сколько потоков ставить?

• Тестируем работу call center’а• Нагрузка – входящие телефонные звонки• 100 звонков в час• Один звонок длится 6 минут• Сколько потоков нужно?


Правильный ответ: количество потоков == количество реальных операторов


Лечим coordinated omission

Либо увеличиваем количество потоковЛибо «увеличиваем количество касс»


Coordinated omission

А я поставлю 1000 потоков и не будет у меня coordinated omission!



А я поставлю 1000 потоков и не будет у меня coordinated omission!Будет: java, TCP, OS, вот это всё вносит непредсказуемые задержки



• Coordinated omission особенно страшно на больших %%

• При большой нагрузке фиксируем времена черезhttps://github.com/HdrHistogram/HdrHistogram


Параметрические зависимости

Всё сделали, но разброс времён всё равно огромен. Что делать?


Привязка времён к входным данным

• Нужно знать на каких данных работал каждый запрос:• Customer id, location id – уникальные ID нужны обязательно

• Тип заказа, тип клиента – по желанию



JMeter -> Server: HTTP header X-JMeter-Step

customer:${customerId}, location: ${location}И на сервере понимаем на каких данных тестировали



JMeter -> Server: HTTP header X-JMeter-Step

customer:${customerId}, location: ${location}Как бы добавить «название шага»?



JMeter -> Server: HTTP header X-JMeter-Stepcustomer:${customerId}, location: ${location}, ${stepName}


Добавляем название шагаJMeter -> Server: HTTP header X-JMeter-Step

customer:${customerId}, location: ${location},${__BeanShell(setAccessibility(true);List c=vars.getObject("JMeterThread.pack").controllers;for(int i=0;i<c.size(); i++) if (c.get(i) instanceoforg.apache.jmeter.control.TransactionController) return c.get(i).getName().replaceFirst("^([0-9]+[.][0-9]+)[^_]+_(P[0-9]+)_"\, "$1$2"),)},



JMeter à CSV• FlexibleFileWriter• Или настройка sample_variables=customerId в

jmeter.properties


Внезапные всплески времён отклика


Всплески на временах отклика

• Оказалось, что в исходном csv данные упорядочены по стране

• При «смене» страны случается «прогрев»• Решение – перемешивать исходный CSV


Расслоение времён


Расслоение времён

• Оказалось, домашняя страница «пустого» клиента работает быстрее

• А в JMeter шаг назывался «домашняя страниа»

• Решение – использовать разные названия шагов: «новый клиент», «клиент с кучей опций»


В жизни


В жизни (крупный план)


Выводы


Выводы

• Проверяем кучность «облака точек со временами отклика»

• Используем правильные timer’ы• Перемешиваем исходные CSV• Не забываем логировать исходные ID


• Владимир Ситников• Инженер производительности в Netcracker• JMeter committer• [email protected]@VladimirSitnikv@vlsi

Вопросы?


Вопросы?

Подводные камни в нагрузочном тестировании

Software