Анализ результатов тестирования производительности

Писал свой отзыв о конференции QA Dnepr Mini Conf. И вот добрался написать про то, о чем там рассказывал.
Предлагаю рассмотреть на примере анализ результатов тестирования производительности.

Итак, допустим наша система позволяет покупать электронные товары. Банально, но просто и востребовано. И у нас есть простой скрипт, который эмулирует с разной долей вероятности покупает товар того или иного типа. Одним пользователем за раз. Это не просто пример, а настоящий тест на живой системе.

Для простоты собираем:

• Время отклика
• Хронологию отсылки запросов (календарное время)
• Код ответа сервера
• Объем пакета запроса
• Ответ сервера в случае ошибки

Первым делом смотрим на summary и, самое главное, ошибки. В нашем примере были следующие результаты

Action	#Samples	Error	Average	Min	Max	Deviation	Throughput	KB/sec	Avg. Bytes
login.htm	574	0,000%	79	35	2100	128,441	0,778	9,86	12986,8
/login	568	2,641%	5148	58	302853	33130,904	0,646	222,83	353006,5
Open Checkout	391	0,000%	391	190	5112	384,271	0,445	30,05	69134,1
Checkout	391	0,256%	2357	218	301873	15272,030	0,444	30,88	71167,4
/logout	564	0,709%	3043	4	300936	25173,124	0,770	262,45	349068,4
GB Checkout	177	0,000%	5410	198	16959	2626,076	0,277	19,83	73264,0
TOTAL	2665	0,75%	2521	4	302853	20169,2	3,013	521,88	177359,2

Как мы видим у нас были ошибки по время теста. Немного, но они все же были. Поэтому следующий шаг проанализировать характер ошибок, их количество и степень влияния. Т.к. тип ошибок, общее количество по типам и время отклика таких ошибочных запросов. Получилась следующая картина.

По характеру

Code title	Response Code	# of Rqsts	% of Errors
OK	200	2666
Internal Server Error	500	8	40,00%
Non HTTP response message: Unexpected end of ZLIB input stream	Non HTTP response	12	60,00%

И характеристики времени отклика по типам ошибок

500			Non HTTP
Average	470.1		Average	301592.8
Min	75		Min	300399
Max	4397		Max	305086

Как видим у нас были ошибки клиента, с длинным временем отклика.
Следующим шагом нам очень хочется увидеть распределение во времени времени ответа сервера. Не будем томиться и посмотрим.

Мы видим 12 всплесков по длительности приблизительно равные 300000 мс.И если наложить такую же информацию, но только по ошибкам, то всплески точно совпадут с Non HTTP ошибками. Это ошибки клиента и их можно убрать из анализа, без риска получить неверные результаты.

Убираем несущественные для нас выбросы. В итоге получим следующую картину.

В целом мы видим относительно равную картину. Нет явного увеличения. А если учесть, что здесь не однотипные запросы, то что-то можно сказать только про несколько явных всплесках до 18ти секунд.

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

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

И мы можем заметить, что у нас есть большое количество запросов длиной в 1с +- (более 20%). А также немалое количество запросов (более 10%), время отклика которых мало, т.е. лежит в диапазоне 20-60 мс.

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

Возьмем, один из запросов на покупку. Посмотрим распределение времени ответа. Этот запрос я разбирал вручную, посчитав количество вхождений запросов в тот или иной интервал по времени отклика.

На этом графике также видны "быстрые" запросы. Просматривая результаты по таким коротким ответам я заметил одну вещь, сделал некоторые подсчеты и получил. Что часть запросов, однотипных запросов, отличалась по размеру пакета. Это справедливо для всех запросов. Для этого же типа следующие результаты:

Как мы видим, чуть более 80% всех запросов были "нормальными". Часть(7%) была "битых", а часть (>10%!) - "пустыми".
На этом этапе нужно сделать выводы о состоятельности теста. Такие ошибки оказались "на совести" инструмента. И желательно тест переделать:

• посмотреть, что будет на следующем этапе
• последить за нагрузкой клиентской машины
• и за сервером - не всегда проблема только в клиенте. Хотя за сервером надо всегда следить

Мы переделали тесты. Немного подправили нагрузку и получили похожие результаты. И надо выдать один секрет. В системе существует асинхронная обработка покупок. И очень критичные проблемы мы нашли именно там.

Основные моменты

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

Enjoy :)