Потоки JMeter запускаются один раз, в то время как счетчик цикла установлен на «навсегда» с таймером постоянной пропускной способности

У меня есть план тестирования в JMeter, который тестирует базу данных memSQL, которая, кажется, запускает каждый поток только один раз, а не работает вечно.

  • Он имеет 3 группы потоков.
  • Каждый имеет свой собственный элемент запроса JDBC (1 для удаления, 1 для вставки, 1 для выбора).
  • Я хочу, чтобы все запросы считывали параметры из файла csv. Я попробовал свой тест с 1 элементом конфигурации набора данных CSV для всего плана тестирования (с режимом совместного использования, установленным для всех активных потоков) и 1 для каждой из групп потоков (с режимом, установленным на текущую группу потоков).
  • Элементы запроса JDBC для удаления и вставки имеют подготовленный оператор обновления, установленный для атрибута типа запроса.
  • Один элемент запроса для выбора имеет значение подготовленного оператора выбора, установленное для этого поля.
  • Во всех случаях, которые я пробовал, для атрибутов конфигурации набора данных CSV были установлены следующие значения: Recycle on EOF - True, Stop thread on EOF - false.
  • Я использую постоянный элемент таймера пропускной способности для всего плана тестирования. Он установлен на Все активные потоки (общие) для атрибута на основе.
  • Как упоминалось в заголовке - для каждой группы потоков всегда отмечен флажок счетчика циклов. Планировщик НЕ используется, и в случае ошибки выбирается кнопка продолжения (хотя ее нет).
  • В сводном отчете я не получаю исключений java из db. Только время вывода запроса и время задержки.

Как уже было сказано, я пробовал 1 исходный файл csv для всех групп потоков. Теперь я создал 3 разных файла csv, и проблема не устранена. Я попытался установить время нарастания всех потоков на 0, 0,1, 1, 2, и все равно не повезло.

Посмотрев в созданный мной сводный отчет, я всегда вижу одинаковое количество выборок. У меня есть 3 группы потоков, каждая по 80 потоков, поэтому я всегда получаю 240 одинаковых запросов. Даже если тест длился 1, 2, 3 минуты и т. Д. Я попытался завершить тест выключением и остановкой, и с обоими я получил одно и то же число.

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


database testing jmeter threadgroup loop-counter
person Nexaspx    schedule 27.01.2019    source источник
comment
Можете ли вы показать конфигурацию таймера постоянной пропускной способности?   -  person UBIK LOAD PACK    schedule 27.01.2019
comment
@UBIKLOADPACK Вы правы в своем запросе. Я только что обнаружил проблему. Это было с запросами в минуту в конфиге таймера. Я скоро опубликую здесь свою ошибку и решение.   -  person Nexaspx    schedule 27.01.2019

Ответы (1)


arrow_upward
2
arrow_downward

TL; DR

Кажется, что все конфигурации были правильными, но фактическое количество запросов в таймере постоянной пропускной способности было слишком низким. Кроме того, JMeter пытается установить пропускную способность в минуту, поэтому тесты должны быть длиннее 1 или 2 минуты с таймером.

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

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

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

person Nexaspx    schedule 27.01.2019