Перейти к содержимому
BXWiki

Нагрузочное тестирование - сценарий, расчёт, чтение результатов

Проверяем сайт нагрузкой заранее, а не в день акции. Считаем пиковую нагрузку, собираем сценарий из реальных цепочек и читаем результаты по порогам нормы.

Механика

Нагрузочное тестирование делится на три этапа: подготовка, проведение и анализ. Пропуск первого этапа делает бессмысленными два остальных, а пропуск третьего превращает работу в набор непрочитанных чисел.

Цель и критерии успеха формулируют заранее, ещё до начала самого теста. Без них результат нельзя интерпретировать и тем более показать заказчику: любое число выглядит одинаково убедительно.

Тестировать нужно на близком к боевому по объёму наборе данных сайта. Пустой каталог отвечает быстро при любой нагрузке, и такой результат не говорит о боевом сайте ничего.

Считают именно пиковую нагрузку на сайт, а не среднюю за сутки. Среднее число запросов в секунду выводят из суточных обращений, а пик берут в два-три раза выше и нагружают именно этим значением.

Нагружают именно динамические страницы сайта, а не его статические файлы. Картинки и стили отдаёт веб-сервер почти бесплатно, поэтому в сценарий берут страницы, которые собирает платформа.

Пользователей моделируют разными. У каждого потока своя учётная запись, свои поисковые слова и свои страницы, а число тестовых пользователей берут в два-три раза больше ожидаемых посетителей.

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

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

В сценарий включают фоновые операции. Обмен с учётной системой, агенты и выгрузки дают деградацию чаще, чем обычный просмотр страниц.

Инструмент для нагрузки выбирают по обычному принципу от простого к сложному. Быстрая проверка одного адреса, простые сценарии из списка адресов и полноценный сценарный инструмент решают разные задачи и требуют разных усилий.

Отдельная тема - что именно считать успехом. Договориться стоит в понятных заказчику числах: сколько посетителей одновременно держит сайт и какое время ответа считается приемлемым в этот момент.

Такая формулировка переживает и смену инструмента, и полную смену команды. Внутренние показатели генератора нагрузки понятны инженеру, а разговор с бизнесом идёт про посетителей, заказы и секунды ожидания.

Шаги

  1. Сформулировать цель теста и критерии успеха ещё до его фактического проведения.
  2. Наполнить копию сайта данными в объёме, близком к боевому набору данных.
  3. Посчитать пиковую нагрузку из суточных обращений и разбить её на цепочки.
  4. Собрать сценарий с разными пользователями, случайными паузами и обязательными фоновыми операциями.
  5. Провести тест с мониторингом сервера, а не только с отчётом инструмента.
  6. Прочитать полученные результаты по порогам нормы и записать выводы письменно в отчёт.

Код

Считаем нагрузку и число потоков:

Окно терминала
# средний RPS = обращения в сутки / 86400
echo $(( 1500000 / 86400 ))       # ≈ 17 запросов в секунду
# пиковый RPS = средний × 2..3    # 34 запроса в секунду - им и нагружаем
# один клиент с паузой 30 секунд даёт ≈ 3000 обращений в сутки
# потоки в цепочке = обращения в сутки × доля / 3000
# уникальных тестовых пользователей берут в 2-3 раза больше посетителей

Расчёт занимает пять минут и задаёт масштаб всей работы. Без него тест превращается либо в безобидную проверку, либо в самостоятельную атаку на собственный сервер.

Быстро проверяем один адрес:

Окно терминала
ab -c 20 -n 500 https://example.com/catalog/section/
#   -c - число одновременных запросов, -n - общее число запросов
# вывод: запросов в секунду, время запроса, доля ошибок
# страница из кэша ответит быстро при любом числе потоков

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

Собираем простой сценарий из списка адресов:

Окно терминала
siege -f urls.txt -c 10 -r 10 -d 3
#   -f - файл со списком адресов, -c - пользователи
#   -r - повторения, -d - пауза между обращениями


# urls.txt
# https://example.com/
# https://example.com/catalog/
# https://example.com/search/?q=насос

Список адресов уже похож на поведение посетителя, но всё ещё не знает про авторизацию и корзину. Для сценариев с входом и оформлением берут инструмент со сценариями и подстановкой данных из файла.

Запускаем сценарный инструмент без графики:

Окно терминала
jmeter -n -t plan.jmx -l result.jtl        # -n - консольный режим
jmeter -n -t plan.jmx -R 10.0.0.11,10.0.0.12   # распределённый запуск
# графический режим сам съедает ресурсы и на долгих тестах падает

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

Наблюдаем за сервером во время теста:

Окно терминала
watch -n2 "ss -s | head -3; uptime"
mysqladmin processlist | grep -c Query      # зависшие запросы к базе
tail -f /var/log/php-fpm/bx0-error.log      # ошибки во время нагрузки
# отчёт генератора без картины на сервере объясняет только половину

Клиентские и серверные показатели читают вместе. Рост времени ответа объясняют процессор, диск или очередь к базе, и без этой картины остаётся только констатировать, что «стало медленно».

Проверяем результат по порогам:

Окно терминала
# успешных ответов не меньше 95%, ошибок сервера не больше 5%
# загрузка процессора около 50% - норма, 80-90% - тревога
# уход в подкачку недопустим, ошибок PHP быть не должно
# 90% обращений укладываются в две секунды

Пороги нормы задают общую рамку разговора о результате теста. Сравнение с ними отвечает на вопрос «готовы ли мы» лучше, чем абсолютные числа времени ответа сами по себе.

Ограничения

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

Одна только главная страница о реальной нагрузке ничего не покажет. Она отдаётся из кэша и держит любую нагрузку, а тяжёлыми оказываются фильтр, поиск, корзина и личный кабинет.

Генератор нагрузки сам требует ресурсов. Слабая машина упрётся в свои пределы раньше сайта, и результат будет говорить о ней, а не о сервере.

Результат любого замера стареет вместе с самим проектом. После крупных правок каталога, шаблонов или окружения замер повторяют, иначе он описывает уже несуществующий сайт.

Типичные проблемы

Тест показал отличные числа, а в день акции сайт лёг.

Нагружали только главную страницу и статические файлы самого сайта. Они отдаются из кэша и не отражают нагрузку от фильтра, поиска и оформления заказа.

Результаты нестабильны от прогона к прогону.

Генератор нагрузки упирается в собственные ресурсы или в пропускную способность сети. Числа в этом случае описывают машину генератора нагрузки, а не сайт.

Сайт на тесте быстрый, на боевом медленный.

Тестовая копия сайта наполнена демо-данными в разы меньшего реального объёма. Выборки на почти пустом каталоге отвечают быстро при любой заданной нагрузке.

Все потоки ведут себя одинаково и результат ровный.

Сценарий гоняет одного и того же виртуального пользователя вообще без пауз. Кэш при этом попадает идеально, а реальный трафик так не выглядит.

Непонятно, что делать с результатами.

Цель и критерии успеха не были сформулированы до начала этого теста. Без заданных порогов любое число нельзя назвать ни хорошим, ни плохим.

Частые вопросы

Сколько потоков брать для теста?

Столько, чтобы получить рассчитанный пиковый поток обращений. Число потоков выводят из суточных обращений, доли цепочки и паузы между шагами, а не берут наугад.

Можно ли обойтись простым инструментом?

Для проверки отдельной страницы - да. Для сценария с входом, корзиной и оформлением нужен инструмент, умеющий подставлять данные и держать сессию.

Что смотреть на сервере во время теста?

Процессор с разбивкой на пользовательское время и ожидание диска, память и подкачку, очередь к базе и ошибки в журналах. Одного отчёта генератора мало.

Нужно ли включать в сценарий обмен с 1С?

Да, если он идёт в рабочие часы. Тяжёлый обмен вместе с посетителями - типовой сценарий падения, и проверять его надо вместе, а не по отдельности.

Как часто повторять нагрузочный тест?

Перед сезонными наплывами и после крупных изменений каталога, шаблонов или окружения. Старый замер описывает сайт, которого больше нет.

Смежное

Первоисточник