LR: Можно ли сделать псевдослучайный в LoadRunner детерминированным?

Question

В сценариях LoadRunner есть несколько случайных источников:

• rand () функция
• Случайные дельты времени размышления (настройки времени выполнения)
• Случайные компоненты времени стимуляции (настройки времени выполнения)
• Случайные параметры (как часть теста VUGen)

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

Я могу использовать srand (), чтобы установить начальное значение для rand ().Установка определенного (жестко запрограммированного) начального значения при инициализации всегда приводит к одинаковой последовательности, предоставляемой rand () - для всех виртуальных пользователей.Если бы я заполнял номер идентификатора VUser, я бы даже получал разные последовательности rand () для каждого пользователя, в то время как они по-прежнему одинаковы для каждого пользователя.

А как насчет других псевдослучайных источников в LR, кроме rand ()?У меня есть шанс отбросить их все, чтобы я получил детерминистическое поведение сценария?

Я думаю, что это очень помогло бы.

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

Answer 1

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

Без начального числа 2-й тест выбрал бы совершенно другой путь.И на другой итерации, еще один совершенно другой путь.Я хочу СЛУЧАЙНЫЕ последовательности, но ПОВТОРЯЕМЫЕ СЛУЧАЙНЫЕ последовательности.Вот почему все современные языки позволяют создавать генератор случайных чисел.Клиенту Load Runner просто нужно добавить одно текстовое поле, которое позволяет вам ввести «начальное значение» для генератора случайных чисел.

Answer 2

Уже покрыто.Я работаю с LoadRunner с 4.51 и не могу вспомнить версию без возможности установить случайное начальное число.Обычно это в настройках времени выполнения сценария, установленных в контроллере.Вы должны быть в состоянии найти документацию по этому вопросу для вашей версии LoadRunner, открыв версию Руководства пользователя для контроллера по Acrobat и выполнив поиск по слову «семя».

Answer 3

Короткий ответ на ваш вопрос: NO .

Random implies just what it says => "Random". 

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

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

Экстраполяция результатов

Your run with 100 vusers and achieve an avg. of 50-60 hits/sec with
response times under 3 sec.

Logically 1000 vusers (10x load) would give you 500-600 hits/sec ... 

But what about the response times? How do you extrapolate them? How do you know
when the web-server(s) chokes and achieves it's knee-point? 

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

Вещи, которые вы не можете контролировать

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

Более "реалистичный" способ определения нагрузки

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

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

Делая это, мы можем «загрузить» целевое приложение с определенной «ожидаемой загрузкой пользователя» вместозначения страниц / сек или ударов / сек или другие технические метры.

Мы также выполняем более длительные прогоны, чтобы увидеть, как сервис ведет себя во времени, поэтому 72-часовой или более тест не является чем-то необычным для фазы теста на выносливость.Это также показывает, есть ли какие-либо утечки памяти на серверах и как фоновые процессы влияют на производительность сервера в «ночное время»