Тестирование с JMeter: как выполнить N запросов в секунду

Question

Мне нужно проверить, может ли наша система выполнять N запросов в секунду.Технически, это 2 запроса к одному API, 2 запроса к другому и 6 запросов к третьему.Но главное, что они должны происходить одновременно - так 10 запросов в секунду.Итак, в JMeter я создал три группы потоков, сначала определяет количество потоков 1 и время разгона 0. Вторая группа потоков такая же, а третья группа потоков определяет количество потоков 6 и время разгона 0. Ноэто не гарантирует, что они будут запускаться в секунду Как мне эмулировать это?И как я вижу результаты - если это было в состоянии выполнить или не было?

Спасибо!

Answer 1

Вы можете использовать ConstantThroughputTimer.

Цитата из файлов справки JMeter ниже:

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

Например, я использовал его для генерации 40 запросов в секунду:

 <ConstantThroughputTimer guiclass="TestBeanGUI" testclass="ConstantThroughputTimer" testname="Constant Throughput Timer" enabled="true">
      <stringProp name="calcMode">all active threads in current thread group</stringProp>
      <doubleProp>
        <name>throughput</name>
        <value>2400.0</value>
        <savedValue>0.0</savedValue>
      </doubleProp>
    </ConstantThroughputTimer>

И вот резюме:

Created the tree successfully using performance/search-performance.jmx
Starting the test @ Tue Mar 15 16:28:39 CET 2011 (1300202919244)
Waiting for possible shutdown message on port 4445
Generate Summary Results +  3247 in  80,3s =   40,4/s Avg:    18 Min:     0 Max:  1328 Err:   108 (3,33%)
Generate Summary Results +  7199 in 180,0s =   40,0/s Avg:    15 Min:     1 Max:  2071 Err:   378 (5,25%)
Generate Summary Results = 10446 in 260,3s =   40,1/s Avg:    16 Min:     0 Max:  2071 Err:   486 (4,65%)
Generate Summary Results +  7200 in 180,0s =   40,0/s Avg:    14 Min:     0 Max:   152 Err:   399 (5,54%)
Generate Summary Results = 17646 in 440,4s =   40,1/s Avg:    15 Min:     0 Max:  2071 Err:   885 (5,02%)
Generate Summary Results +  7199 in 180,0s =   40,0/s Avg:    14 Min:     0 Max:  1797 Err:   436 (6,06%)
Generate Summary Results = 24845 in 620,4s =   40,0/s Avg:    15 Min:     0 Max:  2071 Err:  1321 (5,32%)

Но я запускаю этот тест в своей сети.

Answer 2

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

Как правило, когда показатели производительности специфичны х в секунду, они измеряются в течение определенного периода времени. Ваш API может даже иметь буфер - так что вы могли бы технически отправлять 6 в секунду, но обрабатывать 5 в секунду с буфером 20, что означает, что было бы хорошо для 20 секунд трафика, как вы бы отправили 120, что займет 120/5 = 24 секунды для обработки. Но больше, чем это переполнит буфер. Так что просто отправить ровно 6 в секунду для проверки недостаточно.

В группе потоков вы правы, установив число потоков (пользователей) равным 6. Затем запустите его цикл навсегда (поставьте галочку или поместите его в цикл while) и добавьте прослушиватель, например, сводный отчет и дерево результатов. Результаты, которые вы можете использовать для проверки правильности отправляемых данных и ответов на них (при условии, что вы подтвердите ответы), и в сводном отчете вы можете увидеть, сколько из каждого действия происходит в час (очевидно, умножить на 3600 за секунды, но из-за этой неточности лучше всего запустить его в течение длительного времени).

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

Answer 3

Используйте Таймер формирования пропускной способности

Answer 4

У меня была похожая проблема, и вот два решения, которые я нашел:

Решение 1:
Вы можете использовать Stepping Thread Group (позволяет установить этапы увеличения номера потока за установленные периодывремени) с постоянным таймером пропускной способности в нем.Таймер пропускной способности позволяет установить количество выборок, которое поток может отправлять в минуту (например, если вы установите его равным 1, поток будет отправлять только один запрос в минуту).Кроме того, вы можете применить пропускной таймер ко всем потокам в вашей группе потоков или иметь таймер для каждого потока с его собственными настройками.Подробнее о таймере пропускной способности читайте здесь: https://www.blazemeter.com/blog/how-use-jmeters-throughput-constant-timer

Решение 2:
Используйте «Группу потоков SetUp».Вы можете рассчитать номер потока и время увеличения, чтобы получить желаемое количество потоков в секунду.

Answer 5

Вы можете использовать Функция обратной связи по расписанию , а также потребуется группа потоков параллелизма