Чтобы понять Throughput Controller (TC), просто добавьте один TC и один пробоотборник (внутри TC) и Aggregate Report в комбинации. затем, играйте со всеми параметрами в Throughput Controller.
Из официальной документации:
Всего казни: заставляет контроллер, чтобы остановить выполнение после того, как определенное число казней имели место.
и
Per User: Если флажок установлен, для каждого пользователя будет вызывать контроллер для расчета , должен ли он выполнять на основе одного пользователя (для каждого потока). Если не установлен, то расчет будет глобальным для всех пользователей. Для примера , если используется общий режим выполнения, и снимите флажок «на пользователя», то число, указанное для пропускной способности, будет общее количество выполненных исполнений . Если проверяется «на пользователя», то общее количество исполнений будет количеством пользователей, умножающих число, указанное для пропускной способности.
Прочитайте оба утверждения внимательно несколько раз.
В обоих сценариях, которые вы указали, у вас есть максимальные исполнения 10. (Количество потоков * Количество циклов). Хотя вы указали, Total Executions, как 40 или 60, во-первых, вы должны предоставить более 60, чтобы просмотреть все эти итерации 40/60. Поэтому всегда указывайте больше итераций (используя количество потоков & Loop Count), чем Total Executions.
You have to consider Percentage Executions instead of Total Executions to match your requirements. Опять же, я предлагаю моделировать один образец и понимать поведение, варьируя процентные соотношения.
Ниже приведены некоторые сценарии и ожидаемое поведение (EB).
Сценарий: 1
Thread Group - 10, Loop Count - 1, пропускная способность - 40 (Всего Исполнения), Per User - Проверено.
EB: Sampler будет работать только 10 раз.
Сценарий: 2
Thread Group - 40, Loop Count - 1, пропускная способность - 40 (Всего Исполнения), Per User - Проверено.
EB: Sampler будет работать только 40 раз.
Сценарий: 3
Thread Group - 40, Loop Count - 1, пропускная способность - 40 (Всего Исполнения), Per User - Неконтролируемый.
EB: Sampler будет работать только 40 раз.
Сценарий: 4
Thread Group - 100, Loop Count - 1, пропускная способность - 40 (Всего Исполнения), Per User - Проверено.
EB: Sampler будет работать только 100 раз. рассчитывается, выполняется ли каждый пользователь 40 раз. Поскольку предел не достигнут, он выполняет все 100 итераций.
Сценарий: 5
Thread Group - 100, Loop Count - 1, пропускная способность - 40 (Всего Исполнения), Per User - Неконтролируемый.
EB: Sampler будет работать только 40 раз. рассчитанных на глобальном уровне. Поскольку пробоотборник достиг 40 раз для всех потоков, он прекращает его выполнение.
Сценарий: 6
Thread Group - 100, Loop Count - 40, пропускная способность - 40 (Всего Исполнения), Per User - Проверено.
EB: Sampler будет работать 400 раз (каждый пользователь -> 40 раз, 100 * 40).рассчитывается, выполняется ли каждый пользователь 40 раз. Здесь, даже каждый пользователь предел достигается также и не более казней после 40.
Сценарий: 7
Thread Group - 100, Loop Count - 1, Пропускная способность - 40 (Всего казням), Per User - Не отмечен.
EB: Sampler будет работать только 40 раз. рассчитанных на глобальном уровне. Поскольку пробоотборник достиг 40 раз для всех потоков, он прекращает его выполнение.
Включите ли вы пробоотборники, которые вы хотите отправить внутри контроллера пропускной способности? Этот элемент управляет поведением его дочерних элементов. Возможно, вы можете добавить экран со своим сценарием Jmeter, чтобы лучше понять, чего вы пытаетесь достичь. – Michal
Да, внутри него есть один пробоотборник. его только один, потому что перед его внедрением я хотел это понять. – Keshav