性能测试

一、两种性能指标

业务指标
技术指标

通常我们会从两个层面定义性能场景的需求指标，它们有映射关系，技术指标不能脱离业务指标

二、并发

狭义

指同一个时间点执行相同的操作（如：秒杀）

广义

同一时间点，向服务器发起的请求（可能是不同的请求）
只要向服务器发起请求，那么服务器在这一时间点内都会收到请求（不管是不是同一个请求）

三、并发用户数（重点）

同一时间点，发出请求的用户数，一个用户可以发出多个请求
场景不一定是同一个
和 CPU、响应时间有关系

和并发的关系

假设有 10 个用户数，每个用户同一时间点内发起 2 个请求，那么服务器收到的请求并发数就是 20

性能测试小场景一

不同身份的用户，访问不同的页面或发起不同的请求（广义的并发）
观察 CPU 使用率和响应时间

性能测试小场景二

所有用户，同一个时间点发送同一个请求（狭义的并发）
观察 CPU 使用率和响应时间

3.1 系统用户数

系统累计注册用户数，不一定在线
注册之后也可以一直不在线
因为用户信息是存在数据库的，而数据库数据就是存在磁盘中，所以系统用户数和磁盘空间有关系

3.2 性能测试小场景

写一个脚本添加很多条用户信息插入到数据库
目的：测试系统容量，方便了解系统的最大容量
实际项目中，当系统容量接近最大容量时，系统需要进行容量扩容（加磁盘空间），否则就会爆掉

3.3 在线用户数

在线用户可能是正常发起请求，也可能只是挂机啥操作都没有，不一定同时做某一件事情
在线用户可能是游客（未注册的用户），也可能是系统用户（已注册的用户）
在线用户数≠并发用户数
和内存有关系

性能测试小场景

使用 Jmeter 让不同的用户不断上线，且不下线和发起其他请求，看看内存使用情况
实际场景：12306 以前很多用户在线，响应时间会拉的很长

3.4 线程数

在 jmeter 中，线程数和并发用户数等价【和CPU、响应时间有关系】

四、事务

客户端向服务器发送请求，然后服务器做出响应的过程
登录、注册、下单等功能都属于一个事务
一个事务可能会发起多个请求

4.1 jmeter 相关

jmerter 中，默认一个接口请求，就是一个事务；但也支持多个接口整合成一个事务

4.2 注意点

若一个业务或事务有多个接口，那么多个单接口的性能指标值相加≠ 业务或事务的性能指标值

五、有哪些常见的性能指标值

简写	英文全称	含义
RT	Response Time	响应时间。通常我们说的响应时间，都是包括了Request Time和Response Time
HPS	Hits Per Second	每秒点击数
TPS	Transactions Per Second	每秒事务数
QPS	Queries Per Second	在MySQL中指每秒SQL数
RPS	Requests Per Second	每秒请求数
CPS	Codes Per Second	在HTTP协议中，CPS偶有提及，指的是HTTP返回码每秒
PV	Page View	页面浏览量
UV	Unique Vistor	独立访问者
IP	Internet Protocol	本地是IP地址，子啊性能中一般指独立IP数
Throughput	/	吞吐量
IOPS	Input/Output Operations Per Second	通常描述磁盘

六、响应时间（Respose Time）

6.1 响应时间对于性能测试来说

从发起请求到收到请求响应的时间
包含了：Request Time 和 Response Time
等价于：发起请求网络传输时间 + 服务器处理时间 + 数据库系统处理时间 + 返回响应网络传输时间

6.2 对用户所感知的响应时间包括

用户客户端渲染时间（多了这个）
请求/响应数据网络传输时间
应用服务器处理时间
数据库系统处理时间

6.3 对用户所感知的响应时间包括

用户客户端渲染时间（多了这个）
请求/响应数据网络传输时间
应用服务器处理时间
数据库系统处理时间

6.5 重点

在做性能测试时，要尽可能的降低网络传输时间，这样最终得出的 RT 会无限接近服务器处理时间，所以我们要把网络环境搞好

6.6事务请求响应时间

完成单个事务所用的时间，可能包含了多个请求

6.7 假如用户说应用很慢，要怎么分析？（仅供参考）

单个用户慢？还是多个用户慢？手上只有我们自己的应用慢？还是所有应用都这么慢？
网络问题的话，带宽是用哪家营业商？不同营业商是不是都卡？还是只有用户所在的营业商卡？
.....等等等

6.8 响应时间多少合理？

标准是：2、5、8
2秒：很好
5秒：可以接受
8秒：不能接受

七、TPS（Transaction Per Second，最主要的指标）

服务器每秒处理事务数，衡量服务器处理能力的最主要指标

7.1 知道 T 是如何定义的

在不同的行业、业务中，TPS 定义的颗粒度可能是不同的
所以不管什么情况下，需要做性能测试的业务的相关方都要知道你的 T 是如何定义的

7.2 定义 TPS 的粒度

一般会根据场景的目的来定义 TPS 的粒度
接口层性能测试：T 可以定义为接口级
业务级性能测试：T 可以定义为每个业务步骤和完整的业务流

如果要单独测试接口 1、2、3，那么 T 就是接口级

如果从用户角度下订单，那 1、2、3 都在一个 T 中，就是业务级

结合实际业务设计，库存服务一定是同步，而积分服务可以是异步，所以这个下单业务，可以只看作由 1、2 这两个接口组成，但是 3 接口还是要监控分析的

所以，性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用

7.3 拿上图做个例子

接口级脚本

——事务 start（接口 1）

接口 1 脚本

——事务 end（接口 1）

——事务 start（接口 2）

接口 2 脚本

——事务 end（接口 2）

——事务 start（接口 3）

接口 3 脚本

——事务 end（接口 3）

业务级接口层脚本（就是用接口拼接出一个完整的业务流）

——事务 start（业务 A）

接口 1 脚本 - 接口 2（同步调用）

接口 1 脚本 - 接口 3（异步调用）

——事务 end（业务 A）

用户级脚本

——事务 start（业务 A）

点击 0 - 接口 1 脚本 - 接口 2（同步调用）

点击 0 - 接口 1 脚本 - 接口 3（异步调用）

——事务 end（业务 A）

总结

一般情况下，我们会按从上到下的顺序一一来测试，这样路径清晰地执行，容易定位问题

八、QPS（Queries per Second）

每秒查询率，在数据库中每秒执行 SQL 数量
一个请求可能会执行多条 SQL
某些企业可能会用QPS代替TPS
也是衡量服务端处理能力的一个指标，但不建议使用

九、RPS（Request per Second）

9. 1 简单理解

每秒请求数，用户从客户端发起的请求数

9. 2 深入挖掘

对于请求数来说，也要看是哪个层面的请求，把上面的图做一点点变化来描述请求数

如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2 次库存服务，调用了 1 次积分服务

问：Request 数量如何计算

答：3+2+2+1 = 8？不，应该是 3，因为发出了 3 个 Request，而调用服务会有单独的描述，以便做性能统计

HPS（Hit per Second）

点击率，每秒点击数
有直接理解为用户在界面上的点击次数
一般在性能测试中，都用来描述 HTTP Request，那它代表每秒发送 HTTP 请求的数量，和 RPS 概念完全一样
HPS 越大对 Server 的压力越大

十、CPS/CPM（Calls Per Second/ Calls Per Minutes）

每秒/每分钟调用次数
通常用来描述 Service 层的单位时间内被其他服务调用的次数

例子

上图的订单服务、库存服务、积分服务，各调用了2、2、1次，还是比较好理解的

十一、 TPS、QPS、RPS、HPS、CPS 的总结

有很多维度可以衡量一个系统的性能能力，但是如果把五个指标同时都拿来描述系统性能能力的话，未必太混乱了

11.1 为此我们可以这样做

用 TPS 来统一形容系统的性能能力，其他的都在各层面加上限制条件来描述，比如说：接口调用 1000 Calls/s
在团队中要定义清楚术语的使用场景，还有含义

十二、吞吐量（Throughput）

单位时间内，网络处理的请求数量（事务/s）

网络没有瓶颈时，吞吐量≈TPS

十三、吞吐率

单位时间内，在网络传输的数据量的平均速率（kB/s）

十四、资源利用率

服务器资源的使用程度，比如服务器（应用、服务器）的CPU利用率，内存利用率，磁盘利用率，网络带宽利用率
一般不超过80%

Think Time 思考时间

从业务角度看

它指的是用户进行操作时，每个请求之间的时间间隔
例子：加入购物车后，多久之后会点击下单？浏览一个商品多久会加入购物车

从性能测试角度看

为了模拟用户两次操作之间的时间间隔，才有 Think Time，更加真实的模拟用户的真是操作
它和用户行为有关系，所以应该分析的是用户行为而非用户数