/ask 每秒钟 3500 个请求，mrt 是 200ms，那对应 tps 应该是多少？
要计算每秒处理的事务数（TPS），我们首先需要将每秒的请求数 (Requests per Second, RPS) 与平均响应时间 (Mean Response Time, MRT) 结合起来。我们需要将 MRT 转换为每秒的时间单位，然后使用 RPS 除以转换后的每秒 MRT。
给定的条件是：
RPS = 3500
MRT = 200ms（0.2 秒）
每秒响应时间 (MRT_Per_Second) = 1/MRT 秒
MRT_Per_Second = 1/0.2 = 5
最后，我们计算 TPS：
TPS = RPS x MRT_Per_Second
TPS = 3500 * 5
TPS = 17500
所以，在这个条件下，事务处理每秒（TPS）应为 17500。
大佬们，上述问题 GPT4.0 回答的对吗？
我怎么觉得是 3500*200/1000=700 呢
经过 GPT4.0 自己检查，他的思路是错误的，结果就是 3500*200/1000=700
这个计算公式感觉怪怪的，不能基于请求数 +MRT，计算 TPS 吧。TPS 计算公式，我了解只有 总事务数/总时间（单位秒）这个公式。
TPS 是每秒事务完成数，在系统配置不变的情况下，当请求压力达到让各个线程达到满负荷运行时，一般是一个相对稳定的值。此时再增大压力，TPS 不变，响应时间增大，所以 TPS 其实和响应时间没什么关系。响应时间的增大背后，是系统内部处理不过来，导致新的请求得放到队列里等待，造成额外的等待时间。
而你这个计算公式里，是把响应时间纳入进去来计算 TPS 的，这个和我认知有比较大的出入。
我怎么觉得这个计算是对的
3500 个请求 平均 200ms 完成
=》在 0 秒发送 3500 个请求后 0.2ms 就收到所有的返回。
=》如有上面是对的
=》所以对于服务器来讲 200ms 处理完 3500 个请求。
=》在 0.2 秒发送 3500 个请求后 0.4ms 就收到所有的返回。
.....
=>1 秒内共计发送 3500*5=17500 个
实际上可能达不到 17500 个，要低于这个；个人理解。
每秒钟只能处理 3500 个请求，那么 TPS 就是 3500，管他响应时间是多少呢，废条件~
如果并发是 3500，响应时间 200ms，那么 TPS = 3500 * (1000 / 200) = 17500
我有个疑问，现在的并发只有 3500，平均处理时间是 200 ms.;但是不等同于可以推算出来 如果平均每秒可以处理的是 3500*5 吧？ 实际上随着你并发数增加，系统的响应时间往往会下降，比如到了某个拐点，突然处理性能大幅度下降，甚至奔溃呢？
所以是不是要继续增加并发，来达到系统的满负荷状态？
我感觉性能测试，就聚焦一个指标，比如 tps 就可以了。就去压 tps，在 tps 达标的情况下，再看其他数据。
路客
回复
这种是一本正经地胡说八道的答案，可以用下面两个点推敲下：
1、没有用上 3500 个请求这个条件，公式考虑不够周全
2、MTR 已经是 200ms 了，而 TPS 是每秒处理数数，毫秒转秒应该是乘以 1000，不是除以 1000
恒温
回复
赞同。
对于单接口来说，tps 可以用来表示系统最大处理能力的指标。当 tps 已经达到系统极限后，增大压力只会引起内部请求排队等待，进而增大响应时间，系统性能并没有什么变化。
tps 翻译一下就是每秒处理的事务数量，跟响应时间没有必然联系，因为响应时间的成分非常复杂，响应时间=网络传输时间 + 系统排队时间 +cpu 处理时间。理论上 tps=1 秒/cpu 处理时间，但是 cpu 处理时间需要在业务上打点计时。所以直接发送大量强求，降低网络传输时间和系统排队时间带来的误差，这时 tps=总请求数/总耗时。
