воскресенье, 27 ноября 2011 г.

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

Писал свой отзыв о конференции 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 :)

Комментариев нет:

Отправить комментарий