Представление результатов нагрузочного тестировани
#1
Отправлено 20 мая 2006 - 17:55
Публикация компании IT-Online, автор Дмитрий Сатин
Библиотека / Тестирование
Необходимость нагрузочного тестирования возникает только в самых крупных проектах. Перед внедрением новых версий таких систем приходится обосновывать оправданность риска столкнуться с ограничениями устойчивости системы к нагрузкам. Просчет программистов может быть незначительным — лишний или неоптимальный запрос к базе данных, и частота, с которой этот запрос будет вызываться большим количеством пользователей, может привести систему к параличу, что приведет к потере продаж и пагубно отразится на имидже компании.
#2
Отправлено 20 мая 2006 - 18:12
#3
Отправлено 20 мая 2006 - 18:31
PS
Дмитрий, загляните в мой блог :)
Редактор портала www.it4business.ru
#4
Отправлено 21 мая 2006 - 21:16
Не совсем понятно почему весь анализ результатов нагрузочного тестирования свелся к тому, что вырос 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. Выяснилось, что иногда много маленьких запросов к базе данных могут оказаться лучше, чем один большой запос (объединяющий их). В случае "большого" запроса, могут возникать пиковые нагрузки, которые создают эффект снежного кома - транзакции не могут быстро завершиться, число виртуальных пользователей, порождаемых генератором, растет из-за того, что скорость их появления начинает превышать скорость завершения, и это приводит к еще большей нагрузке.
#5
Отправлено 22 мая 2006 - 06:53
Не согласен. В РФ крупных проектов почти нет, но необходимость в тестировании производительности возникает довольно часто. И для малых и для сверхмалых проектов эта необходимость есть.Необходимость нагрузочного тестирования возникает только в самых крупных проектах.
Фраза построена неудачно и допускает множественное толкование. Боясь, я ее просто не понял.Перед внедрением новых версий таких систем приходится обосновывать оправданность риска столкнуться с ограничениями устойчивости системы к нагрузкам
Кстати, а если это не новая версия, а просто новый продукт?
А что такое "процедура опубликования"? Для меня это помещение программистом новей версии в репозиторий кода. Может быть имелось в виду установка новой версии на рабочий (боевой) стенд?мы внесли изменения в процедуры опубликования новых версий
Зачем? Если требования по производительности выполняются, то на фига козе баян?Мы хотели быть уверены, что новая версия система не тратит больше ресурсов, чем текущая версия.
Это разные категории. Отделите мух от котлет.Для её определения придется исследовать как показатели использования (утилизации) ресурсов при рабочей нагрузке, так и анализировать деятельность пользователей, с целью выявления наиболее частых паттернов поведения (обращения) с системой.
Присоединюсь к коллегам. Это неправильно.Первое, что приходит в голову — это сравнить средние значения утилизации ресурсов (например, CPU на сервере баз данных). И это правильно!
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#6
Отправлено 22 мая 2006 - 07:14
Прошу прощения за резкость, но посмотрите вот этот материал: http://rsdn.ru/artic...Towrite.xml#ELDНа помощь приходит статистика.
-------------------------------------------------------------
Я не рекомендую читателям нашего сайта использовать статистические методы этой статьи в своей работе ввиду наличия ряда логических и фактических ошибок.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#7
Отправлено 22 мая 2006 - 07:21
Именно. Следовательно ...P.S. Кстати. Именно на этих испытаниях я заметил интересную вещь, о которой мог, впрочем, догадаться раньше и без этих работ. Время реакции системы напрямую не связано с тем, насколько система утилизирует ресурсы.
А может быть и наоборот. И если в разных версиях используются разные механизмы, то преобразование значений загрузки процессора в результаты тестирования не выдерживает критики.P.P.S. Выяснилось, что иногда много маленьких запросов к базе данных могут оказаться лучше, чем один большой запос (объединяющий их).
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#8
Отправлено 22 мая 2006 - 08:27
Коллеги,
хочу обратить ваше внимание на один факт, который свойственен почти всем, кто пишет о нагрузочном тестировании (кстати, вклучая и статью, на которую дана ссылка в тексте).
Нагрузочное тестирование НЕ СЛУЖИТ определению НАЛИЧИЯ или ОТСУТСВИЯ узких мест в системе. НЕСУЩЕСТВУЕТ систем без узких мест! Они есть всегда и везде!
Назначение нагрузочного тестирования в выявлении проблем производительности системы (фактически - дефектов производительности). Это означает, что производительность системы НЕ СООТВЕТСТВУЕТ установленным КРИТЕРИЯМ. Узкое место системы принимает статус дефекта на основании факта не соотвествия установленному критерию.
КРИТЕРИЕВ производимтельности существует только ДВА:
- время отклика системы;
- количество обрабатываемых транзакций (или данных) в единицу времени.
ВСЕ! Больше критериев нет.
Если в результате тестирования было выявлено, что система ПРИ ОПРЕДЕЛЕННОЙ МОДЕЛИ НАГРУЗКИ удовлетворяет критериям производительности, то дальнейшее исследование системы - пустая трата времени. Если нет, то производится системный анализ с целью локализации узкого места, выявленного в ходе тестирования. И здесь уже используются разные счетчики и дополнительные тесты.
Факт исправления дефекта производительности не означает устранения узких мест. Это всего лишь означает, что узкое место расширено и на смену ему выступила другая проблема. Нужно ли ее устанять? Это должно определяться на основании КРИТЕРИЕВ.
Следовательно, для проведения тестирования нужны следующие исходные данные:
1. Модель нагрузки (их может быть много, для каждой ситуации).
2. Критерии успешности тестов (или не успешности).
Модель нагрузки включает в себя не только поведение пользователей, но и исходные данные системы, на которой производятся операции (hard-, software, объем и структура данных). Исходя из разных предпосылок (например, ежегодное увеличение объема обрабатываемых данных) строятся различные модели нагрузок.
#9
Отправлено 22 мая 2006 - 09:36
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#10
Отправлено 22 мая 2006 - 09:59
А количество пользователей (включая профиль нагрузки) куда отнести в такой случае? :)КРИТЕРИЕВ производимтельности существует только ДВА:
- время отклика системы;
- количество обрабатываемых транзакций (или данных) в единицу времени.
ВСЕ! Больше критериев нет.
Чисто логически производительность это операции/время, то есть примерно "скорость", но интересует ещё потенциальная возможность "а насколько больше мы можем" или например "а что будет если будет + 100 польователей".
Редактор портала www.it4business.ru
#11
Отправлено 22 мая 2006 - 10:06
Вы наверное экстрасенс!
Я их и пишу, только пока все складывается в стол. То, что-то не доработал, то времени нет закончить. Но я уже решил, что пора их куда-нибудь выложить. Собираюсь свой сайт открыть. Жду, когда РБК-Софт мне позвонит и назначит рандеву с курьером, а они все не звонят и не звонят. У меня уже сомнения стали появляться. Может и нет там никого, за пользовательским интерфейсом?
#12
Отправлено 22 мая 2006 - 10:14
А количество пользователей (включая профиль нагрузки) куда отнести в такой случае? :)КРИТЕРИЕВ производимтельности существует только ДВА:
- время отклика системы;
- количество обрабатываемых транзакций (или данных) в единицу времени.
ВСЕ! Больше критериев нет.
Чисто логически производительность это операции/время, то есть примерно "скорость", но интересует ещё.
Количество пользователей - это модель нагрузки. Сами по себе они не могут являться первичным критерием, так как система может устойчиво работать с разным количеством пользователей.
Следовательно, чтобы определить, удовлетворяет ли нас то, как система работает с 200 пользователями (например), нам нужен еще один критерий. Такой первичный критерий - есть время отклика системы (или количество транзакций).
Если при смоделированной нагрузке в 200 пользователей система проходит критерий успешности по показателю "время отклика", то результат тестирования положительный. Если не проходит (но при этом система вполне может безошибочно обрабатывать запросы всех пользователей), то требуется дополнительное исследование системы с целью локализации узкого места (или другими словами - выявление дефекта производительности).
#13
Отправлено 22 мая 2006 - 10:29
1. Первая - определиться с критериями успешности. Я с этим сталкивался на протяжении всей своей работы тестировщиком. Никто не может сказать как быстро должна работать система. Хотя бизнес аналитики и должны вырабатывать эти данные, но как-то не получается это у них.
Приходиться самому их изобретать. Так, для Интернет приложений в двух разных источниках я нашел два варианта критериев.
- до 1 сек - пользователь считает, что работает с системой реального времени;
- до 8/10 сек - пользователь замечает задержку, но не успевает переключить внимание на другое занятие.
Вот эти критерии и использовали для тестирования Интернет приложений. С другими типами - беда.
2. Моделирование нагрузки.
Этот пункт можно так же разделить на два раздела.
а. Моделирование поведения пользователя. Может включать очень многие параметры, в том числе разное количество пользователей.
б. Моделирование тестовой среды. Идеальный вариант - когда тестовая среда повторяет реальную.
Как я уже писал в одном из своих постов - в основе любой проблемы лежит базис, который можно объяснить на пальцах. Но дальше вступают в действие дополнительные условия, реализация которых требует большех знаний и опыта.
#14
Отправлено 22 мая 2006 - 12:04
Эт-то точно.Никто не может сказать как быстро должна работать система. Хотя бизнес аналитики и должны вырабатывать эти данные, но как-то не получается это у них.
Я выделяю следующие диапазоны:- до 1 сек - пользователь считает, что работает с системой реального времени;
- до 8/10 сек - пользователь замечает задержку, но не успевает переключить внимание на другое занятие.
до 0.1 сек
0.1 - 1
1 - 10
Более 10
Для сайтов вводят еще такую границу как 3 сек. Но причина тут скорее техническая, а не человеческая, так что этой границей мы можем пренебречь.
А вот для того, чтобы понять базис требуется просто немеренно знаний и опыта. Это уже "Гуру".Как я уже писал в одном из своих постов - в основе любой проблемы лежит базис, который можно объяснить на пальцах. Но дальше вступают в действие дополнительные условия, реализация которых требует большех знаний и опыта.
Вы посмотрите, как легко люди пишут и говорят о инстрментах, о профилях, строят графики, проводят партсобрания (это не отсюда), а включаешь - не работает (это тоже не отсюда)
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#15
Отправлено 22 мая 2006 - 12:25
Показателей производительности существует только ОДИН:А количество пользователей (включая профиль нагрузки) куда отнести в такой случае? :)КРИТЕРИЕВ производимтельности существует только ДВА:
- время отклика системы;
- количество обрабатываемых транзакций (или данных) в единицу времени.
ВСЕ! Больше критериев нет.
Чисто логически производительность это операции/время, то есть примерно "скорость", но интересует ещё.
Количество пользователей - это модель нагрузки. Сами по себе они не могут являться первичным критерием, так как система может устойчиво работать с разным количеством пользователей.
Следовательно, чтобы определить, удовлетворяет ли нас то, как система работает с 200 пользователями (например), нам нужен еще один критерий. Такой первичный критерий - есть время отклика системы (или количество транзакций).
Если при смоделированной нагрузке в 200 пользователей система проходит критерий успешности по показателю "время отклика", то результат тестирования положительный. Если не проходит (но при этом система вполне может безошибочно обрабатывать запросы всех пользователей), то требуется дополнительное исследование системы с целью локализации узкого места (или другими словами - выявление дефекта производительности).
Сколько пользователей смогут комфортно работать.
- время отклика системы - служит для определения комфортно / некомфортно / не могут совсем
- количество обрабатываемых транзакций (или данных) в единицу времени + модель нагрузки = число пользователей.
Количество транзакций, графики производительности и прочее и прочее и прочее - оставьте менеджерам, маркетолагам, девелоперам и т.д.
А мне как конечному пользователю нужно, чтобы при игре 2х2, все протосами и все используют батоны - StarCraft не тормозил (время отклика в пределах 0.1 сек и не более) на пятисотом целероне с 128 RAM. ВСЕ! Мне больше ничего не нужно.
То что после исправлений время отклика увеличилось / уменьшилось в 50 раз, с 0,001 до 0,05 сек, мне наплевать.
Ps. Пока мы не будем играть 4х4 на первом пне.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#16
Отправлено 22 мая 2006 - 13:40
Не согласен.Количество пользователей - это модель нагрузки. Сами по себе они не могут являться первичным критерием, так как система может устойчиво работать с разным количеством пользователей.
Следовательно, чтобы определить, удовлетворяет ли нас то, как система работает с 200 пользователями (например), нам нужен еще один критерий. Такой первичный критерий - есть время отклика системы (или количество транзакций).
Количество пользователей, которых может обслуживать система также является как вы определяете "первичным показателем". Сталкивался и не раз с ситуацией, когда при 100 работает в пределах нормы, а при коннекте 100+1 начинаются проблемы у всех 100, при чем проблемы не по времени, а банально с коннектом. И тут уже время реакции всех волнует мало.
Нагрузочное тестирование может и должно отвечать на вопросы о масштабируемости системы "сколько еще пользователей система может обслуживать без потери производительности". Время реакции тут является только показателем: вписываемся мы в показатель "работает" или уже нет. Да, производительность упала, но пользователи могут работать - тест прошел.
Кстати, как верно отметил SALar - время является только мерилом. Для меня задача нагрузочного тестирования это определение порога производственной нагрузки.
Редактор портала www.it4business.ru
#17
Отправлено 22 мая 2006 - 14:22
Не согласен.Количество пользователей - это модель нагрузки. Сами по себе они не могут являться первичным критерием, так как система может устойчиво работать с разным количеством пользователей.
Следовательно, чтобы определить, удовлетворяет ли нас то, как система работает с 200 пользователями (например), нам нужен еще один критерий. Такой первичный критерий - есть время отклика системы (или количество транзакций).
Количество пользователей, которых может обслуживать система также является как вы определяете "первичным показателем". Сталкивался и не раз с ситуацией, когда при 100 работает в пределах нормы, а при коннекте 100+1 начинаются проблемы у всех 100, при чем проблемы не по времени, а банально с коннектом. И тут уже время реакции всех волнует мало.
Трудно поставить диагноз по краткому описанию, но такая проблема более характерна для функционального дефекта, чем для дефекта производительности. Как правило, деградация системы происходит постепенно.
Но даже, если представить следующую ситуацию, что система начинает "сыпать" ошибками, то все равно, мы сравниваем с нужным (одним из двух) критерием. После порога (прошли 10 секунд) - нет дефекта, до порога - дефект.
В жизни, конечно же, не все так однозначно. Можно ввести еще зону опасности. Например, 20 секунд. Если не укладываемся в этот критерий, то в следующем релизе при наличие времени можно будет посмотреть, что там тормозит процесс. Но в этом релизе время на устранения дефекта производительности не тратим, так как тест удовлетворяет формальным требованиям.
Нагрузочное тестирование может и должно отвечать на вопросы о масштабируемости системы "сколько еще пользователей система может обслуживать без потери производительности". Время реакции тут является только показателем: вписываемся мы в показатель "работает" или уже нет. Да, производительность упала, но пользователи могут работать - тест прошел.
Кстати, как верно отметил SALar - время является только мерилом. Для меня задача нагрузочного тестирования это определение порога производственной нагрузки.
Что имеется ввиду под порогом производительности? Момент, когда система сломается? А если система написана истинными коммунистами и она тормозит но не ломается, тогда что?
Критерий может быть один - время обработки запроса. Пользователю до лампочки, сколько еще, таких же как он, терзает систему. Хоть 100, хоть 1000000. Если он ждет больше 10 секунд, то ... его уже нет. Он у конкурентов, которые работают быстрее.
А масштабируемость системы проверяем просто.
В модели негрузки меняем всего лишь один параметр - количество одновременных пользователей. И, опять же, сравниваем с критериями успешности - время отклика системы или количество обрабатываемой информации.
#18
Отправлено 22 мая 2006 - 14:49
Я отталкиваюсь от определения нагрузочного тестирования, которое предлагает 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 вообще вынесено в дополнения, но никак не ложится в основу.
Пример приведенный вами работает для веб-сайтов (магазинов), где время отклика в условиях наличия в пространстве солидного количества аналогов имеет значение: "не купит у нас - пойдет туда где быстрее". Но это узко, как по мне.
Критерий успешности нагрузочного тестирования (особенно для крупных систем) это именно количество пользователей, а затем уже время, количество транзакций, ресурсы и т.д.
Редактор портала www.it4business.ru
#19
Отправлено 22 мая 2006 - 15:06
Но не все равно Системе. Мы ведь тестируем Систему, а не пользователей. Я говорю о бизнес системах (операционисты, обрабатывающие запросы никуда не уходят, у них нет другой системы - они просто проваливают план и компания просто несет убытки), но никак не о частном случае пользователя веб-сайта, которого не устраивает скорость загрузки сайта (зачастую, кстати не является критерием выбора магазина - я например на цену и доставку смотрю в первую очередь).Критерий может быть один - время обработки запроса. Пользователю до лампочки, сколько еще, таких же как он, терзает систему.
Снова узко смотрим, как по мне. Другой вопрос масштабируемости: "А если разнести на 2 сервера и load balancer поставить?", "А если на тот же сервер поставим еще один application server", "У нас два новых аналитических запроса появились, что скажут операционисты если у них упадет формирование остатков по складу с 2 секунд до 30? Оптовик с телефона уйдет или прокатит?"А масштабируемость системы проверяем просто.
В модели негрузки меняем всего лишь один параметр - количество одновременных пользователей. И, опять же, сравниваем с критериями успешности - время отклика системы или количество обрабатываемой информации.
При тестировании масштабируемости модель нагрузки изменяется, тут все верно, но модель нагрузки зависит не только от количества пользователей, но и от их количества в группах, от аппаратной платформы и т.д.: 100 операционистов и 2 аналитика, это не тоже самое что 98 операционистов и 4 аналитика, как все присутствующие понимают. Другими словами модель нагрузки не плоская (кол-во пользователей -> responce time) а объемная (100 пользователей типа А + 5 пользователей типа В + 1 сервер баз данных + выделенный сервер -> график загрузки 1 ПРОТИВ 50 пользователей типа А + 15 пользователей типа В + 1 сервер баз данных + на том же сервере application server -> график загрузки 2). Я обычно так выделяю задачу.
В более тонкие материи типа "слоев нагрузки" предлагаю пока не влазить, чтобы окончательно не уйти "на глубину", если "на мелководье" не договорились зачем лезем :)
Редактор портала www.it4business.ru
#20
Отправлено 23 мая 2006 - 08:12
При тестировании масштабируемости модель нагрузки изменяется, тут все верно, но модель нагрузки зависит не только от количества пользователей, но и от их количества в группах, от аппаратной платформы и т.д.: 100 операционистов и 2 аналитика, это не тоже самое что 98 операционистов и 4 аналитика, как все присутствующие понимают. Другими словами модель нагрузки не плоская (кол-во пользователей -> responce time) а объемная (100 пользователей типа А + 5 пользователей типа В + 1 сервер баз данных + выделенный сервер -> график загрузки 1 ПРОТИВ 50 пользователей типа А + 15 пользователей типа В + 1 сервер баз данных + на том же сервере application server -> график загрузки 2). Я обычно так выделяю задачу.
Case,
А я и не виже особых противоречий в наших позициях. Особенно теперь, после того как ты добавил детали. Терминология, правда, несколько отличается.
Все что ты перечислел - это и есть модель. И она действительно не плоская, а включает в себя множество элементов. Собственно, именно этот термин ты использовал в своем посте.
Отличие наших позиций заключается только в растановке приорететов.
У Джоела Спольски есть отличная статья по классификации типок программ - "Пять миров" (кстати, очень рекомендую его статьи, для тех, кто еще не читал). Он выделяет пять классов программ:
1. Ширпотреб
2. Внутреннее ПО
3. Встроенное ПО
4. Игры
5. Одноразовое ПО
С моей точки зрения именно коммерческие (продукты, призванные работать в конкурентной среде) являются наиболее критичными к вопросу производительности. И не важно, это веб-сайт или программа бухгалтерского учета (предлагаю не трогать программы управления ядерными электростанциями или космическими аппаратами - это не промышленная, а научная разработка ПО).
И логика здесь очень проста.
Если пользователь системы является лицо подневольное и ему программа навязана руководством, то руководству "до лампочки" быстродействие системы (как, впрочем, и удобство интерфеса и многих других параметров). В этом случае на первый план выходит количество одновременных пользователей - сколько человек может работать с системой не толкаясь локтями (аналогично - сколько человек можно впихнуть в маршрутный гроб типа Газель?).
Время отклика системы является величиной универсальной. Если у пользователя есть выбор, то он всегда выбирает программу с максимальным или допустимым быстродействием. Программа может быть идеальной во всех отношениях. И пользовательский интерфейс, и отсутствие багов и супер поддержка пользователей. Но если она заставляет пользователя ждать, то у последнего складывается отрицательное мнение о программе в целом. И он переходит на другой продукт (причем, очень часто он готов мириться с некоторыми недостатками системы в пользу быстродействия).
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных