Обзор инструментов нагрузочного тестирования Александр Демидов «1С-Битрикс»

Обзор инструментов
нагрузочного тестирования
Александр Демидов
«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:
Time taken for tests:
Complete requests:
Failed requests:
Write errors:
Total transferred:
HTML transferred:
Requests per second:
Time per request:
Time per request:
concurrent requests)
Transfer rate:
10
0.984 seconds
100
0
0
3725507 bytes
3664100 bytes
101.60 [#/sec] (mean)
98.424 [ms] (mean)
9.842 [ms] (mean, across all
3696.43 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median
Connect:
1
2
3.6
1
Processing:
63
94 21.5
90
Waiting:
57
89 21.6
84
Total:
64
96 21.5
92
max
23
173
166
174
ab
Плюсы:
Есть везде, где есть Apache
Не требует никакой дополнительной настройки
Очень простой инструмент
Минусы:
Очень простой инструмент
По сути – тестирует только производительность веб-сервера: опрашивает
только один URL, не поддерживает сценарии нагрузки
Чуть сложнее – Siege
Joe Dog Software
http://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=2
http://www.bitrix24.ru/register/reg.php POST domain=test&login=login
http://www.bitrix24.ru/search/ POST < /home/www/siege_post_data
# siege -f urls.txt -c 10 -r 10 -d 3
Siege
HTTP/1.1
HTTP/1.1
HTTP/1.1
HTTP/1.1
200
200
200
200
0.44
0.85
0.85
0.34
secs:
secs:
secs:
secs:
12090
29316
29635
12087
bytes
bytes
bytes
bytes
==>
==>
==>
==>
GET
GET
GET
GET
[...]
done.
Transactions:
Availability:
Elapsed time:
Data transferred:
Response time:
Transaction rate:
Throughput:
Concurrency:
Successful transactions:
Failed transactions:
Longest transaction:
Shortest transaction:
100
100.00
12.66
1.99
0.64
7.90
0.16
5.02
100
0
1.06
0.31
hits
%
secs
MB
secs
trans/sec
MB/sec
/
/support/forum/forum1/
/support/forum/forum1/
/
Боевые сценарии тестирования
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 Bullock
Figured 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
Avg response time, sec
(with page elements)
Pages
Pages per second
Hits
Hits per second
Active users
Sessions
Sessions per second
HTTP errors, %, не более
По всем сессиям
0,058
0,28
0,075
0,09
0,644
0,105
0,135
616149
8198999
8815149
7,1
94,9
102,0
2 054 456
40 655 930
42 710 386
23,80
471,00
494,33
40
260
300
20 515
341 429
361 944
0,24
3,95
4,19
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
@demidov
http://www.1c-bitrix.ru