Введение в нагрузочное тестирование

Материал тренинга для тестировщиков. 

(с) Сергей Мартыненко 2004 г. 

 

 

Терминология

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

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

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

Объемное тестирование - приложение нагружается большим количеством данных, чтобы определить, когда достигаются условия, при которых система перестает работать.

Стресс тестирование - поведение системы при недостатке ресурсов (ресурсов процессора, дискового пространства, обрывов сети, …)

 

Цели и задачи

Все четыре вида тестов принадлежат к одной группе и их иногда называют общим термином «Нагрузочное тестирование». На самом деле эти тесты преследуют различные цели.

Тестирование производительности применяется наиболее часто. Оно применяется на различных стадиях проекта. Цель этого тестирования ответить на вопросы:

  • На стадии проектирования.
    • Какая из архитектур системы лучше? Трех или четырехуровневая, где и как хранить файлы, обеспечат ли выбранный язык и БД необходимую производительность и т.д.
  • На стадии программирования.
    • Какая схема БД лучше? Стоит ли отказаться от нормализации БД в пользу производительности или наоборот; как делать вьюшки; что лучше триггера или внешние ключи.
    • Какой участок кода следует оптимизировать в первую очередь
  • На стадии тестирования:
    • Максимальная производительность системы
    • Определение увеличения времени отклика и длительность операций при увеличении нагрузки.
    • Определение предела применимости программы по числу пользователей.
    • Определение влияния конфигурации системы на производительность.
    • Пиковая нагрузка на систему.
  • На стадии поставки:
    • Удовлетворяет ли архитектура и настройка сети требованиям производительности?

Классическая ошибка - проведение тестирования производительности только на стадии тестирования.

 

Узкие места и объекты тестирования

Достаточно часто, схема бизнес приложения выглядит следующим образом:

Если рассматривать логические потоки информации, то очевидно узким местом становятся сервер приложений и сервер БД. Как правило, возможности системы ограничиваются возможностями сервера приложений, иногда сервера БД. Для увеличения производительности применяют два метода: оптимизацию кода  или БД и аппаратное наращивание (увеличение мощности серверов, создание кластеров).

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

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

  • % загрузки процессора сервера приложений
  • % загрузки процессора сервера БД
  • Средний объем переданных по сети байт за секунду
  • % использования памяти на сервере БД
  • Средний объем считанных с винчестера сервера БД байт за секунду
  • прочее

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

 

Метод тестирования

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

Здесь уместна аналогия с экзаменом. Цикл: студент обдумывает решение, отвечает, экзаменатор оценивает решение, дает следующее задание.

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

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

Объекты  тестирования

  • Тестирования времени выполнения системой одной операции
  • Тестирование времени выполнения системой цепочки действий (бизнес операции)
  • Тестирования времени выполнения компонентом одной операции. Применяется для исследования и оптимизации узких мест.

 

Типичный сценарий тестирования

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

Также желательны:

    • Число переданных и принятых по сети байт
    • Загрузки процессора на сервере и клиенте
    • Объемы занятой и свободной памяти на сервере и клиенте

 

Техника выполнения

Ручная

Может быть использована при отсутствии других вариантов.

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

Средняя нагрузка от одного оператора – 1 бизнес операция в 10 мин

В пике от всех – до 50 бизнес операций в 10 мин и до 10 в минуту.

Если не беспокоиться о правильности ввода, то можно совершать 1 операцию в 30 сек.

Итак, нам понадобится 7 тестеров:

  • один, следящий за счетчиками на серверах и управляющий процедурой
  • один замеряющий время отклика
  • и пять тестеров, грузящих приложение

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

 

Специализированными средствами нагрузочного тестирования

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

  • Rational PerformanceStudio
  • LoadRunner
  • WAST
  • И т.д.

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

 

Самостоятельно написанной утилитой

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

 

Типичные результаты тестирования

 

арактерное поведение web приложения под возрастающей нагрузкой.

Характерное поведение web приложения под возрастающей нагрузкой.

B – точка максимальной производительности системы

D – точка потери производительности

E – точка краха системы.

При увеличении числа потоков производительность системы растет, до достижения точки максимальной производительности (B). Для динамической веб-страницы на IIS это обычно происходит при 2-5 потоках. Далее идет почти ровное плато производительности (B-C-D) при линейном возрастании времени отклика. Затем происходит резкое падение производительности. Типичная ситуация: при 24 потоках время отклика -2.7 сек, при 25 – 7 сек, при 26 – система не отвечает. Для веб сервера, как правило, точка D соответствует времени отклика 3 сек.

Из этих выкладок следует, что можно оценить максимальную производительность и максимальное число одновременных запросов по одному запросу. Если при 8 потоках время отклика составляет 1 сек (8 запросов в секунду), то разумно искать точку краха системы в области 18-24 запроса. А максимальная производительность будет порядка 9 запросов в секунду (+10%) при 2-3 одновременных запросах (точка B).

 

Интерпретация результатов

Допустим мы получили результат: Максимальная производительность достигается при трех одновременных запросах. При этом производительность системы составляет девять запросов в секунду. А каково максимальное количество пользователей?

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

Если пользователь обращается к системе один раз в 60 секунд (режим просмотра сообщений в форуме), тогда максимальное число одновременно работающих пользователей – 270 человек.

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

Комментариев: 5

  1. longraw написал:

    В целом понравилось. Но есть неточности и очень сильные упрощения.
    Про сервер БД очень неточно написано. % утилизации памяти на сервере БД будет фиксированным в 99% процентов проектов. Для Оракла и MS SQL необходимо снимать статистику использования памяти и дисковых групп разными процессами внутри самого сервера БД встроенными средствами. Для диска - тоже самое. Например у Вас на реальном сервере Oracle 10g 30 LUN, из них 20 7+1 дисковых в RAID 0+1 под разные датафайлы, 6 7+1 дисковых RAID-5 под REDO логи и 4 7+1 дисковых RAID-6 под arcivelog.
    Снять статистику ОС по IOps или по потоку - все равно что померить шум песков на Марсе.

    Еще нигде явно не написано, что основной параметр, который фиксируется - время реакции системы на внешние воздействия. Т.е. нагрузка создается таким образом, чтобы время реакции на различные внешние воздействия попадала в заданные пределы.

  2. alex7kir написал:

    Не могли бы Вы уточнить, как именно Вы получаете цифры 270 и 2 человека интерпретации результатов? Создается ощущение, что результаты в этой статье и в “Тестирование производительности. Тренинг, по ICQ” (http://blog.shumoos.com/archives/76) результаты посчитаны по-разному, хотя схема вроде бы одна. Или я что-то не понимаю? Автор или понимающие читатели, просветите, пожалуйста.

  3. sorokin_in_ua написал:

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

    В свое время перерыл половину интернета чтобы найти адекватный пример по тестированию для HTTP POST, так что если кому надо, то велком - http://sorokin.in.ua/?p=323

  4. bugmenot2 написал:

    Наверное не WAST а WAPT

  5. SALar написал:

    http://msdn.microsoft.com/ru-ru/asp.net/aa336559.aspx
    ———————————————————-
    Средство Web Application Stress Tool (WAST)
    Средство оценки производительности веб-приложения Microsoft WAS предназначен для реалистичной имитации запросов страниц несколькими обозревателями с одного веб-узла. Это средство можно использовать для сбора информации о производительности и стабильности вашего веб-приложения. Средство имитирует большое количество запросов при относительно небольшом количестве клиентских компьютеров. Целью является создание среды, максимально приближенной к рабочей, для поиска и устранения проблем веб-приложения до его развертывания.
    ———————————————————-
    Надо сказать порядком устаревший инструмент.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.