Шаг нагрузки — pacing JMeter

1. Что такое шаг нагрузки

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

Обозначим шаг нагрузки как T (минут).

Тогда за минуту работы, один виртуальный пользователь, выполнит 1/T сценариев. Интенсивность работы одного виртуального пользователя будет равна 1/T сценариев в минуту.

А если будет работать N виртуальных пользователей, то они суммарно будут выполнять N/T сценариев в минуту.

Важно, чтобы:

1. Количество виртуальных пользователей N было положительным целым значением.
2. Размер шага T был достаточно велик, чтобы сценарий под нагрузкой укладывался в эту длительность — был больше значения, указанного в SLA.
3. Чтобы их отношение точно соответствовало требуемой интенсивности.

2. Калькулятор шага нагрузки

Для удобства расчёта шага нагрузки к текущему заданию сделан калькулятор шага нагрузки в виде Excel-документа:

Скачать калькулятор шага нагрузки (документ Microsoft Excel):

• pacing.xlsx
• pacing — Google Docs (только для чтения, можно скачать и редактировать)

Для редактирования предназначены жёлтые ячейки документа.

3. Как задать шаг нагрузки в Apache.JMeter

В статье:

• Рецепт хорошего скрипта JMeter

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

В том числе компоненты Test Action и Constant Throughput Timer, которые используются для задания фиксированного шага нагрузки в JMeter.

Если опустить другие элементы, то нужные для задания шага нагрузки блоки такие:

• Test Plan
  • jp@gc — Ultimate Thread Group — сторонний компонент, для задания количества пользователей и длительности их работы, для боевого запуска сценария
    •  Test Action — для шага нагрузки, пауза длительностью 0, пустое действие
      •  Constant Throughput Timer — ограничение частоты работы вышестоящего Test Action, для задания шага нагрузки
    •  Module Controller — ссылка на сценарий в  Test Fragment
  •  Test Fragment — для задания операций в сценарии, общий сценарий для отладочного и боевого запуска выделяется в отдельный фрагмент
    •  Transaction Controller — транзакция верхнего уровня для замера длительности работы всего сценария и пауз
      •  Transaction Controller — транзакция верхнего уровня для замера длительности работы всего сценария без пауз
        • … запросы ….
• WorkBench

А если ещё более кратко, то первым действием в катушке , для которой фиксируется шаг работы задаётся Sampler с типом Test Action:

• https://jmeter.apache.org/usermanual/component_reference.html#Test_Action
  • Name: Test Action: Шаг нагрузки, pacing, 80 секунд
  • Target: Current Thread
  • Action: Pause
  • Duration: 0

Важно заполнить поле Duration значением 0, так как поле обязательно для заполнения. Это пустое действие, sampler, выполняющий 0-ю паузу.

Тут в поле Name я отразил пример длительности шага «80 секунд«, каждый волен выбирать свою длительность. Это как пример. Указывается просто, чтобы не забыть размер шага.

Дочерним элементом добавляется timer  Constant Throughput Timer:

• https://jmeter.apache.org/usermanual/component_reference.html#Constant_Throughput_Timer
  • Name: Constant Throughput Timer: Интенсивность работы пользователя
  • Target throughput (in samples per minute): 0.625 — или другое значение, задающее интенсивность работы пользователя (одного потока)
  • Calculate Throughput based on: this thread only

3.1. Механизм работы связки «Test Action» и «Constant Throughput Timer»

Что происходит при таком составе компонент:

1. Катушка запускает виртуального пользователя (thread).
2. Первая итерация:
   1. Первым действием этого пользователя является  Test Action, но прежде чем выполнить действие срабатывает заданный таймер  Constant Throughput Timer.
   2. На первой итерации работы Test Action ещё не выполнялся, пока выполнилось 0 (samples per minute), поэтому таймер не создаст задержки и Test Action сработает — выполнится пауза длиной 0 секунд, и зафиксируется момент времени, в который выполнилось действие.
   3. Далее выполнятся все нужные действия, транзакции — отработает сценарий.
3. Вторая и последующие итерации:
   1. Снова всё начнётся с  Test Action, перед выполнением которого сработает таймер  Constant Throughput Timer.
   2. В этот раз в памяти уже зафиксирован прежний момент выполнения, поэтому будет выдержана пауза равная шагу, такая, чтобы интенсивность работы  Test Action была точно равна значению, заданному в  Constant Throughput Timer.
   3. Далее выполнятся все нужные действия, транзакции — отработает сценарий.

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

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

3.2. Проверка правильности выбора шага нагрузки

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

Чтобы убедиться, что длительность выполнения шагов сценария не превышает шаг, в качестве корневого элемента используется  Transaction Controller. Один учитывающий паузы и второй, вложенный в него, считающий время без учёта таймеров.

Используя транзакции верхнего уровня и сводные отчёты:

• https://jmeter.apache.org/usermanual/component_reference.html
  • Aggregate Report
  • Summary Report

Можно посмотреть максимальную длительность выполнения корневой транзакции. И если эта длительность превышает шаг, допустим, «80 секунд«, то надо выбрать новый шаг и пересчитать параметры:

• вручную:
  • шаг надо увеличить, взять значение, превышающее максимальное значение, пусть это 120 секунд или 2 минуты;
  • уменьшить значение Target throughput (in samples per minute) в  Constant Throughput Timer, так для шага 2 минуты интенсивность будет 1/2 = 0.5 (in samples per minute);
  • увеличить количество виртуальных пользователей, чтобы в сумме они создали нужную интенсивность работы. Если нужна интенсивность 7 сценариев в минуту, то значит нужно 7 / 0.5 = 14 пользователей;
• или воспользовавшись калькулятором (смотри выше).

4. Как задаётся интенсивность в HP LoadRunner

В HP LoadRunner всё тоже самое, нужно задать фиксированный шаг нагрузки и задать количество виртуальных пользователей.

4.1. Шаг нагрузки в HP LoadRunner

Шаг нагрузки в HP LoadRunner задаётся в Runtime Settings на вкладке Pacing:

• Start new iteration at Fixed intervals, every [ …. ] seconds

Шаг задаётся в секундах. В HP LoadRunner нам надо задать фиксированный шаг для итерации в секундах, а в Apache.JMeter задаётся фиксированная частота — величина обратная размеру шага (итераций в минуту). А смысл один и тот же.

Количество пользователей задаётся в HP LoadRunner Controller на вкладке Design, в разделе Scenario Schedule.

5. Пример расчёта шага нагрузки и визуализация

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

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

Пусть в качестве шага нагрузки мы выбираем 30 минут.

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

Тогда понадобится всего 5 пользователей, выполняющих сценарии с интенсивностью 1/30 сценария в минуту или 2 сценария в час.

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

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

4.1. Строевой шаг

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

4.2. Смена профиля нагрузки