关于TPS的公式

在学习极客时间性能测试30讲中，有不错的描述，总结如下：
 

这里有一个比较严重的理解误区，那就是压力工具中的线程或用户数到底是不是用来描述性

能表现的？我们通过一个示意图来说明：

通过这个图，我们可以看到一个简单的计算逻辑：

1. 如果有 10000 个在线用户数，同时并发度是 1%，那显然并发用户数就是 100。

2. 如果每个线程的 20TPS，显然只需要 5 个线程就够了（请注意，这里说的线程指的是压

力机的线程数）。

3. 这时对 Server 来说，它处理的就是 100TPS，平均响应时间是 50ms。50ms 就是根据

1000ms/20TPS 得来的（请注意，这里说的平均响应时间会在一个区间内浮动，但只要

TPS 不变，这个平均响应时间就不会变）。

4. 如果我们有两个 Server 线程来处理，那么一个线程就是 50TPS，这个很直接吧。

5. 请大家注意，这里我有一个转换的细节，那就是 并发用户数到压力机的并发线程数 。这

一步，我们通常怎么做呢？就是基准测试的第一步。关于这一点，我们在后续的场景中

交待。 而我们通常说的“并发”这个词，依赖 TPS 来承载的时候，指的都是 Server 端的处理能

力，并不是压力工具上的并发线程数。在上面的例子中，我们说的并发就是指服务器上

100TPS 的处理能力，而不是指 5 个压力机的并发线程数。 请你切记这一点，以免沟通障

碍 。

在我带过的所有项目中，这都是一个沟通的前提。

所以，我一直在强调一点，这是一个基础的知识： 不要在意你用的是什么压力工具，只要在

意你服务端的处理能力就可以了 。

示例

上面说了这么多，我们现在来看一个实例。这个例子很简单，就是：

JMeter（1 个线程） - Nginx - Tomcat - MySQL

通过上面的逻辑，我们先来看看 JMeter 的处理情况：

 复制代码

1 summary + 5922 in 00 : 00 : 30 = 197.4 /s Avg: 4 Min: 0 Max: 26 Err:

2 summary = 35463 in 00 : 03 : 05 = 192.0 /s Avg: 5 Min: 0 Max: 147 Err:

3 summary + 5922 in 00 : 00 : 30 = 197.5 /s Avg: 4 Min: 0 Max: 24 Err:

4 summary = 41385 in 00 : 03 : 35 = 192.8 /s Avg: 5 Min: 0 Max: 147 Err:

5 summary + 5808 in 00 : 00 : 30 = 193.6 /s Avg: 5 Min: 0 Max: 25 Err:

6 summary = 47193 in 00 : 04 : 05 = 192.9 /s Avg: 5 Min: 0 Max: 147 Err:

我们可以看到，JMeter 的平均响应时间基本都在 5ms，因为只有一个压力机线程，所以它

的 TPS 应该接近 1000ms/5ms=200TPS。从测试结果上来看，也确实是接近的。有人说

为什么会少一点？因为这里算的是平均数，并且这个数据是 30s 刷新一次，用 30 秒的时间

内完成的事务数除以 30s 得到的，但是如果事务还没有完成，就不会计算在内了；同时，

如果在这段时间内有一两个时间长的事务，也会拉低 TPS。

那么对于服务端呢，我们来看看服务端线程的工作情况。 可以看到在服务端，我开了 5 个线程，但是服务端并没有一直干活，只有一个在干活的，

其他的都处于空闲状态。

这是一种很合理的状态。但是你需要注意的是，这种合理的状态并不一定是对的性能状态。

1. 并发用户数（TPS）是 193.6TPS。如果并发度为 5%，在线用户数就是

193.6/5%=3872。

2. 响应时间是 5ms。

3. 压力机并发线程数是 1。这一条，我们通常也不对非专业人士描述，只要性能测试工程

师自己知道就可以了。

下面我们换一下场景，在压力机上启动 10 个线程。结果如下：

 复制代码

1 summary + 11742 in 00 : 00 : 30 = 391.3 /s Avg: 25 Min: 0 Max: 335 Err:

2 summary = 55761 in 00 : 02 : 24 = 386.6 /s Avg: 25 Min: 0 Max: 346 Err:

3 summary + 11924 in 00 : 00 : 30 = 397.5 /s Avg: 25 Min: 0 Max: 80 Err:

4 summary = 67685 in 00 : 02 : 54 = 388.5 /s Avg: 25 Min: 0 Max: 346 Err:

5 summary + 11884 in 00 : 00 : 30 = 396.2 /s Avg: 25 Min: 0 Max: 240 Err:

6 summary = 79569 in 00 : 03 : 24 = 389.6 /s Avg: 25 Min: 0 Max: 346 Err:

平均响应时间在 25ms，我们来计算一处，(1000ms/25ms)*10=400TPS，而最新刷出来

的一条是 396.2，是不是非常合理？

再回来看看服务端的线程：

同样是 5 个线程，现在就忙了很多。

1. 并发用户数（TPS）是 396.2TPS。如果并发度为 5%，在线用户数就是

396.2/5%=7924。

2. 响应时间是 25ms。如果要有公式的话，这个计算公式将非常简单：
 

 

我不打算再将此公式复杂化，所以就不再用字母替代了。

这就是我经常提到的， 对于压力工具来说，只要不报错，我们就关心 TPS 和响应时间就可

以了，因为 TPS 反应出来的是和服务器对应的处理能力，至少压力线程数是多少，并不关

键 。我想这时会有人能想起来 JMeter 的 BIO 和 AIO 之争吧。

你也许会说，这个我理解了，服务端有多少个线程，就可以支持多少个压力机上的并发线

程。但是这取决于 TPS 有多少，如果服务端处理的快，那压力机的并发线程就可以更多一

些。

这个逻辑看似很合理，但是通常服务端都是有业务逻辑的，既然有业务逻辑，显然不会比压

力机快。

应该说，服务端需要更多的线程来处理压力机线程发过来的请求。所以我们用几台压力机就

可以压几十台服务端的性能了。

如果在一个微服务的系统中，因为每个服务都只做一件事情，拆分得很细，我们要注意整个

系统的容量水位，而不是看某一个服务的能力，这就是拉平整个系统的容量。

我曾经看一个人做压力的时候，压力工具中要使用 4000 个线程，结果给服务端的 Tomcat

上也配置了 4000 个线程，结果 Tomcat 一启动，稍微有点访问，CS 就特别高，结果导致

请求没处理多少，自己倒浪费了不少 CPU。