Предварительные действия

Подготовьте всё к нагрузочному тестированию. Примерная последовательность таких мер.

Рекомендуем установить на серверы пакет для сбора аналитических метрик системы и базы данных: нагрузка на процессор, диск, память, число и типы запросов к базе данных. Эти метрики доступны «из коробки» в таких пакетах, как munin и Zabbix/Cacti.

  Анализ цепочек использования

Для начала поймите сценарии использования веб-проекта клиентами. Задача облегчается, если есть сайт-прототип, – тогда можно взять его логи и вычленить из них сценарии работы с посетителями. Если веб-проект новый, необходимо описать основные цепочки использования. Например:

• «Гости 1»: Главная->Поиск->Страница товара, 30%
• «Гости 2»: Главная->Поиск->Страница товара->Корзина->Заказ, 3%
• «Гости 3 (перешли по рекламе)»: Страница товара->Страница раздела->Страница товара->Страница сравнения, 5%

Важно помнить:

• Об авторизации
• Сохранении параметров в сессию
• Поисковых строках
• Идентификаторах посещаемых товаров

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

  Расчет и подготовка нагрузочных потоков

На данном этапе происходит настройка нагрузочных потоков в выбранном инструменте создания нагрузки – Jmeter, Яндекс.Танк и аналогах.

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

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

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

Оцените целесообразность тестирования статической и динамической частей веб-системы.

• Обычно тестируют только динамическую составляющую – совершают запросы к php-скриптам (nginx->apache->php).
• Иногда необходимо тестировать скорость отдачи статики (nginx->файл) – в ряде проектов создается интенсивная нагрузка при скачивании большого количества файлов с диска. Это будет замедлять работу веб-сервера и базы данных.

В таких случаях мы рекомендуем рассмотреть локальные или удаленные облачные хранилища: Amazon S3, OpenStack Swift и аналоги.

  Выбор критичных метрик

Метрики «среднего» – арифметического и медиана – подходят большинств проектов. Но бывают исключения.

Время выполнения веб-страницы

Если загрузка веб-страницы в браузер клиента будет выполнена преимущественно по быстрому каналу или размер страниц небольшой, достаточно держаться среднего показателя серверной генерации страницы, например, <0.5 секунды. В противном случае или при относительно тяжелой клиентской части - нужно также оптимизировать размер/скорость загрузки составляющих частей страниц в браузер клиента.

Рекомендуем ввести строгое ограничение, к примеру, 90% запросов должно быть сделано менее чем за 0.15 секунды. При этом могут быть запросы более 1 и 5 секунд. Но в среднем веб-проект будет быстрым для большинства.

Ошибки

Число кодов ответов, отличных от 20*, должно стремиться к нулю. При высокой посещаемости может увеличиться число 50* ошибок.

Основные причины:

• Импорты/экспорты по расписанию и другие регулярные обслуживающие задачи (бэкап).
• Перезагрузка apache/php-fpm.
• Крах процессов PHP из-за доступа к запрещенным разделам памяти

Необходимо:

• Выявлять данные ошибки
• Планировать их уменьшение
• Корректировать настройки и код
• Сводить количество ошибок в конце нагрузочного тестирования к нулю

Бывают более жесткие требования. Например запрет на запросы, которые выполняются дольше 5 секунд, или на превышение доли таких запросов 0.01%. Нагрузочное тестирование покажет причину ошибок и поможет их устранить (или хотя бы снизить).

«Сглаживание»

Ускоряет страницы, которые медленно выполняются из-за сброса больших объемов кэша при импортах-экспортах, технология «композитного кэша»:

• Клиенту быстро отдается контент
• Он отображается в браузере
• Динамическая информация подгружается в фоне с помощью javascript