Обзор инструментов нагрузочного тестирования

Александр Демидов«1С-Битрикс»

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

Зачем?

Проверка и оптимизация конфигурации оборудования, виртуальных машин, серверного программного обеспечения

Оценка максимальной производительности, которую способен выдерживать проект с типовыми сценариями нагрузки на доступных ресурсах

Влияние модулей проекта на производительность, сценарии обработки пиковой нагрузки

Оценка стабильности при максимальных нагрузках при проведении 24-часовых тестов с учетом внешних факторов (импорты, резервное копирование и т.п.)

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

А как трактовать результаты?

Только определив требования вместе с заказчиком

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

Количество хитов в сутки

Скорость загрузки главной страницы при указанном количестве хитов

Скорость загрузки критичных разделов

Среднее время загрузки всех страниц в сутки

Процент страниц с временем загрузки более n сек.

Допустимый процент ошибок

Допустимое время простоя

...

Начнем с простого…

Apache HTTP server benchmarking tool

ab [options] [http[s]://]hostname[:port]/path

где основные необходимые options:

-c concurrency количество одновременных запросов к серверу (по уолчанию 1)

-n requests общее количество запросов (по умолчанию 1)

ab

Concurrency Level: 10Time taken for tests: 0.984 secondsComplete requests: 100Failed requests: 0Write errors: 0Total transferred: 3725507 bytesHTML transferred: 3664100 bytesRequests per second: 101.60 [#/sec] (mean)Time per request: 98.424 [ms] (mean)Time per request: 9.842 [ms] (mean, across all concurrent requests)Transfer rate: 3696.43 [Kbytes/sec] received

Connection Times (ms) min mean[+/-sd] median maxConnect: 1 2 3.6 1 23Processing: 63 94 21.5 90 173Waiting: 57 89 21.6 84 166Total: 64 96 21.5 92 174

ab

Плюсы:Есть везде, где есть Apache

Не требует никакой дополнительной настройки

Очень простой инструмент

Минусы:Очень простой инструмент

По сути – тестирует только производительность веб-сервера: опрашивает только один URL, не поддерживает сценарии нагрузки

Чуть сложнее – Siege

Joe Dog Softwarehttp://www.joedog.org/siege-home/

Многопоточный

Можно задавать как количество запросов, так и продолжительность (время) тестирования

Поддерживает простейшие сценарии

Siege

# cat urls.txt# URLS file for siege# --

http://www.bitrix24.ru/http://www.bitrix24.ru/support/forum/forum1/topic3469/?PAGEN_1=2http://www.bitrix24.ru/register/reg.php POST domain=test&login=loginhttp://www.bitrix24.ru/search/ POST < /home/www/siege_post_data

# siege -f urls.txt -c 10 -r 10 -d 3

Siege

HTTP/1.1 200 0.44 secs: 12090 bytes ==> GET /HTTP/1.1 200 0.85 secs: 29316 bytes ==> GET /support/forum/forum1/HTTP/1.1 200 0.85 secs: 29635 bytes ==> GET /support/forum/forum1/HTTP/1.1 200 0.34 secs: 12087 bytes ==> GET /

[...]

done.

Transactions: 100 hitsAvailability: 100.00 %Elapsed time: 12.66 secsData transferred: 1.99 MBResponse time: 0.64 secsTransaction rate: 7.90 trans/secThroughput: 0.16 MB/secConcurrency: 5.02Successful transactions: 100Failed transactions: 0Longest transaction: 1.06Shortest transaction: 0.31

Боевые сценарии тестирования

URL’ы для сценариев можно взять из логов веб-сервера

Похожий инструмент - httperf

http://www.hpl.hp.com/research/linux/httperf/30 Jan 2008: visit our sourceforge page at http://sourceforge.net/projects/httperf

http://sourceforge.net/projects/httperf/As of 2009-12-24, this project may now be found at http://code.google.com/p/httperf/.

https://code.google.com/p/httperf/2013-05-28 - Ted BullockFigured out my lost account to access the httperf repository. Although I am not currently doing active development for httperf, you can now submit bug reports and I will be able to receive them.

Сложнее… и функциональнее

Apache JMeter http://jmeter.apache.org/

Java

HTTP, HTTPS, SOAP, Database via JDBC, LDAP, SMTP(S), POP3(S), IMAP(S)

Консоль и GUI

Распределенное тестирование

План тестирования – XML

Может обрабатывать лог веб-сервера как план тестирования

Визуализация результатов в GUI

JMeter

JMeter

Tsung

http://tsung.erlang-projects.org/

Erlang

HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP, Jabber/XMPP

Консоль (GUI через сторонний плагин)

Распределенное тестирование (миллионы пользователей)

Фазы тестирования

План тестирования – XML

Запись плана с помощью Tsung recorder’а

Мониторинг тестируемых серверов (Erlang, munin, SNMP)

Инструменты для генерации статистики и графиков из логов работы

tsung_stats.pl

tsung_stats.pl + Gnuplot

WAPT

http://www.loadtestingtool.com/

Windows

Платный (есть триал на 30 дней / 20 виртуальных пользователей)

Запись плана тестирования из десктопных и мобильных браузеров

Зависимости в планах тестирования (последующий URL в зависимости от ответа сервера)

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

WAPT – профили тестирования

Название профиля Виртуальных пользователей / сессия

Время на “раздумья” между кликами (сек)

Add users per second

Connection speed

Старт, max users, long TT, slow connection

2800 9 - 25 10 256k DSL

Старт, mid users, short TT, fast connection

450 0 - 5 5 Max

Authorized users 200 9 - 25 5 256k DSL

Non-Authorized users 1800 9 - 25 5 256k DSL

WAPT – отчеты

Авторизованные сессии Неавторизованные сессии По всем сессиям

Avg page exec time (PHP), sec 0,058

Avg response time, sec 0,28 0,075 0,09

(with page elements) 0,644 0,105 0,135

Pages 616149 8198999 8815149

Pages per second 7,1 94,9 102,0

Hits 2 054 456 40 655 930 42 710 386

Hits per second 23,80 471,00 494,33

Active users 40 260 300

Sessions 20 515 341 429 361 944

Sessions per second 0,24 3,95 4,19

HTTP errors, %, не более 0,05

Не забываем о родных инструментах

Инструменты тестирования в «Битриксе»

Нюансы…

Полноценные длительные нагрузочные тесты проводите в близких к «боевым» условиях (импорты, бэкапы и т.п.)

Проводите тесты на полном наборе данных

В идеале – распределенные тесты

Совсем в идеале – территориально распределенные

Каким бы идеальным не был сценарий – он будет лишь «искусственным» повторением боевой нагрузки

Например, влияние «Веб-аналитики»

На 12-часовом тесте – значительно падение скорости генерации страниц:

• потребление mysqld до 120% ядра CPU

• load average – до 12-13

«Веб-аналитика»

Максимальное время выполнения у запроса к B_STAT_SESSION, который выполняется по индексу (IP_FIRST_NUMBER,DATE_STAT типа Date).

Генерация нагрузки – с одного IP адреса. Соответственно индекс обладал нулевой избирательностью.

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

mysql > update b_stat_session set IP_FIRST_NUMBER = FLOOR(1520000000 + RAND() * (232669));

Резюме

Обязательно проводите полноценное нагрузочное тестирование перед стартом проекта

В процессе эксплуатации быстро определить «запас» «узких» мест можно с помощью простых инструментов (ab, встроенный тест «Битрикса»)

Для полноценных тестов – инструменты, максимально близко имитирующие пользователей

Перед выкладыванием апдейтов на «бой» проводите нагрузочные тесты

Чем серьезнее меняется логика приложения – тем тщательнее должен быть тест (в идеале – полноценный суточный)

Проводите тесты, имея настроенную систему мониторинга

Спасибо за внимание! Вопросы?

Александр Демидовdemidov@1c-bitrix.ru+7-926-521-3700 @demidovhttp://www.1c-bitrix.ru