看到一篇文章，其中部分内容是这样的：
例子：一个高速路有 10 个入口，每个入口每秒钟只能进 1 辆车
1、请问 1 秒钟最多能进几辆车？
TPS=10
2、每辆车需要多长时间进行响应？
reponse time = 1
3、改成 20 辆车，每秒能进几辆？每辆车的响应时间是多长？
TPS = 10，reponse time = 1 (10 个为一等份，分成两等份，平均 tps (10/1+10/2)/2=7.5 平均响应时间 (2+1)/2=1.5
以上问题 3，对于 tps，我的理解是服务端每秒钟能够处理的事务数，应该等于 总的事务数/总的时间，这也跟 jmeter 的计算方式一样，所以 tps 应该是 20/2=10；
然后就有点疑惑了，不知道大佬们能不能帮忙解个惑
问题 3 这个算法很神奇。第一次见到这么拆开求平均的 tps 算法。
平均响应时间公式也不大对，应该是 总请求响应时间/总请求数（10*2+10*1）/ 20 ，虽然结果一样，但意义不一样。
问题 3：前 10 个请求执行用了 1 秒，所以 TPS= 10/1，后 10 个请求执行用了 1 秒，等第一次的请求执行完毕用了 1 秒，所以 TPS = 10/ (1 + 1), 是这个意思吗
闲云野鹤
回复
估计是。但这样计算个人觉得不合理。如果有 100 个，那最后一个批次的 10 个，tps 就是 10/10=1 了，这样 100 个的平均 tps 会比 10 低不少。
但实际上，服务的处理能力并没有下降过，一直都是每秒处理 10 个事务，只是因为有等待，导致响应时间增加了（在题目的理想模型下）。tps 应该只和本身性能有关，这样才符合当 tps 达到本身服务能力上限后，再增加负载 tps 会持平，而响应时间增加的现象。
陈恒捷
回复
我跟你理解一样。但是我在测试时，遇到同一个接口使用不同线程数，得到的 tps 不一样，比如在 30 的时候 tps 能达到 170，但是设置为 100 的时候只有 120，按理说应该是差不多才对
逗爸比
回复
也要看资源消耗情况。个人理解，一般并发高的时候，无法立即处理的请求会放在队列之类的地方等待，这个等待队列本身也有一些资源消耗的，从等待队列挪到处理进程也会比并发低时不用这个动作多一些处理成本。
tps 一般是在可用资源恒定的情况下会保持一个相对稳定的值，但如果资源已经减少（分配了一部分去做等待队列或者别的事情，不参与请求处理），那 tps 也会下降。
我看着这个 10/2 陷入了沉思