[Из песочницы] Нагрузочное тестирование Web-систем. Как к нему подготовиться
Комментарии (2)
11 июля 2017 в 15:42 (комментарий был изменён)
0↑
↓
На самом деле, Ваши трактования не совсем верны. В первую очередь нужно менее широко, на этапе планирования, определить что Вы хотите измерить, ведь нагрузочное тестирование это целый пул смежных и не очень задач по тестированию системы.В контексте несущего сервера, можно полностью отбросить статику и ресурсы от третьих сторон, так как нас интересует именно состояние нашего сервера, а не то, что происходит у юзера на UI (где-то UI не догрузился, где то js запарился)
Второй момент, недостаточно получить лишь HPS график, так как он не несет реальной пользы в исследовании сервера: скриптов, базы, кешей.
Из второго момента, так же следует понимать между абсолютной нагрузкой и взвешенной. Нередко проводя тесты, и приводя какие-то обоснованные результатами доводы я слышу «Тю, чувак, та такого быть не может — мы ж тут все кешируем/прелоадим/anyway» — как пример того что многие не понимают целей лоуд теста.И одно из последних, для реально взвешенного лоуда, нельзя полагаться на методику «размазывания запросов», она естественно дают некие приближенные цифры производительности, но лучше всего в реальной системе, на проде, иметь некоторые метрики снятые всякими статистик сервисами (гуглометрика, яндекс метрика). При таком подходе, можно иметь взвешенную цифру запросов с секунду для одного реального пользователя, а его плотность запросов — как объект для построения своих тест-сьютов для лоуда-тестинга.
В целом, при простом тестировании в первом приближении, достаточно обзавестись лог-мониторингом (CPU/RAM), базы, и просто стабильно нагружать сервер одним запросом, уверен, даже при таком подходе Вы найдете большое количество недочетов в веб-приложении, и дальнейший анализ логов, уже более точно скажет куда нужно копать, для рефакторинга… у меня в 90% случаев, после первичного просмотра, дела сразу уходят в профилирование базы, изучения запросов, выдаче slow-log и его анализа.
11 июля 2017 в 16:02
0↑
↓
Фактически большинство так и теструют — каждые микросервисы отдельно. Более того, я тоже так делаю, потому что порой необходимо выделять проблемы микросервисов или кэширующих прокси серверов и т. д.Я не предлагаю отказываться от их тестирования, я всего лишь предлагаю выполнять тестирование всей системы перед продакшеном. Конечно, нагружая сервер даже одним запросом вы можете выявить большую часть проблем.
Возьмем в качестве примера on-line кабинет организации. При входе в него начинают загружаться данные. Связь с базами данных будет работать на отлично — мы же это проверили и нагрузили. Но вот CSS или JS могу не успеть загрузиться, а следовательно внешний вид кабинета будет полностью не работоспособный. Его UI может на столько «разъехаться», что возможно дальнешее его использование пользователю не понравится и он от него откажется. Отбросив сторонние ресурсы, есть вероятность потерять пользователей на этапе ознакомления с системой. Он может просто обновить страницу и у него уже все может быть хорошо. Не все пользователи терпеливые.
