Jmeter 5.1.1 вроде 🤔

Что-то не так?

вот так в 5.2.1:

…
# Remote batching support
# Since JMeter 2.9, default is MODE_STRIPPED_BATCH, which returns samples in
# batch mode (every 100 samples or every minute by default)
# Note also that MODE_STRIPPED_BATCH strips response data from SampleResult, so if you need it change to
# another mode
# Batch returns samples in batches
# Statistical returns sample summary statistics
# mode can also be the class name of an implementation of org.apache.jmeter.samplers.SampleSender
#mode=Standard
#mode=Batch
#mode=Statistical
#Set to true to key statistical samples on threadName rather than threadGroup
#key_on_threadname=false
#mode=Stripped
#mode=StrippedBatch
#mode=org.example.load.MySampleSender
…

да и в предыдущих версиях этот кусок не менялся вроде; в общем, стоит туда добавить пропертю mode)

а за что отвечает этот параметр?

не, не так - в какой ситуации он тебе понадобился?) @AlexeyCherkashin

назрел еще вопрос дискуссионный)
зачем повышать количество тредов при поиске максимума например, когда это hit-based, пропорционально тпсам? то есть делают две лесенки в Thread Group и Shaping Timer, например. можно же быстро выйти и зафиксировать количество тредов на достаточно высоком значении, чтобы обеспечить нужный уровень тпс на всем протяжении теста

в сценарии когда лесенки две - однозначно нельзя понять, на приложение так влияет количество "коннектов" или количество тпс

есть мнения почему например в LR делается по дефолту именно так? и почему так крайне часто практикуют?

При распределенгом старте, во время отладки для получения результата мне приходится ждать либо минуту, либо пачку из 100 результатов 😭

За способ отправки с Серверов метрик

То есть времени отклика или ошибка, итд, я о них...

а, точно - понял

Добрый день) кто-нибудь сталкивался с ограничением tps при тесте приложения на weblogic? В ресурсы не упираюсь)

Сколько бы не заслал в weblogic потоков, tps за весь тест один и тот же, нет ни роста ни деградации

Мб какие то настройки wb?

а мониторинги то есть?

Всем привет! Кто нибудь нагружал Siebel с помощью jmeter? С какими трудностями/проблемами сталкивались?

Если я правильно понимаю jmeter и предпосылки:
- Thread != коннект. Если keepalive выключен (что по дефолту).
- Тред блокируется на время ожидания ответа от сервера.
- Jmeter thread == Java thread
Верны:

То имеет смысл делать RPS = threads. Потому что если ответ от сервера будет медленнее предполагаемого ожидания для одного треда. То это затормозит остальные запросы которые должны выполняться на этом же треде.

К примеру есть 100 тредов и хочется 1000 RPS.
Значит каждый тред должен выполнить реквест за 100мс
Если же один один тред выполнит реквест за 200мс то финальный RPS будет уже 999.

Или можно поставить таймаут который будет освобождать тред. тогда да

Ну а иметь сильно больше тредов тоже не хорошо, так как это память, context switches, etc..

ладно,  а если изначально перезаложить количество тредов, то пропорционалтный их рост все таки не имеет смысла?)

не имеет)
но какой бенефит от раннего создания тредов?
Они будут шататься в системе пока тест не выйдет на максимальное значение.

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