请求协助：基于给定需求计算迭代时间与Pacing Time以达成50TPH

参数拆解与核心逻辑 #

目标每小时50次事务（TPH），5个并发用户，测试时长1小时：

• 每个用户每小时需完成的事务数：50 / 5 = 10 次
• 单个用户的完整迭代周期（事务执行时间 + Pacing等待时间）需固定为：3600秒 / 10次 = 360秒/次

迭代时间与Pacing Time的计算公式 #

• 迭代时间：单个用户完成一次事务的实际执行时长（含事务内的思考时间，不含后续等待的Pacing时间），需通过实际测试测得平均值。
• Pacing Time：用户完成事务后等待再发起下一次请求的时间，公式为：

Pacing Time = 单个用户目标迭代周期 - 实际迭代时间

举个实际例子：如果测试测得单个事务的迭代时间为70秒，那么需要设置的Pacing Time为 360 - 70 = 290秒。这样每个用户每360秒发起一次事务，5个用户每小时总事务数刚好是5×10=50，达成目标TPH。

实际TPH达80的原因及修正 #

TPH超标说明客户端发起请求的频率远高于目标值，常见原因及解决方法：

• 未设置Pacing Time：用户完成事务后立刻发起下一次请求，导致迭代周期仅等于实际事务执行时间。此时需按照上述公式计算目标Pacing Time，用该值限制请求间隔。
• Pacing Time设置过短：如果已经设置了Pacing但仍超标，说明设置的等待时间不足以拉长迭代周期到360秒，重新计算并调整Pacing Time即可。

Little定律的误用说明 #

你用Little定律未得到预期结果，是因为混淆了系统稳态参数和客户端控制参数：
Little定律 L = λW 是描述系统内部的稳态关系：L是系统中同时处理的请求数（并发请求数），λ是系统实际能承载的吞吐量，W是请求在系统中的平均逗留时间。它用于验证系统的负载能力，而非控制客户端的请求频率。要精准控制客户端的TPH，必须通过设置Pacing Time来固定用户的请求间隔，而非依赖系统负载自动限流。

内容的提问来源于stack exchange，提问作者Bhaskara Reddy Dwarampudi