Home

Публикация компании IT-Online, автор Дмитрий Сатин

Оригинальная публикация

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

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

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

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

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

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

И вот в этот момент возникнет проблема, о которой мы хотим вас предупредить, и помочь в её решении.

Как представить полученные данные? Как принять решение? Лучше или хуже новая версия системы по сравнению с текущей?

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

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

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

Решение 1. Графическое представление

Постройте частотную диаграмму нагрузки, расположив в оси абсцисс кванты нагрузки, например на процессор: 10%, 20%, 30% и т.д. А по оси ординат количество регистраций счетчиком этих значений нагрузки.

Построив на тех же осях график нагрузки второй версии, вы сможете сравнить их.

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

Вам нужно составить запрос, преобразующий таблицу вида:

• Значение счетчика
• Версия системы (идентификатор билда)

в перекрестную таблицу:

• Значение счетчика
• Количество измерений для первой версии
• Количество измерений для второй версии
• и т.д.

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

В практике, скорее всего, такого сильного различия не будет. Поэтому, кроме построения графиков, вам нужно будет подкрепить своё решение статистическими критериями.

Решение 2. Статистический критерий

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

Для оценки t-критерия проще всего воспользоваться MS Excel’ем. Функция, которая вам нужна, называется TTEST (ТТЕСТ — в русской локализации).

Для нашей задачи подходит двухвыборочный t-тест с разными дисперсиями. Он используется для двух выборок данных из разных генеральных совокупностей. Эта форма t-теста предполагает несовпадение дисперсий генеральных совокупностей и обычно называется гетероскедастическим t-тестом.

Справку по функции TTECT см. здесь http://office.microsoft.com/ru-ru/assistance/HP052093251049.aspx

Пример из жизни

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

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

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

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

Распеределение загрузки CPU

Распределение нагрузки новой версии отличалось большим разбросом значений, от 0 до 50%, в то время как текущая версия показала более цельный и организованный характер.

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

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

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

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

Таблица 1. Средние значения по загрузке CPU

T-тест сравнения текущей и новой версий равен 5,91E-58

Таблица 2. Значения T-теста при сравнении версий

Можно с уверенностью говорить, что средние значения утилизации ресурсов CPU для текущей и новой версии системы достоверно различаются. Значение T-теста пренебрежительно мало.

А вот текущая и исправленная новая версия различаются не так уверенно. Есть некоторая вероятность (P = 0.0469) того что средние значения при бесконечном количестве измерений (в пределе) окажутся равны.