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

必须可以

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

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

看了下官方文档，关于吞吐量定时器内吞吐量参数的解释是：
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"，实际吞吐量=设置线程数 * 设置吞吐量数值，但不稳定

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

QPS！=TPS

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