一般情况下，在做性能测试时，都不会去强调并发的概念。因为现实的场景中，除了秒杀、整点开抢等几类特殊的场景外。都不会进行狭义上的并发测试。与实际的业务场景不符。我们更多的会采用 TPS，响应时间之类的指标来衡量性能。

“登录接口能够承受秒级 1000 并发” 这个性能需求本身就有问题。秒级 1000 并发，也就意味着 TPS 达到 1000（如果是这么理解的话）。那么线程数是多少并不是固定的。因为还要考虑到响应时间。

如果按上面的理解，TPS 要求达到 1000，假设响应时间为 0.5，那就是要 500 的请求量（TPS = Vu/Time，这里暂不考虑网络传输的时间，实际情况会更复杂），至于这 500 的请求量，是通过 50 线程的并发，还是 100 线程的并发，并不重要。因为对于服务器而言，关心的单位时间内到达服务器的请求数，至于这些请求是由多少线程发起的，并不太关心。

不要纠结并发数，TPS 结合响应时间，才是性能的真实指标

Tps 是服务器每秒处理的事务数量，跟多少个线程没有任何关系。多线程只为了产生更大的 rps，而 tps 不可能大于 rps。多线程并发在单核 cpu 上其实是交替执行的，只是切换时间很短，以纳秒计，所以看作是同时运行，这称为并发。还有一个相似的概念叫并行，必须不同的线程运行在不同的 CPU 核心上

TPS，代表服务端的并发处理能力。
jmeter 中有个 Number of Thread 指的是并发用户数。
这两个很容易混淆。
性能测试关注的是 TPS、响应时间和错误率。

tps 是加入了响应时间后计算出来的吧？我理解的是线程数越多 qps 越高，但是 tps 是有个瓶颈的，超过了瓶颈，线程数再多也上不去了，然后超时，错误之类的会增加

并发只是提高 TPS 或 QPS 的一种手段，实际操作中线程数=并发数，但是不等于处理并发能力

秒级 1000 并发需求可以有两种理解：

1. 场景可以支持 1000QPS 或 TPS，不论是高并发还是低并发，能达到就可以（达不到加资源），同时观察响应时间和错误率在合理范围内，给出达到预期的最小并发，另外如果资源冗余再看下资源能支撑的最高并发以及可达到的最高 TPS 或 QPS，评估是否符合预期（适用于流量高峰持续场景）
2. 当前资源下、1000 并发场景下的服务能力在合理范围（响应时间、错误率、资源指标），直接起 1000 并发，看资源情况（适用于秒杀活动那种场景）

这种都要结合实际的性能测试需求，看是哪一种再决定怎么做，不用纠结于字眼。以登陆接口为例的话，我理解更多的是 1000QPS 的概念，而不是 1000 个并发。

两个数据都很重要。

TPS 是最直观的表明服务性能能力的一个指标，但是同样一个服务，在 1000 并发下和 2000 并发下的性能表现可能会差距很大。 1000 并发和 2000 并发对于服务来说，表示不同的连接压力。

举个例子：当服务最大处理能力为 1000TPS 时，当 1000 个并发压测时，平均响应时间为 1 秒。
但是当 2000 个并发压测时，因服务处理能力有限，平均响应时间可能会增加到 1.5 秒。

这个时候，当并发继续增加的时候，服务很可能出现性能拐点（QPS 大幅下降，响应时间大幅增加）。

所以，在日常压测中，开发同学还需要考虑，当大量并发链接请求来临时：
（1）是否会出现性能拐点
（2）到达性能拐点之前，是否需要增加降级方案
（3）对于易引发性能问题的并发数，是否要增加细粒度报警
等等
以及：
（1）在目前的基础上，是否可通过调整配置，来提高服务的 TPS 能力和应对并发的能力

确实是这样，但是现在很多团队还有领导，都认为并发数这个概念是以线程数或者用户数来判定，想要在团队里改变这种观念太难了，甚至有次出完性能报告给甲方后，甲方又找了家第三方有测试资质的机构再次测试了一遍性能，一看第三方的报告，1000 并发就是 1000 个线程，给我整不会了都

比如我 1000 个线程持续压测，但此时 tps 是 100，在某个时间点，有 100 个线程在服务里面，那剩下的 900 个线程是在哪个位置排队呢，在 nginx 里面还是其他地方呢

这是什么理解，用 1000 个线程压测，服务端当然得有 1000 个线程，压测首先要监测服务端增加的线程数跟发起的线程数一致，你都说 tps 是算出来的来表达服务端能力的，跟线程无关。然后你的疑惑我认为可以从业务角度出发，性能测试也是要尽量模拟真实场景对吧，那么同样 1000tps 的登录接口：

1、1000tps = 1000 个用户 1s 内每个用户登录一次
2、1000tps = 100 个用户 1s 内每个用户登录十次

这两个一样吗，是不是还是用 1000 个用户比较接近实际，而且是领导们更关注的是场景 1 我觉得没啥问题。

再一个从实际出发，100 线程想达到 1000 的 tps，那每 s 每个线程都要完成 10 个请求，每个请求只有 0.1s，这也不太现实，一般高并发（线程）才能达到高 tps，所以我认为理解 线程数=并发 没有什么问题

本来就不是一个东西。
不过实际工作中，有些可能是描述上的问题，我们产品爱用并发用户数来描述性能，因为他们关心的是客户端用户情况，他们对服务器处理能力说实话有些没有太大的概念，在他们看来是一回事儿。。。所以提的性能指标需求翻译过来可能就是线程数。

但是做性能测试和分析的人得知道差别。

首先你应该测出 1000 个线程所产生的 qps，纠正一下，我前面描述有误，rps 应该为 qps，也就是测试出 1000 个线程每秒能发送多少个请求，假如你的 CPU 特别垃圾，1000 个线程只能产生 100 个 qps，那你的 CPU 负荷太高，线程可能处于任何状态。假如 1000 个线程产生的 qps 远远大于 100，那说明 CPU 负载有余，那性能瓶颈在服务器，线程大多在等待服务器响应

个人理解，专业的性能测试人员，应该要用 TPS + 响应时间 来描述服务端性能。包括要达到的性能目标以及实际测试出来的性能结果。

• 先来解析下你正文里这两个看起来好像等价的假设：

假设并发理解为线程的话，1000 线程持续执行 60 秒，结果理论上应该产出 60000 条数据才符合需求

其实你这句话里面带有一个预设条件，就是每个请求的响应时间大约是 1 秒。要满足这个场景，性能需要达到 tps = 1000 + 响应时间 = 1s

假设并发理解为 TPS 的话，可能花 30 个线程就可以达到 1000tps 执行 60 秒，结果也能产出 60000 条数据

而从你这句话来倒推，30 个线程能达到 1000 tps ，意味着平均每个线程每秒得产生 33 tps，意味着接口的响应时间必须控制在 1/33（约为 0.03）秒左右。要满足这个场景，性能需要达到 tps = 1000 + 响应时间 = 0.03s

所以，加上响应时间这个指标后，你能明确看出来，这两个场景下对服务端的性能要求其实差了 33 倍了吧？

• 至于为啥大家会喜欢用线程数，我觉得里面有一些历史因素。

以前 LR 类似 JMeter 线程数的东西叫做 virtualUser（虚拟用户），意思是这个就是虚拟有多少个用户在使用。同时为了让这些用户表现更符合实际情况，还会有需要在每个操作之间加入 thinkTime（思考时间，实际就是固定的等待时长）。所以我只需要评估高峰期大概系统会有多少个用户来用，正常用户习惯每次操作之间间隔多久，就可以把这个场景直接输入到性能测试工具里，直接作为性能场景使用了。

但随着时间推移，这个思考时间越来越少人用或者考虑，因为不管设定多少都很难靠谱，而且思考时间差 1 秒，实际发起的压力就会有很大差异。但虚拟用户转变为线程数继续留在了 Jmeter 里，所以大家会习惯继续这么称呼，毕竟老板和产品更能听懂 “并发用户数” 这类词。但实际上只要稍微想细一点，就会发现不精确，因为这个场景下，线程和实际用户的核心差异是，线程得到响应后会立即再次发起请求，但实际用户谁有空没事做会一直不间断给你发请求呢。

因此，一个合格的性能测试工程师，应该能做好翻译工作，把老板和产品的想法，转换为专业的性能指标，应用到性能测试里。

一般高并发（线程）才能达到高 tps

这个结论和我日常认知差异有点大，建议你试试用 10 个线程去测试某个逻辑比较简单的接口，然后换 100 个线程再测一次，对比看下 10 个线程下的 tps ，和 100 线程下的 tps ，差异会不会很大？

翻到一篇阿里云大佬写的，现在性能这块应该是分成了两个派系，一派是并发，一派是 TPS，但是两个流派都能通过分析和调优解决问题。

https://developer.aliyun.com/article/709950

看了后思路突然打开了，既然线程数和 TPS 都能解决问题的话，那其实配合团队目前的水平更改测试方式才是正确的。

我目前也是这样理解的，而且实际压测过程中拿着 TPS 和响应时间找开发运维进行调优的时候他们也比较有方向，调优的目的只有一个，就是减少响应时间增加 TPS。但现在换了个团队之后概念这块都要重头来，并发这块统一口径挺难的，要么争论要么加入。

一般不是业务和产品喜欢用并发用户数 +rt，开发运维喜欢用 tps+rt 吗？你意思是现在开发和运维也喜欢用并发用户数了？

目前待的这个团队，性能指标只有并发用户数，只要不报错就继续加线程 ，开发可能为了省事也同意这个指标，昨天特地为这个争论了一下，没啥作用。

如果实在无法改变，那就先保持一致吧。

我一般的做法是，把产品的性能需求想办法转换为 tps+rt 目标指标，然后再去拿这个来和开发运维沟通以及出报告。一般其他角色只要觉得你的转换思路听起来是靠谱的，那他们也不会说你非得怎么怎么样，毕竟这个不是他们专业范畴，一讲深他们其实也就听不懂了。

交流一下，这是一个简单的查询接口 10 并发和 50 并发下的结果，理想情况下，响应时间应该一样，而 tps 变成 5 倍，实际上响应时间些许增加，这个跟我发送速率没有达到 5 倍也有关

在服务端能力没有到达拐点之前，并发增加，响应时间应该几乎不变，而 tps 也会增加，或者说不增加并发是没法测到 tps 的最大值，这有什么问题请指教

不好意思，确实我之前逻辑不够严谨。在服务端没有达到满负荷（即服务端每个处理线程都在工作中没有闲置，也是我们俗称的性能拐点）时，确实是压测工具的线程数增加，响应时间不变，tps 增加。

我其实核心不认同的应该是 线程数=并发 这个观点。我对这个观点的理解是：针对正文里的 登录接口能够承受秒级 1000 并发 ，就应该用假设 1 里面的 1000 个线程去发起压力，并要求响应时间达标。

在我的经验里，一般在线程数在比目标 tps 低不少的时候，系统就可以达到目标 tps 了。真要用和用户数一样的线程数去压且不考虑思考时间（现在越来越少人用这个了），容易给到过大的压力。

针对正文里的 登录接口能够承受秒级 1000 并发 ，就应该用假设 1 里面的 1000 个线程去发起压力，并要求响应时间达标。

我也是这么理解，没毛病

• QPS（Queries Per Second）：每秒的用户访问量（也有叫 RPS 的）
• TPS（Transcations Per Second）：每秒的 Transcations 数量（Transcation 是一个抽象概念所以不好用中文直翻，可以类比事务，个人理解是业务单个分支的完整流程，而完整的业务流程可能是多个分支一同完成）

QPS is basically similar to TPS, but the difference is that a single visit to a page forms a TPS; however, a page request may generate multiple requests to the server, which can be included in the “QPS”.

上述出自链接。

在搞明白概念的区别之后，再来看术语的应用场景。性能测试关注点是性能上，所以只要把性能解释清楚就好，在不同的公司，无论对与错，无论术语用得专不专业，只要大家都知道在说同一个东西其实也还好。

回到问题上，性能测试关注的是性能，而制造性能压力一般来源于并发访问量和能使用的资源，所以我们要描述压力大小，就相当于要描述并发量以及提供给系统的资源量。

TPS 和 QPS 对比，按照老外的解释，TPS 是一个更内部更拆解的概念，在业务足够简单的情况下它可以跟 QPS 等价；QPS 是更面向用户的概念，它把整个系统看成整体，不管你系统内部怎么运作，现在每秒多一个访问过来那就是 QPS 加一，更直观更好理解也更容易统计，所以我推荐用 QPS 来表示并发或者压力程度，当然单纯说 QPS 是没用的，还要加上请求正常响应比例等条件的约束才有实际分析意义，就不展开扯了。

还有一个很重要的点，要区分好线程数和 QPS 两个概念，个人感觉之所以会把线程数等价于 QPS，可能是习惯将 Jmeter 世界里的概念搬到其他场景来。因为 Jmeter 实现发压是基于多线程模型，不严谨地说就是一个线程发一个请求，很古老的 I/O 模型，在当时可能是很好的方案，但现在看来会有局限。对比与 Locust、Gatling、K6 等更新一代的压测工具，使用更高效的 I/O 模型更有利于榨干发压机的性能，这个时候就再也不是一个线程等价一个请求。所以，不能用线程数来代表并发，而是用该以实际发了多少请求给服务器来统计并发。这篇文章写得很好建议阅读。

有点不太理解, 为什么要用假设 1 中的 1000 线程呢.
假如: 登录接口的响应时间平均 0.2 秒. 那么 1000 个线程会造成 5000/s 的 TPS 吧 (服务器没达到瓶颈的前提下). 而这个测试的需求: 秒级 1000 用户并发. 理解为 1000/s TPS 去测的话, 200 个线程数就够了.

前段时间做过一些系统的性能测试, 如果将常说的 1000 并发理解为 1000 线程话, 如果响应时间低于 1s 的时候, 很容易造成大于 1000/s 的 TPS 压力, 导致服务器过载.

所以现在我们的思路就是当开发提到某某接口预计要能支持 1000 并发的时候, 如果响应时间要求低于 1s, 我们往往会转化为 1000TPS 的目标去测. 而如果响应时间要求低于 2s, 那么就按照 1000/2s 的 TPS 去测. 这样出的结果, 也比较容易和运维抓到的客户当前的请求量相结合匹配.

所以, 是我理解错了吗