Цель — оценить стабильность работы сайта под определенной нагрузкой. Также небольшим постоянным числом запросов к сайту можно «прогревать» кэш на сайте. Если нам нужно провести benchmark — измерить поведение системы при разной нагрузке, мы может создать несколько классов поведения и провести несколько тестов при разных нагрузках. Без оптимизации запросов к БД на товарных страницах и страницах каталога со сброшенным кэшем сайт не способен выдержать даже малую нагрузку. Инструменты могут воспроизводить любой сценарий поведения пользователя в интернет-магазине и собирать метрики для отчета о нагрузочном тестировании.
В качестве инструмента нагрузочного тестирования — Яндекс Танк с модулем Phantom. Phantom отличается высокой производительностью, но не позволяет генерировать POST-запросы — мы не можем проверить сценарии отправки отзывов, авторизации на сайте и добавления товаров в корзину. Поэтому мы оценивали количество запросов в секунду, которое может выдержать сайт, без анализа добавления товаров в корзину. RPS — число запросов в секунду на страницы сайта, которые производили при нагрузочном тестировании. Показывает примерное количество запросов, после которого был прерван тест — либо из-за отсутствия ответа по сети, либо из-за ошибок в HTTP запросах.
Мы проанализировали ведущие интернет-магазины, результаты исследований, свой опыт и собрали важные моменты в одно руководство. Делаем e-commerce лучше, поэтому не только пользуемся сами, но и делимся с вами. Мы провели несколько тестов и получили результаты, которыми поделимся ниже. Пробный «обстрел» для проверки конфигурации, примерных лимитов и шагов наращивания интенсивности, выявление ошибок конфигурации тестового задания.
Цель — оценить возможности ресурса в критических ситуациях, выявить слабые места. На второй вкладке можно посмотреть графики нагрузки в режиме реального времени. В случае, если сервер падает при определенной нагрузке или его поведение меняется, на графике это будет сразу видно. Следующее несколько функций — запросы, за счет которых будет создаваться нагрузка. Опять же, нам не нужно обрабатывать ответ сервера — результаты пойдут сразу в статистику. Я добавил только переменную base_url, которая должна содержать полный адрес тестируемого ресурса.
Пропуская импорты, в самом начале мы видим 2 почти одинаковые функции логина и логаута, состоящие из одной строчки. L.client — объект HTTP сессии, с помощью которой мы будем создавать нагрузку. Мы используем метод POST, почти идентичный такому же в библиотеке requests. Почти — потому что в данном примере мы передаем в качестве первого аргумента не полный URL, а только его часть — конкретный сервис.
Свойству tasks мы передаем словарь методов, которые будет вызывать пользователь и их частоту вызовов. Когда речь заходить о тестировании производительности — в первую очередь все думают о JMeter’е — он бесспорно остается самым известным инструментом с самым большим количеством плагинов. Мне же JMeter никогда не нравился из-за неочевидного https://deveducation.com/blog/nagruzochnoe-testirovanie-rukovodstvo-dlya-nachinayushchikh/ интерфейса и высокого порога вхождения, как только возникает необходимость протестировать не Hello World приложение. Как увеличить скорость загрузки сайта или интернет-магазина на Битрикс и как это скажется на конверсии. С «прогретым» кэшем на текущих серверах сайт способен выдерживать существенные нагрузки — более 300 RPS.
Как видим, здесь указан сервер, который мы будем тестировать — именно к этому URL будут добавлятся адреса сервисов из файла теста. Описанные далее примеры можно классифицировать как black-box функциональное нагрузочное тестирование. Даже не зная ничего о тестируемом приложении и не доступа к логам, мы можем измерить его производительность. При достижении примерно 11 запросов в секунду нагрузка на базу данных выросла до 100%.
На тестируемом оборудовании без кэша эталонные демо-сайты показали существенную производительность, что дало основание изучать код сайта на предмет его оптимизации, а также оптимизации запросов к БД. База данных тоже была загружена не более чем на 30%, а зачастую меньше. Тест прервался по причине сетевой недоступности из-за повышенной нагрузки на канал связи. На внешнем сетевом интерфейсе web-сервера сайта загрузка канала превысила 800 мегабит в секунду. Постоянная — предполагает постоянную нагрузку, количество «пользователей» не меняется со временем.
Тест имитирует увеличение числа посетителей на сайте, чтобы оценить, насколько ресурс справляется с нагрузкой и как обрабатывает запросы посетителей. Следом за нагрузочным тестированием мы провели глубокий технический аудит сайта. Сделали рефакторинг компонентов и исправили все выявленные в результате аудита проблемы.
Мне достаточно часто приходится использовать различные онлайн-сервисы для проверки доступности сайтов и их поверхностных тестов и проверок. Тестирование масштабируемости для проверки способности системы работать стабильно при увеличении нагрузки, при этом время отклика и затраты на проект не должны увеличиваться. Нагрузочное тестирование входит в разряд автоматизированного тестирования, проведение которого позволяет сэмулировать нагрузку на систему, чтобы проверить ее стабильность, работоспособность и масштабируемость.
Ресурсы серверов (особенно сервера БД) имеют большой запас по мощности и после проведения рекомендуемых оптимизаций могут быть сильно избыточными. Как показал краткий опрос коллег — почти у всех эти наборы сервисов отличаются.
Непосредственно тестирование — его лучше выполнить несколько раз. Тестировать стойкость к нагрузке нужно, чтобы сервер не «лег» при запуске сайта или из-за увеличения количества посещений. Процедура не застрахует от некорректной работы при нагрузках, но поможет понять реальную пропускную способность сайта.
Restauración 57, Santiago, República Domincana Tel.: 809-580-1171