在学习极客时间性能测试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:
Max:
26
Err:
2
summary =
35463
in
00
:
03
:
05
=
192.0
/s Avg:
5
Min:
Max:
147
Err:
3
summary +
5922
in
00
:
00
:
30
=
197.5
/s Avg:
4
Min:
Max:
24
Err:
4
summary =
41385
in
00
:
03
:
35
=
192.8
/s Avg:
5
Min:
Max:
147
Err:
5
summary +
5808
in
00
:
00
:
30
=
193.6
/s Avg:
5
Min:
Max:
25
Err:
6
summary =
47193
in
00
:
04
:
05
=
192.9
/s Avg:
5
Min:
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:
Max:
335
Err:
2
summary =
55761
in
00
:
02
:
24
=
386.6
/s Avg:
25
Min:
Max:
346
Err:
3
summary +
11924
in
00
:
00
:
30
=
397.5
/s Avg:
25
Min:
Max:
80
Err:
4
summary =
67685
in
00
:
02
:
54
=
388.5
/s Avg:
25
Min:
Max:
346
Err:
5
summary +
11884
in
00
:
00
:
30
=
396.2
/s Avg:
25
Min:
Max:
240
Err:
6
summary =
79569
in
00
:
03
:
24
=
389.6
/s Avg:
25
Min:
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 就特别高，结果导致
![浅谈---测试Native Windows Command与Native PowerShell Command哪个效率高[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)