• Хиты к динамике в сутки;
• Хиты к статике в сутки.

Это важный момент. Например, запустили нагрузочное тестирование, оно прошло успешно, результатом остались довольны. Но не учли тот факт, что в проекте есть каталог с базой данных на 1 млн. объектов. Запустили проект, пошла реальная нагрузка, и системе понадобился экспорт/импорт каталога - и в итоге система может стать неустойчивой или вообще перестанет отвечать на запросы пользователей. Поэтому во время нагрузочного тестирования нужно учитывать подобные критические сценарии и включать их в тест.

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

Рассмотрим пример графика посещаемости за неделю:

Получаем по логам сервера за сутки – 1,5 млн. хитов к динамическим данным. Среднее количество запросов в секунду высчитывается как 1,5 млн./86400 = 17 запросов/сек, но на графике в пике видим 34 запроса/сек.

Поэтому всегда нужно готовиться к пикам выше среднего в 2-3 раза, а точнее - смотреть по графикам и логам сервера, т.е брать для нагрузочного тестирования количество запросов в секунду, исходя из пикового значения нагрузки проекта, а не из среднего.

Важно знать, не перегружена ли текущая веб-система при нагрузочном тестировании. При тестировании, например, нужно следить, не заполнены ли все процессы Apache (mod_status), не допускать скопления очередей на NGINX, запросы к базе данных не должны «висеть» (show processlist) - все это может привести к недостоверным результатам тестирования.

Например, эта перегруженная веб-система может «отбрасывать» запросы:

Примерное количество хитов, которое создает пользователь в секунду - 10. Определить примерную величину можно также по веб-аналитике текущего сайта или с помощью данных внешних источников (например, Google Analytics).

Если тестируется портал компании, то общее количество хитов в сутки считается, исходя из количества сотрудников и продолжительности рабочего дня. Можно также добавить некоторое количество хитов «про запас».

Цепочки - это, по сути, поведение клиентов на сайте, куда будут ходить пользователи/сотрудники. Варианты цепочек берутся из аналитики или придумываются самим (на основе типичного поведения пользователя на сайте данной тематики). Глубокое исследование не требуется, только лишь основное поведение.

Пример цепочки 1:

	1.1 Главная
	1.2 Список новостей
	1.3 Детальная новости
	1.4 Поиск по сайту
		

Пример цепочки 2:

	2.1 Детальная каталога
	2.2 Авторизация
	2.3 Корзина
	2.4 Мастер заказа
	2.5 Личный кабинет
		

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

К примеру, получилось такое распределение путей следования посетителя по сайту:

	70% - Главная
	20% - Каталог – Корзина – Мастер заказа
	5% - Результаты поиска – Описание товара – Корзина
	5% - Новости – Новость детально			
		

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

Создание уникальных пользователей для тестирования также важно, и это также позволяет приблизиться к реальной работе проекта. Все эти данные можно хранить в CSV-файлах и подключать к Jmeter при тестировании. Количество создаваемых пользователей - примерно в 2-3 раза больше прогнозируемого количества посетителей.