Home

Автор: Андрей Широбоков

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

Описание подхода к формированию требований для тестирования производительности Приложения. Подготовка к тестированию.

1. Определяем критичный с точки зрения производительности функционал и составляем таблицу критериев в виде:

<функция/операция> — интенсивность выполнения (интенсивности определяются исходя из статистики посещаемости/используемости Приложения пользователями и процентного распределения данной функции/операции в общей нагрузке) — время отклика. Пример такой таблицы с двумя операциями:

Таблица 1.

Таблица 2 иллюстрирует (как пример) распределение операций на сайте электронной торговли, группы операций выделены разными цветами. В сочетании с журналами регистрирующими количество запросов пользователей к тем или иным страницам сайта, может быть произведен анализ и рассчитаны значения интенсивностей. Подобная статистика может быть так же собрана и представлена бизнес подразделениями, которые понимают объемы и направления пользовательской активности. Хочется заметить что по результатам анализа журналов интересными могут быть разные интенсивности представляющие собой разные Профили Нагрузки, например, утренняя и вечерняя (ночная) активность пользователей на сайте, Начало Операционного дня и Завершение Операционного Дня для банковских приложений, нагрузка на Приложение может быть так же различна в разные дни месяца/года и так далее.

Таблица 2.

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

Как правило производительность и времена отклика все таки связаны между собой и медленное выполнение операций (из-за наличия «узких мест») приводит к снижению производительности даже несмотря на правильное моделирование операций в тесте.

2. Описываем тестируемый функционал в виде сценариев (шаги выполняемые пользователем, программой для моделирования функции/операции).

3. Классифицируем сценарии как основные (непосредственно моделирующие тестируемую функциональность) так и фоновые (дополнительные функции/операции) необходимые для получения полного профиля нагрузки.

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

5. Формируем нагрузочную модель (моделирует какой либо Профиль Нагрузки), в которой указывается каким количеством виртуальных пользователей и с какой интенсивностью, будет выполняться каждый сценарий. Хочется также обратить внимание что ключевым моментом здесь все таки является интенсивность выполнения данного пользовательского сценария (операции) из таблицы критериев (Таблица 1). Количество виртуальных пользователей определяется исходя из этого критерия и, например, 100 операций в час можно смоделировать как 10, 50 так и другим количеством виртуальных пользователей. Впрочем, есть ситуации когда количество виртуальных пользователей задается и манипулировать этим количеством уже не получится (например, с технической точки зрения целесообразно иметь в тесте не менее некоторого количества пользователей работающих одновременно, или иногда бизнес может попросить проверить работу данного сценария для определенного количества пользователей и так далее). Нагрузочных моделей может быть несколько, где каждая может моделировать какой либо специфичный профиль нагрузки. В качестве примеров могут быть рассмотрены Средняя, Максимальная, Пиковая нагрузки, выраженные в разных интенсивностях выполнения операций. Могут также иметь место Нагрузки Начала операционного дня, Окончания Операционного дня, Начала, Середины и Конца месяца. Если необходимо то формируются группы пользователей выполняющих сценарии синхронно друг с другом, указываются условия начала и завершения теста (сколько виртуальных пользователей и в какой последовательности стартует в начале и останавливается по завершении теста)

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

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

8. Разрабатываем, отлаживаем тестовые скрипты.

9. Производим установку счетчиков в основных (не фоновых) тестовых скриптах для замера времен откликов.

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

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

1. Первые тесты желательно проводить на самом низком нагрузочном профиле так как еще непонятно поведение системы, возможно есть серьезные препятствия для нормальной/ожидаемой производительности.
2. Обычно практикуется повышение нагрузки, выраженное в увеличении интенсивностей выполнения операций (увеличение количества пользователей) с тем чтобы получить зависимости времен отклика от различных нагрузок.
3. Одновременно с проведением теста необходимо снимать метрики производительности серверного оборудования так как тестирование Приложения обычно производится относительно аппаратных конфигураций (кол-во CPU x Memory). Наиболее важными из них являются:
   1. Показатели в процентах для процессоров:
      1. CPU user использование процессоров для работы Приложения,
      2. CPU wio ожидание процессорами ввода/вывода,
      3. CPU idle «простой» процессора
   2. Очереди на процессора
   3. Использование памяти
   4. Очереди на диски
      При этом дисковая подсистема и сеть не должны быть «узкими местами» так как в этом случае будет непонятно насколько эффективным с точки зрения производительности является само Приложение

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

1. Результатами для анализа как правило являются замеры времен отклика по операциям (счетчики, установленные в скрипте), количество успешно выполненных операций в течении теста и метрики использования серверного оборудования.
2. Чаще всего имеет смысл анализировать результаты времен отклика по значению 90 персентелей. Например, если среднее время отклика по какой либо тестируемой операции 10 секунд, по 90 процентам — 25 секунд и максимум, скажем, равен 39 секундам то это означает что 90 процентов времен отклика по данной операции не превышает 25 секунд и только 10 процентов времен распределяются в диапазоне от 25 секунд до 39 секунд. В зависимости от специфики данного тестирования эти 10 процентов могут быть признаны «выбросом» и проигнорированы, как впрочем, и наоборот, в случае наличия эффективных кэшей и невозможности полностью избежать кэширования, максимальные значения могут иметь важное значение для рассмотрения и анализа результатов.
3. При тестировании с нарастанием нагрузки получается несколько точек где каждой моделируемой нагрузке соответствует время отклика для контролируемой операции.
4. Результатом этих экспериментов могут быть кривые наглядно представляющие характер изменения времени отклика от нагрузки. Идеальным случаем является линейный характер зависимости времени отклика от нагрузки так как это позволяет нам прогнозировать отсутствие значительных замедлений за границами проводимых экспериментов.
   Результатом тестирования может явиться решение о дальнейшей доработке Приложения, настройке (tuning) программного обеспечения или об изменении аппаратной конфигурации оборудования для лучшего соответствия бизнес требованиям по производительности.

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