Представление результатов нагрузочного тестировани

Представление результатов сравнительного нагрузочного тестирования
Публикация компании IT-Online, автор Дмитрий Сатин
Библиотека / Тестирование

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

Не совсем понятно почему весь анализ результатов нагрузочного тестирования свелся к тому, что вырос CPU. А как же response time основных операций на сайте? Неужели новая версия работала также шустро, как и прежняя, и только показатель CPU был выше?

Дмитрий, я предложил несколько комментариев на сайте статьи в блоге IT-Online - думаю как появятся ответы, надо как-то скомпилировать обе ветки обсуждений.

PS
Дмитрий, загляните в мой блог :)

Не совсем понятно почему весь анализ результатов нагрузочного тестирования свелся к тому, что вырос CPU. А как же response time основных операций на сайте? Неужели новая версия работала также шустро, как и прежняя, и только показатель CPU был выше?

Дмитрий, не совсем точно. Анализировалось много показателей. Система состоит их двух сайтов каждый из которых, работает в NLB-кластере: два web-сервера, которые обращаются к одному серверу баз данных.

Для web-серверов фиксировались:

AnonymousUsers_sec
CurrentAnonymousUsers

Для всех трех серверов:

Memory_AvailableMBytes
PhysicalDisk_Total_CurrentDiskQueueLength
Processor_Total_ProcessorTime

Таким образом 15 счетчиков.

Кроме того, анализировалось время отклика 33 транзакций. Дополнительно, анализировались логи web-серверов, с целью, убедиться, что частота создаваемая генератором, одинакова для обеих версий.

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

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

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

Дмитрий Сатин
IT-Online

P.S. Кстати. Именно на этих испытаниях я заметил интересную вещь, о которой мог, впрочем, догадаться раньше и без этих работ. Время реакции системы напрямую не связано с тем, насколько система утилизирует ресурсы.

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

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

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

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

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

Фраза построена неудачно и допускает множественное толкование. Боясь, я ее просто не понял.
Кстати, а если это не новая версия, а просто новый продукт?

мы внесли изменения в процедуры опубликования новых версий

А что такое "процедура опубликования"? Для меня это помещение программистом новей версии в репозиторий кода. Может быть имелось в виду установка новой версии на рабочий (боевой) стенд?

Мы хотели быть уверены, что новая версия система не тратит больше ресурсов, чем текущая версия.

Зачем? Если требования по производительности выполняются, то на фига козе баян?

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

Это разные категории. Отделите мух от котлет.

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

Присоединюсь к коллегам. Это неправильно.

На помощь приходит статистика.

Прошу прощения за резкость, но посмотрите вот этот материал: http://rsdn.ru/artic...Towrite.xml#ELD
-------------------------------------------------------------
Я не рекомендую читателям нашего сайта использовать статистические методы этой статьи в своей работе ввиду наличия ряда логических и фактических ошибок.

P.S. Кстати. Именно на этих испытаниях я заметил интересную вещь, о которой мог, впрочем, догадаться раньше и без этих работ. Время реакции системы напрямую не связано с тем, насколько система утилизирует ресурсы.

Именно. Следовательно ...

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

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

Да... Статья вызывает вопросы.

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

Нагрузочное тестирование НЕ СЛУЖИТ определению НАЛИЧИЯ или ОТСУТСВИЯ узких мест в системе. НЕСУЩЕСТВУЕТ систем без узких мест! Они есть всегда и везде!

Назначение нагрузочного тестирования в выявлении проблем производительности системы (фактически - дефектов производительности). Это означает, что производительность системы НЕ СООТВЕТСТВУЕТ установленным КРИТЕРИЯМ. Узкое место системы принимает статус дефекта на основании факта не соотвествия установленному критерию.

КРИТЕРИЕВ производимтельности существует только ДВА:
- время отклика системы;
- количество обрабатываемых транзакций (или данных) в единицу времени.
ВСЕ! Больше критериев нет.

Если в результате тестирования было выявлено, что система ПРИ ОПРЕДЕЛЕННОЙ МОДЕЛИ НАГРУЗКИ удовлетворяет критериям производительности, то дальнейшее исследование системы - пустая трата времени. Если нет, то производится системный анализ с целью локализации узкого места, выявленного в ходе тестирования. И здесь уже используются разные счетчики и дополнительные тесты.

Факт исправления дефекта производительности не означает устранения узких мест. Это всего лишь означает, что узкое место расширено и на смену ему выступила другая проблема. Нужно ли ее устанять? Это должно определяться на основании КРИТЕРИЕВ.

Следовательно, для проведения тестирования нужны следующие исходные данные:
1. Модель нагрузки (их может быть много, для каждой ситуации).
2. Критерии успешности тестов (или не успешности).

Модель нагрузки включает в себя не только поведение пользователей, но и исходные данные системы, на которой производятся операции (hard-, software, объем и структура данных). Исходя из разных предпосылок (например, ежегодное увеличение объема обрабатываемых данных) строятся различные модели нагрузок.

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

КРИТЕРИЕВ производимтельности существует только ДВА:
- время отклика системы;
- количество обрабатываемых транзакций (или данных) в единицу времени.
ВСЕ! Больше критериев нет.

А количество пользователей (включая профиль нагрузки) куда отнести в такой случае? :)

Чисто логически производительность это операции/время, то есть примерно "скорость", но интересует ещё потенциальная возможность "а насколько больше мы можем" или например "а что будет если будет + 100 польователей".

SALar,

Вы наверное экстрасенс!


Я их и пишу, только пока все складывается в стол. То, что-то не доработал, то времени нет закончить. Но я уже решил, что пора их куда-нибудь выложить. Собираюсь свой сайт открыть. Жду, когда РБК-Софт мне позвонит и назначит рандеву с курьером, а они все не звонят и не звонят. У меня уже сомнения стали появляться. Может и нет там никого, за пользовательским интерфейсом?

КРИТЕРИЕВ производимтельности существует только ДВА:
- время отклика системы;
- количество обрабатываемых транзакций (или данных) в единицу времени.
ВСЕ! Больше критериев нет.

А количество пользователей (включая профиль нагрузки) куда отнести в такой случае? :)

Чисто логически производительность это операции/время, то есть примерно "скорость", но интересует ещё.

Количество пользователей - это модель нагрузки. Сами по себе они не могут являться первичным критерием, так как система может устойчиво работать с разным количеством пользователей.

Следовательно, чтобы определить, удовлетворяет ли нас то, как система работает с 200 пользователями (например), нам нужен еще один критерий. Такой первичный критерий - есть время отклика системы (или количество транзакций).

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

Если продолжить предыдущую мысль, то существует две проблемы.

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

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

Вот эти критерии и использовали для тестирования Интернет приложений. С другими типами - беда.

2. Моделирование нагрузки.
Этот пункт можно так же разделить на два раздела.
а. Моделирование поведения пользователя. Может включать очень многие параметры, в том числе разное количество пользователей.
б. Моделирование тестовой среды. Идеальный вариант - когда тестовая среда повторяет реальную.

Как я уже писал в одном из своих постов - в основе любой проблемы лежит базис, который можно объяснить на пальцах. Но дальше вступают в действие дополнительные условия, реализация которых требует большех знаний и опыта.

Никто не может сказать как быстро должна работать система. Хотя бизнес аналитики и должны вырабатывать эти данные, но как-то не получается это у них. 

Эт-то точно.

- до 1 сек - пользователь считает, что работает с системой реального времени;
- до 8/10 сек - пользователь замечает задержку, но не успевает переключить внимание на другое занятие.

Я выделяю следующие диапазоны:
до 0.1 сек
0.1 - 1
1 - 10
Более 10

Для сайтов вводят еще такую границу как 3 сек. Но причина тут скорее техническая, а не человеческая, так что этой границей мы можем пренебречь.

Как я уже писал в одном из своих постов - в основе любой проблемы лежит базис, который можно объяснить на пальцах. Но дальше вступают в действие дополнительные условия, реализация которых требует большех знаний и опыта.

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

КРИТЕРИЕВ производимтельности существует только ДВА:
- время отклика системы;
- количество обрабатываемых транзакций (или данных) в единицу времени.
ВСЕ! Больше критериев нет.

А количество пользователей (включая профиль нагрузки) куда отнести в такой случае? :)

Чисто логически производительность это операции/время, то есть примерно "скорость", но интересует ещё.

Количество пользователей - это модель нагрузки. Сами по себе они не могут являться первичным критерием, так как система может устойчиво работать с разным количеством пользователей.

Следовательно, чтобы определить, удовлетворяет ли нас то, как система работает с 200 пользователями (например), нам нужен еще один критерий. Такой первичный критерий - есть время отклика системы (или количество транзакций).

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

Показателей производительности существует только ОДИН:
Сколько пользователей смогут комфортно работать.

- время отклика системы - служит для определения комфортно / некомфортно / не могут совсем
- количество обрабатываемых транзакций (или данных) в единицу времени + модель нагрузки = число пользователей.

Количество транзакций, графики производительности и прочее и прочее и прочее - оставьте менеджерам, маркетолагам, девелоперам и т.д.
А мне как конечному пользователю нужно, чтобы при игре 2х2, все протосами и все используют батоны - StarCraft не тормозил (время отклика в пределах 0.1 сек и не более) на пятисотом целероне с 128 RAM. ВСЕ! Мне больше ничего не нужно.
То что после исправлений время отклика увеличилось / уменьшилось в 50 раз, с 0,001 до 0,05 сек, мне наплевать.
Ps. Пока мы не будем играть 4х4 на первом пне.

Количество пользователей - это модель нагрузки. Сами по себе они не могут являться первичным критерием, так как система может устойчиво работать с разным количеством пользователей.

Следовательно, чтобы определить, удовлетворяет ли нас то, как система работает с 200 пользователями (например), нам нужен еще один критерий. Такой первичный критерий - есть время отклика системы (или количество транзакций).

Не согласен.

Количество пользователей, которых может обслуживать система также является как вы определяете "первичным показателем". Сталкивался и не раз с ситуацией, когда при 100 работает в пределах нормы, а при коннекте 100+1 начинаются проблемы у всех 100, при чем проблемы не по времени, а банально с коннектом. И тут уже время реакции всех волнует мало.

Нагрузочное тестирование может и должно отвечать на вопросы о масштабируемости системы "сколько еще пользователей система может обслуживать без потери производительности". Время реакции тут является только показателем: вписываемся мы в показатель "работает" или уже нет. Да, производительность упала, но пользователи могут работать - тест прошел.

Кстати, как верно отметил SALar - время является только мерилом. Для меня задача нагрузочного тестирования это определение порога производственной нагрузки.

Количество пользователей - это модель нагрузки. Сами по себе они не могут являться первичным критерием, так как система может устойчиво работать с разным количеством пользователей.

Следовательно, чтобы определить, удовлетворяет ли нас то, как система работает с 200 пользователями (например), нам нужен еще один критерий. Такой первичный критерий - есть время отклика системы (или количество транзакций).

Не согласен.

Количество пользователей, которых может обслуживать система также является как вы определяете "первичным показателем". Сталкивался и не раз с ситуацией, когда при 100 работает в пределах нормы, а при коннекте 100+1 начинаются проблемы у всех 100, при чем проблемы не по времени, а банально с коннектом. И тут уже время реакции всех волнует мало.

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

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

В жизни, конечно же, не все так однозначно. Можно ввести еще зону опасности. Например, 20 секунд. Если не укладываемся в этот критерий, то в следующем релизе при наличие времени можно будет посмотреть, что там тормозит процесс. Но в этом релизе время на устранения дефекта производительности не тратим, так как тест удовлетворяет формальным требованиям.

Нагрузочное тестирование может и должно отвечать на вопросы о масштабируемости системы "сколько еще пользователей система может обслуживать без потери производительности". Время реакции тут является только показателем: вписываемся мы в показатель "работает" или уже нет. Да, производительность упала, но пользователи могут работать - тест прошел.

Кстати, как верно отметил SALar - время является только мерилом. Для меня задача нагрузочного тестирования это определение порога производственной нагрузки.

Что имеется ввиду под порогом производительности? Момент, когда система сломается? А если система написана истинными коммунистами и она тормозит но не ломается, тогда что?

Критерий может быть один - время обработки запроса. Пользователю до лампочки, сколько еще, таких же как он, терзает систему. Хоть 100, хоть 1000000. Если он ждет больше 10 секунд, то ... его уже нет. Он у конкурентов, которые работают быстрее.

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

Философия получается, Сергей. "Как посмотреть"?

Я отталкиваюсь от определения нагрузочного тестирования, которое предлагает RUP:
Load testing is a performance test which subjects the target-of-test to varying workloads to measure and evaluate the performance behaviors and ability of the target-of-test to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues).

Как видим response times и transaction rates вообще вынесено в дополнения, но никак не ложится в основу.

Пример приведенный вами работает для веб-сайтов (магазинов), где время отклика в условиях наличия в пространстве солидного количества аналогов имеет значение: "не купит у нас - пойдет туда где быстрее". Но это узко, как по мне.

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

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

Но не все равно Системе. Мы ведь тестируем Систему, а не пользователей. Я говорю о бизнес системах (операционисты, обрабатывающие запросы никуда не уходят, у них нет другой системы - они просто проваливают план и компания просто несет убытки), но никак не о частном случае пользователя веб-сайта, которого не устраивает скорость загрузки сайта (зачастую, кстати не является критерием выбора магазина - я например на цену и доставку смотрю в первую очередь).

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

Снова узко смотрим, как по мне. Другой вопрос масштабируемости: "А если разнести на 2 сервера и load balancer поставить?", "А если на тот же сервер поставим еще один application server", "У нас два новых аналитических запроса появились, что скажут операционисты если у них упадет формирование остатков по складу с 2 секунд до 30? Оптовик с телефона уйдет или прокатит?"

При тестировании масштабируемости модель нагрузки изменяется, тут все верно, но модель нагрузки зависит не только от количества пользователей, но и от их количества в группах, от аппаратной платформы и т.д.: 100 операционистов и 2 аналитика, это не тоже самое что 98 операционистов и 4 аналитика, как все присутствующие понимают. Другими словами модель нагрузки не плоская (кол-во пользователей -> responce time) а объемная (100 пользователей типа А + 5 пользователей типа В + 1 сервер баз данных + выделенный сервер -> график загрузки 1 ПРОТИВ 50 пользователей типа А + 15 пользователей типа В + 1 сервер баз данных + на том же сервере application server -> график загрузки 2). Я обычно так выделяю задачу.

В более тонкие материи типа "слоев нагрузки" предлагаю пока не влазить, чтобы окончательно не уйти "на глубину", если "на мелководье" не договорились зачем лезем :)

При тестировании масштабируемости модель нагрузки изменяется, тут все верно, но модель нагрузки зависит не только от количества пользователей, но и от их количества в группах, от аппаратной платформы и т.д.: 100 операционистов и 2 аналитика, это не тоже самое что 98 операционистов и 4 аналитика, как все присутствующие понимают. Другими словами модель нагрузки не плоская (кол-во пользователей -> responce time) а объемная (100 пользователей типа А + 5 пользователей типа В + 1 сервер баз данных + выделенный сервер -> график загрузки 1 ПРОТИВ 50 пользователей типа А + 15 пользователей типа В + 1 сервер баз данных + на том же сервере application server -> график загрузки 2). Я обычно так выделяю задачу.

Case,

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

Все что ты перечислел - это и есть модель. И она действительно не плоская, а включает в себя множество элементов. Собственно, именно этот термин ты использовал в своем посте.

Отличие наших позиций заключается только в растановке приорететов.

У Джоела Спольски есть отличная статья по классификации типок программ - "Пять миров" (кстати, очень рекомендую его статьи, для тех, кто еще не читал). Он выделяет пять классов программ:
1. Ширпотреб
2. Внутреннее ПО
3. Встроенное ПО
4. Игры
5. Одноразовое ПО

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

И логика здесь очень проста.
Если пользователь системы является лицо подневольное и ему программа навязана руководством, то руководству "до лампочки" быстродействие системы (как, впрочем, и удобство интерфеса и многих других параметров). В этом случае на первый план выходит количество одновременных пользователей - сколько человек может работать с системой не толкаясь локтями (аналогично - сколько человек можно впихнуть в маршрутный гроб типа Газель?).

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