在学习极客时间性能测试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。
