Надо грузить!

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

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

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

Методика и инструментарий

Для начала разберёмся, как проводится нагрузочное тестирование. Обычно выполняются следующие шаги:

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

Рассмотрим их последовательно.

Уточнение целей и требований

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

Приведём пример из проекта по организации процесса управления мощностями в одном из российских Банков. Как часть решения проектной задачи, заказчик разрабатывал внутренние спецификации ИТ-услуг (предоставляемых департаментом ИТ основному бизнесу), определяющие характер зависимости потребностей в ИТ-ресурсах от плановых показателей объёма потребления ИТ-услуг. Естественно, такая зависимость является довольно сложной – нелинейной и плохо поддающейся аналитическому прогнозированию в случае существенного отклонения параметров нагрузки от текущих значений, при которых поведение ИТ-систем известно. Например, если мы увеличим число одновременно работающих пользователей с сотни до полутора, система может справиться без изменения обеспечивающих работу приложения ресурсов (разве что нам придётся приобрести дополнительные клиентские лицензии). Если мы продолжим увеличивать нагрузку и изменим число пользователей с полутора сотен до двух, может потребоваться наращивание оперативной памяти или процессорной мощности. Но если мы задумаемся об увеличении числа пользователей до, скажем, четырёх-пяти сотен, то окажется, что «линейным» наращиванием ресурсов уже не обойтись. Вместо этого возможно придётся менять архитектуру системы – увеличивать количество серверов приложений или строить кластер с распределением нагрузки на уровне СУБД. Это приведёт к резкому росту расходов и появлению потребности в совершенно других ресурсах – дополнительных серверах, специфичных лицензиях для обеспечения кластеризации и так далее. Нагрузочное тестирование рассматривалось как один из способов определения границ масштабирования в пределах текущей архитектуры ИТ-систем (когда возможно плавное наращивание мощностей постепенным увеличением ИТ-ресурсов).

Также на этапе уточнения целей могут определяться требования:

• к характеристикам производительности системы (максимально допустимое время реакции или выполнения тех или иных операций);
• к характеристикам тестовой среды (например, наличие медленных или ненадёжных каналов передачи данных между клиентом и сервером или размещение web-серверов для обслуживания внешних клиентов в DMZ¹).

Определение профиля нагрузки

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

К таким операциям могут, например, относиться:

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

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

Выбор инструментария

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

• использовать готовый коммерческий или свободно распространяемый продукт (выбор особенно широк в части тестирования web-приложений);
• разработать свой набор скриптов, обеспечивающих тестирование.

Помимо выполнения операций программным способом, который может не обеспечивать тестирование скорости реакции пользовательского интерфейса, концентрируясь на измерении скорости выполнения операций на уровне прикладных протоколов, в ряде случаев прибегают к дополнительному тестированию с привлечением «живых пользователей». Выполняя такие же или отличные операции, пользователи могут сформировать субъективное впечатление о производительности системы (так называемый «User Experience Under Load Test»).

Разработка нагрузочных тестов (сценариев)

Определившись с инструментарием, можно приступить к генерации тестов. Здесь всё зависит от того, насколько гибко ваша система допускает управление через внешние API². Чем более полно вы можете управлять системой посредством COM, CORBA, web-сервисов и других интерфейсов, тем большее покрытие тестовых сценариев получится обеспечить.

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

Подготовка тестовой среды

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

Проведение тестов

Пора приступить к тестированию. На этом этапе запускаются тесты (как автоматизированные, так и выполняемые вручную) и снимаются следующие характеристики:

• текущее количество действующих клиентов и совершаемых ими операций;
• потребление основных ресурсов на тестовых узлах (потребление оперативной памяти, нагрузка на процессоры, нагрузка на дисковую подсистему) – рабочих станциях, серверах приложений, web-серверах, серверах баз данных;
• уровень загрузки сети передачи данных между тестовыми узлами;
• время отклика системы и время выполнения ключевых операций.

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

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

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

А стоит ли овчинка?

Из сказанного становится ясно, что проведение нагрузочного тестирования «по всем правилам военного искусства» требует и времени, и серьёзных ресурсов. Поэтому часто возникает вопрос: не получится ли так, что измерение окажется дороже, чем неопределённость в принятии решения о масштабируемости системы?

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

Поэтому рискнём дать некоторые рекомендации:

• Всегда чётко определяйте, на какой вопрос необходимо ответить при помощи тестирования, и для принятия какого решения это необходимо.
• Если для проведения полного тестирования возможностей (времени, денег, знаний и так далее) недостаточно, задайте себе вопрос: «Что можно сделать с тем, что у меня есть»? И возможно сделать удастся больше, чем ничего.
• Привлекайте поставщиков. Есть вероятность, что поставщик может помочь вам и с определением профиля нагрузки, и с выбором инструментария, и с определением параметров тестовой среды.

Непридуманная история

В качестве обещанного в начале статьи примера «быстрого и недорогого» нагрузочного тестирования приведём работу, которую нам довелось выполнять для одного из наших заказчиков. Речь идёт о тестировании приложения OMNITRACKER CleverENGINE, которое один из крупнейших российских банков рассматривал в качестве варианта для миграции с действующей системы автоматизации процессов управления ИТ-услугами, построенной на базе продукта HP OpenView Service Desk 4.5.

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

Для сокращения сроков и стоимости тестирования было решено:

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

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

В ходе тестирования измерялось время автоматизированного выполнения следующих операций:

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

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

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

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

Зависимость времени создания обращения от количества операций в единицу времени

На основании представленного графика можно сделать следующие выводы:

• среднее время выполнения операции постепенно растёт и превышает ожидаемый заказчиком уровень в три секунды примерно после 90 операций записи в минуту;
• далее примерно до 100-110 операций в минуту время создания обращения продолжает расти относительно стабильно – система работает медленнее, чем хотелось бы, но пока предсказуемо;
• наконец, после 110 операций в секунду резко возрастает дисперсия – система выходит на критический режим. Это и есть практический потолок масштабирования системы для заданных характеристик оборудования.

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

Выводы

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

Сноски

1. Так называемая демилитаризованная зона, обеспечивающая ограничение взаимодействий между внешними и внутренними серверами предприятия.
2. Application Programming Interface – интерфейс программирования, посредством которого осуществляется управление приложением.