因为一个线程完全有可能模拟多个请求，而不只是一个。线程池、并发执行等机制都可能导致每个线程并不是简单的一对一对应一个请求。 1.每个线程可能模拟了多个请求，这就使得吞吐量看起来大于并发用户数。 2.系统可能在处理过程中出现了一些请求失败的情况，这样实际TPS就会小于吞吐量。
之前刷到过一张图片，图片显示（ps.翻了一下，没翻到）：...
并发是同一时刻有多少个请求进来，qps是每秒服务能处理的请求数量，虽然你这里的最大并发是58，假设你的服务半秒钟就可以把这58个请求全部处理掉，那么qps肯定大于58了
因为一个线程完全有可能模拟多个请求，而不只是一个。线程池、并发执行等机制都可能导致每个线程并不是简单的一对一对应一个请求。 1.每个线程可能模拟了多个请求，这就使得吞吐量看起来大于并发用户数。 2.系统可能在处理过程中出现了一些请求失败的情况，这样实际TPS就会小于吞吐量。
之前刷到过一张图片，图片显示（ps.翻了一下，没翻到）：...
并发是同一时刻有多少个请求进来，qps是每秒服务能处理的请求数量，虽然你这里的最大并发是58，假设你的服务半秒钟就可以把这58个请求全部处理掉，那么qps肯定大于58了