性能测试工具 Jmeter 的各类吞吐量定时器真的能准确限制结果 TPS 的值吗?

今晚打老虎 · 2022年08月15日 · 最后由 今晚打老虎 回复于 2022年08月17日 · 4304 次阅读

前段时间看到一个场景:
“采用递增模式压测,保持 50TPS 下运行 600 秒”
当时也是想到了吞吐量控制器之类的配置,可是实际操作验证后发现结果 TPS 并没有被限制住,所以来此请教各位大佬
TPS 在性能测试场景中能否作为前置条件被准确控制?

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 9 条回复 时间 点赞

可以试着加一个固定时间来进行精准控制

必须可以

加个 jp@gc - Throughput Shaping Timer 不就搞定了。另外是保持 50QPS 下运行 600 秒,而不是 TPS

sakura1 回复

配合 Throughput Shaping Timer 吗?我看这里目标还是 RPS 的控制

Pactortester 回复

看了下官方文档,关于吞吐量定时器内吞吐量参数的解释是:
Throughput we want the timer to try to generate(我们希望计时器尝试生成的吞吐量。).
只是给个期望值,而且还注明了一些影响因素:
Of course the throughput will be lower if the server is not capable of handling it, or if other timers or time-consuming test elements prevent it.(当然,如果服务器无法处理它,或者如果其他计时器或耗时的测试元素阻止它,吞吐量将会降低。)

最近用到常量吞吐量控制器,总结主要两点:

  1. 线程数设置要足够。 调整线程数,直到能快速产生足量 tps
  2. 检查吞吐量计数器设置是否合理。 选"all active threads in current thread group",实际产生吞吐量会更接近目标值;
    选"this thread only",实际吞吐量=设置线程数 * 设置吞吐量数值,但不稳定
Stay 回复

是的,吞吐量定时器 +Throughput Shaping Timer,可是并不理想,而且 Throughput Shaping Timer 是作用于 RPS。
场景就是对 TPS 的要求,一开始我也想当然的和普遍的请求压力联系在了一起,可是了解后确定就是 TPS 的前置

QPS!=TPS

迷龙 回复

我知道老哥,我开始也以为是 qps,可是确定后说就是 TPS 前置。。。我当时第一想法也是,拿着结果做前置??

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册