性能测试常用名词解释

并发

1.同一请求在同一时间段发起多次。

2.不同请求在同一时间发起多次。

实际场景：

1. 同一用户短时间内不断执行多次同一操作，如提交表单。这时我们可以对统一会话增加幂等、防抖等方式做限制。

2. 不同用户在短时间内不断执行多次同一操作，如抢火车票。这时我们需要在服务层面做一些分流、限流、队列等方式降低服务的压力激增。

线程数

以jmeter为例，线程组中的线程数就相当于并发的用户数量。这个数值依赖于压测机本身的cpu线程数，比如我有一台8核16线程的设备，那么他最多能同时并发16个请求（实际情况要比这个小，系统本身还需要占用一些线程数），及时你填写的数量大于16，也不可能超过这个数值。

事务

一个事务可以包含多个请求，我们可以以事务的维度看查看一个完整的业务场景的性能指标，例如访问单一页面初始化需要的多个请求，那么将这些这个事务聚合成一个事务，我们就可以统计出当前页面整体的加载时长（当然这里还需要考虑前端的渲染时间）。jmeter 提供了 事务控制器（Generate parent sample）​​来帮我们实现这一测试场景。

性能指标

response time

响应时间

• 包括一个请求从发出到接收到反馈之前的时间差。

• response time = 发起请求网络传输时间 + 服务器处理时间 + 数据库系统处理时间 + 返回响应网络传输时间

• response time + 前端页面渲染时间就是用户侧的感知的”响应时间“。

TPS

Transactions per second ，每秒执行事务数

• jmeter实际每秒发出的请求数量，可以是一个请求也可以是多个请求。

QPS

Queries per second，每秒请求数量

• 服务端实际每秒接收的请求数量 。

• 有的时候也可以翻译成：每秒查询率，即在数据库中每秒执行 SQL 数量

• PS: 一个请求可能会执行多条 SQL

Throughput

吞吐量

• 吞吐量是指系统在单位时间内处理请求的数量。

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

成功率

• 请求成功的次数占总请求数的比例。

• 如果 QPS 和响应时间都满足性能要求时，请求成功率只有 50%，用户也是不会接受的。

资源利用率

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

性能拐点

• 一般服务都有性能临界点。当超过临界点时，吞吐量非线性下降，响应时间指数级增加，成功率降低。

• 找到出现性能拐点的主要原因：基于性能拐点主要原因设置高危性能报警线。此为高风险注意事项，因为一旦达到性能拐点，有可能会出现雪崩现象，造成极其严重的事故。

• 观察超过性能拐点后，系统是否会出现假死、崩溃等高风险事件。