一、性能测试的概念&意义

1、概念

通过技术的手段模拟大量用户同时访问被测应用，观察、记录和分析系统的各项性能指标的过程。

2、目的

评估系统的性能瓶颈，预测系统的最大用户负载能力

3、意义

能够有效评估系统的性能指标，用于系统的性能评估 2）能够识别系统的性能瓶颈，协助性能调优 3）能够指导突发流量承载方案的制定 4）能够用于系统运维成本的预算

二、性能指标理解

1、指标分析

（1）响应时间

用户通过客户端向服务端发出请求的时间为：T1

服务端接收到请求，处理该请求的时间为：T2

服务端返回数据给客户端时间为：T3

客户端接收到响应数据，处理数据呈现给用户时间为：T4

（2）响应时间系统视角

系统的响应时间 Ts= T1+T2+T3

该时间没有包括客户端对数据处理并呈现的时间 T4

（3）响应时间用户视角

用户眼中的的响应时间 Tu = T1+T2+T3+T4

用户通过客户端发出请求到客户端展现请求结果，这个时间越短越好

（4）响应时间服务器视角

服务器接收到客户端发送的请求，并给出响应，这个过程所消耗的时间为响应时间，即服务器仅关注 T2

从不同的视角下，衡量响应时间的指标也各不相同。在实际测试过程中，要明确以什么视角验证被测对象的性能。

2、并发

（1）并发用户数

简称 VU ,指的是系统中操作业务的用户。一般称为虚拟用户数。并发用户数跟注册用户数，在线用户数有很大差别。并发用户数一定会对服务器产生压力，而在线用户数只是挂在系统上，对服务器不产生压力

（2）在线用户数

在已有系统中选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数

（3）注册用户数

数据库中存在的用户数。并发用户数可以取系统用户数的 10%，例如在半个小时内，使用系统的用户数为 10 万，那么取 10%(即 1 万) 作为并发用户数

（4）系统并发数

一般指测试工具为了模拟出用户并发压力而启动的线程，比如 jmeter 里面的 Thread。由于 jmeter 中的线程有迭代的概念，所以通过线程迭代数就可以模拟出用户单位时间最大的并发数。

注意不要把系统并发数和并发用户数* 的概念混在一起

3、吞吐量

单位时间内系统处理请求的数量。吞吐量直接体现了软件系统的业务处理能力

（1）衡量方式

Rps 请求数/单位时间

Hps 点击数/单位时间

Tps 通过事物数/单位时间

Qps 查询数/单位时间

（2）TPS 模型

随着压力不断增长，实测系统的资源会不断被消耗，TPS 值会因为这些因素而发生变化，并且符合一定的规律

4、基准测试

原点到 a 之间的系统性能，指以系统预期性能指标为前提，对系统不断增加压力，以验证系统能否达到预期性能

5、负载测试

a 到 b 的系统性能，是指对系统不断地增加压力或一定压力下的持续运行，直到系统的某项或多项性能指标达到极限，例如某种资源已经达到饱和状态等

6、压力测试

b 到 d 之间的系统性能，是指超过安全负载的情况下，对系统不断施加压力，直到系统崩溃，找出系统的瓶颈点和崩溃点。

Tps（每秒处理事务数）

一个事务是指客户端向服务器发送请求然后服务器做出反应的过程

单请求事物：事物由单个接口请求构成。如一次登录，一次查询

多请求事物：事物由多个接口请求构成。如登录 - 查询 - 新增 - 退出。这四步操作构成一个完整的事物

TPS 的决定性因素：事务是要靠虚拟用户完成

1 个用户在 1 秒内完成 1 笔事务，那么 TPS 就是 1

1 个事物响应时间是 1ms,那么 1 个用户在 1 秒内能完成 1000 笔事务。TPS 就是 1000

1 笔业务响应时间是 1s,那么 1 个用户在 1 秒内只能完成 1 笔事务。想达到 1000TPS 就至少需要 1000 个用户

因此可以说 1 个用户能产生 1000TPS， 1000 个用户也可以产生 1000TPS，由响应时间决定

5、Rps 每秒发起的请求数

并发数=rps* 平均响应时间

RPS 用来描述施压引擎实际发出的压力大小

RPS 模式主要是为了站在服务端视角去直接衡量系统的吞吐能力-TPS 而设计的

并发过低时可能达不到预期的 RPS，并发过高时可能压力过大直接压垮服务器

按照被压测端需要达到的 TPS 去设置相应的 RPS，应用场景主要是一些动态的接口 API，比如登陆、提交订单

7、吞吐量行业标准

金融行业：1000TPS~50000TPS，不包括互联网化的活动

保险行业：100TPS~100000TPS，不包括互联网化的活动

制造行业：10TPS~5000TPS

互联网电子商务：10000TPS~1000000TPS

互联网中型网站：1000TPS~50000TPS

互联网小型网站: 500TPS~10000TPS

提问：我有一个功能，需要测试一下最大支持多少用户并发？

此时要计算的是最大用户并发数，强调的是同时操作，也可以理解为同时发起请求，我们可以通过 RPS 定时器或者阶梯加压线程组测试每秒最大的请求数

三、吞吐量模式下的阶梯负载

RPS模式负载：RPS是request persecond，也就是每秒的请求数。我们通过持续不断地增加请求来对服务端施压，测试服务端的处理能力，找到瓶颈。

策略

第一次：并发 200，不限迭代次数，同时在请求下面加 RPS 定时器。目的是在 200 线程下，将 RPS 逐步增加到 1000/S,并持续运行一段时间

start=1 end=200，持续时间是 10。表示我们需要在 10s 内将 RPS（每秒请求数）均匀的从 1 提升到 200。

拐点判断方式

通过 Tps走势图观察拐点。吞吐量会随压力的增大呈抛物线状，抛物线的最高点处，即为当前测试环境下该请求的最大处理能力。吞吐量的拐点往往也就是响应时间的拐点。
通过资源消耗判断拐点。比如测试中 Tps 仍呈上升趋势，但 CPU 资源使用率已高达 90%，就以此时 Tps 值为当前测试环境下该请求的最大处理能力。

注意：rps 是客户端每秒发起的请求，tps 是服务端每秒完成的请求。实际情况中，tps 往往和 rps 不等，因为要考虑到中间的网络和服务处理时间

启动 jmeter，运行一段时间之后我们观察一下监听器的数据图表Tps监听

RPS 在 836/s 的时候开始出现拐点，请求曲线的角度开始收窄

TPS 在 730/s 左右开始出现剧波动，可以认为这是吞吐量的一个拐点

在 1:00 秒的时候，也就是 TPS 达到 730/S 的时候，事物开始出现错误

1：此处可能就是一个性能瓶颈
2：有可能是百度对 ip 的访问量做了限流，防止爬虫
3：有可能是我当前环境的问题，包括带宽，内存，cpu 等等资源的限制，后期都需要考虑进去

在性能稳定的情况下，可以套用公式去计算出最大并发数:并发数 = RPS * 响应时间
1：稳定状态下，最大 RPS= 836/S。这个值可以理解为最大支持 1 秒内 836个用户同时去访问。
2：稳定情况下，响应时间大约长期保持在 160 ms
3：稳定情况下，峰值系统并发数大约是 836*0.16=134。这个值可以理解为只要启动 134个线程就可以在一秒内满足 836/s 的压力值。或者换个角度，也可以表示最大支持 134个用户在 1s 内不停的访问，一直达到瓶颈点

第二次：100 并发
这一次我们把线程数收紧，只给 100 线程。以此观察线程数降低的情况下，压力会不会变小观察到，请求数依然在 820-830 这个区间变缓