Как проводить нагрузочное тестирование веб-проектов, используя JMeter
23.10.2019
А вы проводите тестирование? Как часто? Им не стоит пренебрегать: оно показывает ресурсы системы и позволяет заблаговременно масштабировать её, не дожидаясь падения сервера. На 17-ой IT-пятнице обсуждали нюансы нагрузочного тестирования. Приводим конспект доклада.
Для чего нужно нагрузочное тестирование
Оно позволяет:
- оценить скорость работы;
- определить критерии стабильности;
- оценить возможности масштабирования приложения.
Владельцы и администраторы сайтов должны понимать, при каких входящих потоках они должны начинать планировать изменения в “железе” и софте, масштабировать инфраструктуру. Нагрузочное тестирование позволяет заранее узнать эти метрики, и быть готовыми к своевременной технической модернизации.
Такое тестирование должно давать прогнозы — не только описывать текущий уровень. Например, сейчас сайт открывается за полсекунды с 20 тысячами одновременных запросов. А если к ним добавится еще 20 тысяч? 40? Как изменится время отклика и откроется ли сайт вообще? Эксперименты и прогнозы покажут, при каких показателях система будет нуждаться в масштабировании.
Виды нагрузочного тестирования
1. Плановое тестирование. При нём мы даём нагрузку, которая ожидается при обычной работе — система должна нормально работать в таких условиях.
2. Стресс-тестирование. Это испытание в условиях экстремальных рабочих нагрузок. Для него обычная рабочая нагрузка увеличивается в десятки, сотни или даже тысячи раз. Определяет, что произойдёт с системой, когда резко увеличатся показатели при том же самом паттерне поведения посетителей сайта.
3. Тестирование на выносливость. Здесь мы даём нагрузку на 50-100% выше, чем обычно, но оставляем её на продолжительным времени. Часто такое тестирование показывает то, чего не видно на обычном плановом испытании. Например, появляются бэкапы — как следствие, переполняются кэши, достигаются лимиты максимального количества параллельных соединений к серверу...
4. Тестирование пиков. Оно выявляет реакцию ПО на внезапные большие пиковые нагрузки, создаваемые пользователями. Например, в вечерний прайм-тайм клиент говорит вам: “Через 15 минут у меня рассылка по 100 тысячам пользователей, и они сейчас зайдут на сайт”. Это значит, что к текущему органическому трафику резко добавится волны посетителей с рассылки. К этому нужно быть готовым — знать, как поведёт себя система при резких скачках нагрузок.
5. Объёмное тестирование. Его суть в том, чтобы сгенерировать самые объёмные запросы, которые могут быть со стороны посетителей сайта. Это максимально большие выборки, максимально долгие сессии. Тестирование определяет, как система поведёт себя при нагрузках запросов максимального объема.
6. Тестирование масштабируемости. Это то же самое плановое тестирование, но в момент увеличения производительности системы путём добавления новых элементов. Например, дополнительного “слейва”, балансировщика, php-ноды и т.п. В этот момент ресурсы самой системы тоже потребляются, и она “просаживается”. Тестировать на масштабируемость нужно заранее, чтобы знать, когда вы должны разворачивать новые мощности, не дожидаясь пиковых нагрузок и отказа серверов.
Порядок нагрузочного тестирования
1. Определите характеристики текущей среды тестирования. Вы должны понимать, насколько они шире или уже свойств той среды, которую мы пытаемся воссоздать в тестировании.
2. Определите критерии приемлемости производительности. Тестирование всегда преследует некие цели, но не всегда результат теста соотносится с ними. Критерии, которые способен показать тест, должны быть приемлемы с тем, что вы хотите определить.
3. Запланируйте и разработайте тесты производительности.
4. Настройте тестовую среду.
5. Реализуйте тестовый дизайн. После того, как мы определили программу тестирования, критерии и среду, нужно протестировать сами тесты. Выясните, действительно ли тест измеряет именно то, что нужно, и так, как нужно. Для этого нужно изучить лог вывода и сопоставить его с желаемым результатом: мы тестируем нужные страницы? Делаем это на основании загруженных данных?
6. Проведите сами тесты.
7. Проведите анализ, уточнение и повторное тестирование. Делайте тесты хотя бы три раза, в идеале — пять. Без фанатизма: не каждый релиз изменяет архитектуру и работу системы, поэтому запускать тестирование перед абсолютно всеми релизами не нужно.
Какие общие метрики позволяет определить нагрузочное тестирование
Их 17, вот они:
- использование процессорного времени;
- использование памяти;
- время IO операций;
- пропускная способность IO;
- выделенная память;
- число ошибок страниц;
- количество прерываний в секунду;
- длина очереди диска;
- длина очереди вывода сети;
- время ответа;
- число соединений;
- максимальное количество активных сеансов;
- коэффициенты попадания в кэш;
- блокировки баз данных;
- максимальное время ожидания;
- количество потоков;
- сборка мусора.
1. Делаем карту — что вообще мы будем тестировать. Бывает, SEO-шники говорят: “Вот наша карта сайта, мы будем по ней жить”. Вы прогоняете её по тесту, и на 80% ссылок получаете 404 ошибку. Дескать, когда-нибудь оптимизаторы создадут эти страницы, а пока там пусть будут заглушки. Так не пойдёт: собираем не ту карту сайта, которую нам скажут собрать SEO-шники, а реальную, с помощью Link Checker.
2. Собираем поведенческие факторы. Это удобно делать с помощью Matomo (раньше называлась Pivick) — локальной альтернативы Яндекс.Метрики и Google Analytics, работающей на своих логах. Она очень точно отображает статистику загрузок страниц и действий пользователей. С учётом данных можно выбрать оптимальную частоту кэширования.
Интернет-магазины обычно не кэшируют последние страницы воронки, на которых оформляется заказ. А до этого человек посещает 2-4 статичных страницы с кэшированными данными. Вот этот переход нагрузки от кэшированных к некэшируемым страницам сильно влияет на поведение сервера. По простым логам этого не предсказать, а Matomo покажет.
3. Собираем access-логи.
4. Составляем шаблон тестирования с помощью JUnit Sampler, Access log Sampler.
После этого мы получим готовый план тестирования. В нём можно:
- провести обычный тест;
- запустить 10-30 или больше копий теста с разными источниками;
- провести стрессовое тестирование (двукратный запуск нагрузки на протяжении 24 часов);
- провести тестирование на выносливость (много коротких стресс-тестов при плановой нагрузке).
