JMeter: Поля Значения объединяемого

Question

[пересмотренный Orig ДЛЯ ПРОЩЕ ССЫЛКИ]

Запуска JMeter 2.13 r1665067, я исполнительский тестирование API делает основные функции CRUD с помощью HTTP-запросы от JMeter в базу данных, где „идентификатор“ значение поля спорадически «сливается» с жестко закодированным значением «baseUnitValue», что приводит к сбою и сообщению трассировки стека «Obj не найдено».

создать новую запись

HTTP POST 
    "id": 0, 
    "schedulePeriodId": 1259810849, 
    "amount": null, 
    "baseUnitValue": 10.50, 
    "procValue": "G0040", 

RESPONSE 
    "id": 1259811045, 
    "schedulePeriodId": 1259810849, 
    "amount": null, 
    "baseUnitValue": 10.50, 
    "procValue": "G0040" 

RegEx Extractor 
    Apply to: Main Sample only 
    Field to check: Body 
    Ref Name: baseUnitId 
    Reg Exp: \"id":(.+?)\, 
    Template: $1$ 
    Match No: 1 
    Default: None 

UPDATE (оригинал)

HTTP POST 
    ${__BeanShell(return vars.get("foobar").replaceAll(vars.get("baseUnitFieldValue")\,"11.50");,)} 

    Where it's using/interpreting foobar to contain: 
     "id": 12599511.507, 
     "periodId": 1259810849, 
     "amount": null, 
     "baseUnitValue": 11.50, 
     "procValue": "G0040" 

RESPONSE 
    Object with id 12599511 not found... 

После ряда опытов и исследований, картина возникла:

• если 'ID' = хххххх и baseUnitValue = 10.5,
  , когда UPDATE встречается с жестким c Одед 'baseUnitValue' от 11.50, значение 'ID' изменяется на XXXXXX 11,50

В принципе, каждые 1000 записей потерпит неудачу, когда 'идентификатор' закончится в xxxxxx1045. Я бы «появлялся», последние цифры значения «id» оценивались каждый раз, а когда он заканчивался в 1045, он был округлен до 10.50.

---

Благодаря помощи @ kiril-s и @ dmitri-t было создано следующее решение.

Во-первых, я добавил 2 новых Переменные, определяемые пользователем

• rnd1 4,9999 (мин значение)
• rnd2 15,9999 (максимальное значение)

CREATE (добавлено BeanShell Препроцессор)

HTTP POST 
    "id": 0, 
    "schedulePeriodId": 1259810849, 
    "amount": null, 
    "baseUnitValue": ${RND}, 
    "procValue": "G0040", 

BeanShell PreProcessor 
    Parameters: ${RND1}, ${RND2} 
    Script: 
    import java.util.*; 

    String [] params = Parameters.split(","); 

    double rangeMin = Double.valueOf(params[0]); 
    double rangeMax = Double.valueOf(params[1]); 
    Random r = new Random(); 
    double randomValue = rangeMin + (rangeMax - rangeMin) * r.nextDouble(); 
    vars.put("RND",randomValue.toString()); 
    //System.out.println(randomValue); 

Существует также REGEX для параметризации значения поля «id», назначенного базой данных. Это позволяет выполнять функции READ и DELETE, добавляя связанный URL с параметром.

При выполнении запроса READ HTTP добавлен постпроцессор BeanShell в существующий 2 REGEX. REGEX 1 Ref Имя: Foobar Reg Exp: (? S) (.^*)

REGEX 2 
    Ref Name: origFieldValue 
    Reg Exp: \,"baseUnitValue":(.+?)\, 

BeanShell PostProcessor 
    Reset Interpreter: False 
    Parameters: ${RND1}, ${RND2} 
    Script: 
     import java.util.*; 

     String [] params = Parameters.split(","); 

     double rangeMin = Double.valueOf(params[0]); 
     double rangeMax = Double.valueOf(params[1]); 
     Random r = new Random(); 
     double randomValue = rangeMin + (rangeMax - rangeMin) * r.nextDouble(); 

     vars.put("newFieldValue",randomValue.toString()); 
     //System.out.println(randomValue); 

Это позволяет прохождение другое значение (newFieldValue) к 'baseUnitFieldValue' без жесткого кодирования.

ОБНОВЛЕНИЕ (добавлено JSR223 Препроцессор)

HTTP POST 
    ${baseUnitValueBody} 

JSR223 PreProcessor 
    Language: groovy 
    Parameters: "newFieldValue" 
    Script: 
    import org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase; 
    import org.apache.jmeter.protocol.http.util.HTTPArgument; 

    vars.put("foobar", vars.get("foobar").replace(vars.get("baseUnitFieldValue"),vars.get("newFieldValue"))); 

Также обратите внимание на изменение отreplaceAllкreplace.

Теперь «baseUnitValue» всегда уникально, и поле «id» не оценивается и преобразуется каждые 1000 записей. Я запустил 500 пользователей потокового потока 1 и 1000 пользователей @ 3 цикла. Оригинальная проблема больше не возникает. Еще раз спасибо @ dmitri-t и @ kiril-s.

Дополнительная обратная связь приветствуется.

Answer 1

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

Прежде всего скачайте groovy-all.jar, переместите его в папку «lib» Jmeter и перезапустите JMeter, чтобы выбрать банку.

Редизайн ваш UPDATE записи следующим образом:

• HTTP Request
  • JSR223 PreProcessor

В JSR223 постпроцессор:

1. Использование «заводной» как язык
2. Положите что-то уникальное в «Компиляция кеше» вход

3. Вставьте следующий код в «Сценарий» область:

   vars.put("foobar", vars.get("foobar").replaceAll(vars.get("baseUnitFieldValue"),"11.50")); 
   

Это должно исправить ваш проблема. См. Beanshell vs JSR223 vs Java JMeter Scripting: The Performance-Off You've Been Waiting For! для получения подробных разъяснений, инструкций по установке превосходной поддержки движимого двигателя и лучшей практики написания сценариев.