Нагрузочное тестирование ПО

суббота, 21 июня 2008 г.

Разработка модели нагрузки

Base line нагрузочная точка

Хочется заметить что такой расчет нагрузочной точки (описан в предыдущей статье), основанный на собранной для работающего приложения статистике (или на ожидаемом объеме работы для вновь разработанного приложения), является исходным для дальнейшего роста нагрузки. А сама расчитанная нагрузочная точка может считаться базовой или base-line точкой. Теперь можно увеличивать нагрузку, двигаясь с некоторым шагом, увеличивая при этом только количество виртуальных пользователей в группах, не изменяя интенсивности выполнения операций для одного виртуального пользователя.

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

четверг, 19 июня 2008 г.

Разработка модели нагрузки

Расчет нагрузочных точек

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

Моделирование работы с пересчетом интенсивностей в этом случае можно проиллюстрировать следующим примером

ПРИМЕР: (для одной операции)

Количество операций = 200 за 4 часа
Количество бизнес пользователей = 20
---------------------------------------

1. Определяем количество операций для каждого пользователя

200/20 = 10

2. В час каждый пользователь выполняет 2.5 операции

10/4 = 2.5

3. Определяем период повторения операции (интенсивность) для каждого пользователя

60/2.5 = 24 минуты

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

24/4 = 6 мин. = 360 секунд

Таким образом, 5 виртуальных пользователей, выполняя операцию с периодом 6 минут, обеспечат за 4 часа заданную производительность равную 200 операциям.

Что дает такой пересчет :

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

Какие есть ограничения :

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

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

Дополняем терминологию :

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


Разработка модели нагрузки

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

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

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

<Профиль нагрузки>
1. Операция_1 - интенсивность выполнения n раз / ед. времени
2. Операция_2 - интенсивность выполнения n раз / ед. времени
3. Операция_3 - интенсивность выполнения n раз / ед. времени
4. Операция_4 - интенсивность выполнения n раз / ед. времени
5. Операция_5 - интенсивность выполнения n раз / ед. времени

Дополняем терминологию (нумерацию я решил сделать сквозную) :

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

воскресенье, 1 июня 2008 г.

Разработка модели нагрузки

Изучение Приложения

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

-Описание компонентов приложения с составлением схемы взаимодействия между ними

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

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

Еще раз хочется заметить, что опрос бизнес пользователей или совместное исследование с разработчиками и администраторами системы может значительно облегчить задачу. Если приложение находится в эксплуатации то можно провести мониторинг загрузки компонентов аппаратных серверов (процессора, память, диски) и проанализировать системные журналы веб серверов, снять stats pack, если в качестве сервера базы данных, например, используется Oracle. Системные журналы могут показать пики высокой активности пользователей в течение дня и дать количественное оценки того сколько транзакций (хитов) выполняется в единицу времени. Есть "золотое правило" гласящее, что 20% операций приложения генерируют 80% нагрузки в системе. Нужно стараться выбрать для моделирования именно эти 20% операций.

Разработка модели нагрузки

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