性能测试-

目录

一、概念

二、性能测试需要有模型

三、性能测试要有方案

四、性能测试中要有场景

五、IO响应时间

六、是否性能调优

 七、TPS

八、并发度的分析

 九、响应时间

响应时间的 258 原则合理吗？

十、异常场景的性能需求指标

十一、业务指标和性能指标之间的关系​

 十二、并发

 十三、用户数怎么计算

十四、线程数递增方法

 十五、性能衰减的过程

十六、性能方案

十七、容量场景

---

一、概念

        性能测试是针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。

        性能项目是有宏观目标的：

• 找到系统中的性能瓶颈并优化掉；
• 满足业务容量的要求，保障线上系统可以正常运行。

        一个完整的性能工程来看，一个系统上线并经过正常的业务场景之后，我们还需要做一件事情：把线上的性能数据拿回来，和性能测试过程中的数据做环比，看之前做的是否满足真实的业务场景。而环比的内容就是我们的性能模型、性能指标等。

        性能工程是指，通过分析业务逻辑和技术架构，创建性能模型，制定性能方案，准备应用环境，设计并实施性能部署监控，实现符合真实业务逻辑的压力，通过监控手段获取各组件的性能计数器，分析计数器采集出的数据，查找出性能瓶颈的根本原因并优化，最后通过环比生产环境的性能数据修正场景。        

二、性能测试需要有模型

模型是什么？它是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。比如说，我们有 100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。这种做法需要的数据通常都是从生产环境中的数据中统计来的，很多在线上不敢直接压测的企业都是这样做的。

三、性能测试要有方案

方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。基本上有这些内容就够了，这些内容具体的信息还需要精准。

使用-x参数我们可以获得更多统计信息。

四、性能测试中要有场景

可以说，“性能场景”这个词在性能测试中占据着举足轻重的地位，只是我们很多人都不理解“场景”应该如何定义。场景来源于英文的 scenario，对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

有了性能需求指标之后，我们需要把这些性能需求指标一一对应到场景中，看它们符合哪个类型。

可能有人看到这里会说：“我觉得全都有了呀。其实不是！在我的性能工程理念中，场景绝对不只有脚本和业务模型这么点内容。我在上一个专栏中已经描述了场景设计和执行，有两个重点：

• 场景分为四类（基准、容量、稳定性、异常）；
• 执行过程中要保持连续递增。

• 性能脚本：性能脚本只是场景中用来施压的部分，它记录了这个场景要做的是哪些事情，是接口级脚本、业务级脚本，还是用户级脚本？
• 参数化数据：这一点我在平时的培训中反复强调过多次，但是，仍然有很多人认为用少量的参数循环跑场景是合理的。这样的想法绝对是错的！因为如果严重的话，会直接导致结果不可用。
• 监控策略：请注意，在一开始的场景执行中，不要过度上监控工具，最好是先上全局监控工具。等有了问题之后，我们再重复执行场景，上定向监控工具。
• 执行控制：首先，我们得按“基准 - 容量 - 稳定性 - 异常”的逻辑执行；其次，在执行过程中要查看实时的数据曲线，并判断是停下来，还是继续，以及要分析哪些内容，以便我们清楚下一步要干什么事情。
• 场景调整：在这一步中我们需要明确很多东西，比如压力线程到底应该从多少开始，最大是多少；递增策略到底配置成什么样；要不要递减策略；持续时间是多长等等。
• 软硬件环境：在场景执行时我们脑子里要有概念，就是在这样的场景设计之下，软硬件的表现应该是什么样子，CPU、IO、内存、网络应该用多少，线程池是否合理等等，这些都要有经验上的判断和比对。
• 基础数据 / 铺底数据：不同的场景目标，对基础数据 / 铺底数据的要求是不一样的。而我们在性能场景中要求的基础数据 / 铺底数据就是和生产一致。
• 挡板 /Mock/ 第三方：在场景中，对不可控的第三方一定要管控好，因为第三方的快慢会直接影响结果。这一步我们要根据场景的目标来。如果要测试的是真实生产逻辑，那就应该加上这一步；如果要测试的是，自己的系统有没有性能问题，那就可以屏蔽掉。但是在结果报告中，我们需要写明这个风险。

五、IO响应时间

iostat -d -x -k 1 10

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sda 1.56 28.31 7.80 31.49 42.51 2.92 21.26 1.46 1.16 0.03 0.79 2.62 10.28

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sda 2.00 20.00 381.00 7.00 12320.00 216.00 6160.00 108.00 32.31 1.75 4.50 2.17 84.20

rrqm/s：每秒这个设备相关的读取请求有多少被Merge了(当系统调用需要读取数据的 时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge)；wrqm/s：每秒这个 设备相关的写入请求有多少被Merge了。

rsec/s：每秒读取的扇区数；wsec/： 每秒写入的扇区数。

r/s：The number of read requests that were issued to the device per second；w/s：The number of write requests that were issued to the device per second；

await：每一个IO请求的处理的平均时间(单位是微秒)。这里可以理解为IO的响应时 间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。

六、是否性能调优

新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底。

旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。

新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到最好。

 七、TPS

        TPS（Transactions Per Second）。我们都知道 TPS 是性能领域中一个关键的性能指标概念，它用来描述每秒事务数。我们也知道 TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。

        经常有人问，TPS 应该如何定义？

        这个实在是没有具体的“法律规定”，那就意味着，你想怎么定就怎么定。通常情况下，我们会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试，T 可以直接定义为接口级；如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务流。

        我们用一个示意图来说明一下。

        如果我们要单独测试接口 1、2、3，那 T 就是接口级的；如果我们要从用户的角度来下一个订单，那 1、2、3 应该在一个 T 中，这就是业务级的了。

 如果要有公式的话，这个计算公式将非常简单：TPS=1000ms/响应时间(单位ms)∗压力机线程数

  

八、并发度的分析

在很多业务中，并发度都会低于 5%，甚至低于 1%。拿 5% 来计算，就是 10000 用户 x5%=500(TPS)，注意哦，这里是 TPS，而不是并发线程数。如果这时响应时间是 100ms。

那显然并发线程数是： 500TPS/(1000ms/100ms)=50(并发线程)。

通过这样简单的计算逻辑，我们就可以看出来用户数、线程数和 TPS 之间的关系了。

但是！响应时间肯定不会一直都是 100ms 的嘛。所以通常情况下，上面的这个比例都不会固定，而是随着并发线程数的增加，会出现趋势上的关系。

所以，在性能分析中，我一直在强调着一个词：趋势！

 九、响应时间

响应时间的 258 原则合理吗？

对于响应时间，有很多人还在说着 258 或 2510 响应时间是业内的通用标准。

然后我问他们这个标准的出处在哪里？谁写的？背景是什么？几乎没有人知道。真是不能想像，一个谁都不知道出处的原则居然会有那么大的传播范围，就像谣言一样，出来之后，再也找不到源头。

其实这是在 80 年代的时候，英国一家 IT 媒体对音乐缓冲服务做的一次调查。在那个年代，得到的结果是，2 秒客户满意度不错；5 秒满意度就下降了，但还有利润；8 秒时，就没有利润了。于是他们就把这个统计数据公布了出来，这样就出现了 258 principle，翻译成中文之后，它就像一个万年不变的定理，深深影响着很多人。

这个统计结果的出现，已经过去快 40 年了，IT 发展的都能上天了，这个时间现在已经完全不适用了。所以，以后出去别再提 258/2510 响应时间原则这样的话了，太不专业。

那么响应时间如何设计比较合理呢？这里有两种思路推荐给你。

• 同行业的对比数据。
• 找到使用系统的样本用户（越多越好），对他们做统计，将结果拿出来，就是最有效的响应时间的制定标准。

十、异常场景的性能需求指标

针对该场景，你只需记住这个流程即可：针对系统的架构，先分析异常场景中的需求点，再设计相应的案例来覆盖。为什么要分析系统架构呢？因为在一个应用中，我们把功能测试完一遍之后，异常问题通常有两大类：其一是架构级的异常；其二是容量引起的性能异常。而对于架构级的异常，我们只能站在架构的角度进行分析

十一、业务指标和性能指标之间的关系

这个示意显然不够详细，但也能说明关系了。所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。这样一来，技术指标就不会是一块飞地。同时，在回答了技术指标是否满足的同时，也能回答是否可以满足业务指标。 

 十二、并发

绝对并发指的是同一时刻的并发数；相对并发指的是一个时间段内发生的事情。

我们假设上图中的这些小人是严格按照这个逻辑到达系统的，那显然，系统的绝对并发用户数是 4。如果描述 1 秒内的并发用户数，那就是 16。是不是显而易见？

但是，在实际的系统中，用户通常是这样分配的：

我们只要描述并发就好了，不用有“相对”和“绝对”的概念，这样可以简化沟通，也不会出错。

那么如何来描述上面的并发用户数呢？

在这里我建议用 TPS 来承载“并发”这个概念。

并发数是 16TPS，就是 1 秒内整个系统处理了 16 个事务。这样描述就够了，别纠结。在线用户数、并发

 十三、用户数怎么计算

如上图所示，总共有 32 个用户进入了系统，但是绿色的用户并没有任何动作，那么显然，在线用户数是 32 个，并发用户数是 16 个，这时的并发度就是 50%。

但在一个系统中，通常都是下面这个样子的。

 为了能 hold 住更多的用户，我们通常都会把一些数据放到 Redis 这样的缓存服务器中。所以在线用户数怎么算呢，如果仅从上面这种简单的图来看的话，其实就是缓存服务器能有多大，能 hold 住多少用户需要的数据。

最多再加上在超时路上的用户数。如下所示：

所以我们要是想知道在线的最大的用户数是多少，对于一个设计逻辑清晰的系统来说，不用测试就可以知道，直接拿缓存的内存来算就可以了。

假设一个用户进入系统之后，需要用 10k 内存来维护一个用户的信息，那么 10G 的内存就能 hold 住 1,048,576 个用户的数据，这就是最大在线用户数了。

在实际的项目中，我们还会将超时放在一起来考虑。但并发用户数不同，他们需要在系统中执行某个动作。我们要测试的重中之重，就是统计这些正在执行动作的并发用户数。

当我们统计生产环境中的在线用户数时，并发用户数也是要同时统计的。这里会涉及到一个概念：并发度。

要想计算并发用户和在线用户数之间的关系，都需要有并发度。做性能的人都知道，我们有时会接到一个需求，那就是一定要测试出来系统最大在线用户数是多少。这个需求怎么做呢？

很多人都是通过加思考时间（有的压力工具中叫等待时间，Sleep 时间）来保持用户与系统之间的 session 不断，但实际上的并发度非常非常低。我曾经看到一个小伙，在一台 4C8G 的笔记本上用 LoadRunner 跑了 1 万个用户，里面的 error 疯狂上涨，当然正常的事务也有。

我问他，你这个场景有什么意义，这么多错？他说，老板要一个最大在线用户数。我说你这些都错了呀。他说，没事，我要的是 Running User 能达到最大就行，给老板交差。我只能默默地离开了。

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

我们通过一个示意图来说明：

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

• 如果有 10000 个在线用户数，同时并发度是 1%，那显然并发用户数就是 100。
• 如果每个线程的 20TPS，显然只需要 5 个线程就够了（请注意，这里说的线程指的是压力机的线程数）。

• 这时对 Server 来说，它处理的就是 100TPS，平均响应时间是 50ms。50ms 就是根据 1000ms/20TPS 得来的（请注意，这里说的平均响应时间会在一个区间内浮动，但只要 TPS 不变，这个平均响应时间就不会变）。
• 如果我们有两个 Server 线程来处理，那么一个线程就是 50TPS，这个很直接吧。

• 请大家注意，这里我有一个转换的细节，那就是并发用户数到压力机的并发线程数。这一步，我们通常怎么做呢？就是基准测试的第一步。关于这一点，我们在后续的场景中交待。

而我们通常说的“并发”这个词，依赖 TPS 来承载的时候，指的都是 Server 端的处理能力，并不是压力工具上的并发线程数。

在上面的例子中，我们说的并发就是指服务器上 100TPS 的处理能力，而不是指 5 个压力机的并发线程数。

请你切记这一点，以免沟通障碍。在我带过的所有项目中，这都是一个沟通的前提。

所以，我一直在强调一点，这是一个基础的知识：不要在意你用的是什么压力工具，只要在意你服务端的处理能力就可以了。

十四、线程数递增方法

那么，对于场景中线程（有些工具中叫虚拟用户）递增的策略，我们要做到以下几点：

• 场景中的线程递增一定是连续的，并且在递增的过程中也是有梯度的。
• 场景中的线程递增一定要和 TPS 的递增有比例关系，而不是突然达到最上限。
• 后面在场景的篇幅中我们会再说它们之间的比例关系。上面两点针对的是常规的性能场景。对于秒杀类的场景，我们前期一定是做好了系统预热的工作的，在预热之后，线程突增产生的压力，也是在可处理范围的。这时，我们可以设计线程突增的场景来看系统瞬间的处理能力。如果不能模拟出秒杀的陡增，就是不合理的场景。

这里给出我做性能场景递增的经验值：

当然这里也不会是放在哪个系统中都适合的递增幅度，你还是要根据实际的测试过程来做相应的判断。

有了这些判断之后，相信大家都能做出合理的场景来了。

 十五、性能衰减的过程

有了瓶颈的判断能力，也有了线程递增的意识，那么下面在场景执行中，我们就要有判断性能衰减的能力了吧。来，我们先看一个压力过程中产生的结果图。

在递增的压力过程中，随着用户数的增加。我们可以做几次计算。

第一次计算，在线程达到 24 时，TPS 为 1810.6，也就是每线程每秒发出 75.44 个请求。

第二次计算，在线程达到 72 时，TPS 为 4375.1，也就是每线程每秒发出 60.77 个请求。

第三次计算，在线程达到 137 时，TPS 为 5034，也就是每线程每秒发出 36.74 个请求。

通过这三次计算，我们是不是可以看到，每线程每秒发出的请求数在变少，但是整体 TPS 是在增加的。我们有很多做性能测试的人，基本上，只看 TPS 和响应时间的时候，在上面这个示例中，肯定会一直往上加用户。

虽然响应时间在增加，但是增加得也不多嘛。但实际上，通过我们的计算可以知道，性能是在不断地衰减的。我们来看一张统计图：

通过红线的大致比对可以知道，当每线程每秒的请求数降到 55 左右的时候，TPS 就达到上限了，大概在 5000 左右，再接着往上增加线程已经没有用了，响应时间开始往上增加了。这就是性能衰减的过程（题外话，在上图中，其实还有一个问题，就是在红线前面，性能在上升的过程中有几次抖动，这个抖动到后面变大了，也变频繁了，如果这是必然出现的抖动，那也是配置问题，希望你注意到这一点）。

为什么要这么细致地描述性能衰减的过程呢？其实我就是想告诉你，只要每线程每秒的 TPS 开始变少，就意味着性能瓶颈已经出现了。但是瓶颈出现之后，并不是说服务器的处理能力（这里我们用 TPS 来描述）会下降，应该说 TPS 仍然会上升，在性能不断衰减的过程中，TPS 就会达到上限。

这也是前面我说的，性能瓶颈其实在最大 TPS 之前早就已经出现了。那么我们是不是应该在性能衰减到最大 TPS 时就停止场景呢？这个不一定的哦。因为停不停场景，取决于我们的场景目标，如果我们只是为了得到最大 TPS，那确实可以停止场景了。

但是，如果我们要扩大化性能瓶颈，也就是说为了让瓶颈更为明显，就完全不需要停止场景，只要不报错，就接着往上压，一直压到我们要说的下一个话题——响应时间变长，需要拆分。

十六、性能方案

十七、容量场景

有了基准场景的结果之后，我们就进入了容量场景的阶段。在容量场景中，我们还是要继续秉承“连续、递增”的执行思路，最重要的是，要实现我们前面提到的业务模型，来真实模拟线上的业务场景。

那应该如何控制这个比例关系呢？如果你是用 JMeter 的话，可以使用 Throughput Controller 来控制业务比例，如下所示：

总之，在场景执行结束之后，我们要把业务比例做统计，并且要和业务比例对比，当比例一致时，才算是合理的场景。

容量场景的最大 TPS 是指最大的稳定 TPS。

那么你看，上面这张图已经抖动了，已经不稳定了，我们再去找它的最大 TPS 还有什么意义呢？你敢让一个生产系统运行在这样抖动的状态中吗？所以，对于上图中这样的 TPS 曲线，我会把最大的稳定 TPS 定为第三个阶梯，也就是在 600 左右，而不会定在 700。 

十八、稳定性场景

（一）稳定性场景的时长

在运维周期内，有 1 亿笔业务容量。根据上面容量场景中的测试结果，假设最大稳定 TPS 是 500，那稳定性场景的执行时长就是：

（二）用多大的 TPS 来执行

在执行稳定性场景时，完全可以用最大的稳定 TPS 来运行，只要覆盖了运维周期之内的业务容量即可

十九、参数化数据

参数化数据量应该是多少，取决于场景运行多长时间。

而在场景运行中，我们通常要用到两类数据：唯一性数据和可重复使用的数据。

对于唯一性数据（比如用户数据）来说，我们需要使用多少参数化数据是非常容易计算的。比如一个运行半小时的场景，TPS 如果是 100 的话，那就需要 18 万的数据量，计算过程如下：

数据量 = 30min×60s×100TPS=18w

对于可重复使用的数据量

我们需要分析真实业务场景中是如何重复的，比如说电商系统中商品的数据量，我们在做参数化的时候就可以重复，毕竟多个人是可以同时购买同一个商品的。

我们假设平均有 1000 个用户在 10 个商品中，那当我们有 18 万个用户时，就需要 1800 个商品：商品数量 = 18w用户÷1000用户×10商品=1800商品