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

Хорошие практики нагрузочного тестирования: гайд для тех, кто успел до «пожара»

Время на прочтение9 мин
Количество просмотров9.4K
Всего голосов 8: ↑7 и ↓1+10
Комментарии1

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

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


Я наверное не открою Америки, но для стресс тестов вебприложения, мы берем access логи за 1..2 месяца и на их базе формируем список ресурсов для тулзы, которая обеспечивает нагрузку при стресс тестировании. 2 основных кейса обычно:

1) as is , то есть все дневные логи объединяются в один и все это запускается неким кол-вом потоков в сторону тестового стенда

2) согласно целям теста, логи отфильтровываются по каким-либо правилам, исключаются какие то разделы или например оставляем только те запросы, которые в логах имеют код ответа не равный 200 и т.д.

Варьируя кол-во потоков и случайность задержки между ними, можно имитировать нарастающую нагрузку, постоянную нагрузку, пиковую нагрузку и так далее

Минус - нельзя автоматизировать воспроизведение POST запросов для создания нагрузки максимально приближенной к реальной. Это да. Но это зависит от вебприложения уже.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий