常用名词
并发
1.同一请求在同一时间段发起多次。
2.不同请求在同一时间发起多次。
实际场景：
同一用户短时间内不断执行多次同一操作，如提交表单。这时我们可以对统一会话增加幂等、防抖等方式做限制。
不同用户在短时间内不断执行多次同一操作，如抢火车票。这时我们需要在服务层面做一些分流、限流、队列等方式降低服务的压力激增。
线程数
以jmeter为例，线程组中的线程数就相当于并发的用户数量。这个数值依赖于压测机本身的cpu线程数，比如我有一台8核16线程的设备，那么他最多能同时并发16个请求（实际情况要比这个小，系统本身还需要占用一些线程数），及时你填写的数量大于16，也不可能超过这个数值。
事务
一个事务可以包含多个请求，我们可以以事务的维度看查看一个完整的业务场景的性能指标，例如访问单一页面初始化需要的多个请求，那么将这些这个事务聚合成一个事务，我们就可以统计出当前页面整体的加载时长（当然这里还需要考虑前端的渲染时间）。jmeter 提供了事务控制器（Generate parent sample）来帮我们实现这一测试场景。
性能拐点
一般服务都有性能临界点。当超过临界点时，吞吐量非线性下降，响应时间指数级增加，成功率降低。
找到出现性能拐点的主要原因：基于性能拐点主要原因设置高危性能报警线。此为高风险注意事项，因为一旦达到性能拐点，有可能会出现雪崩现象，造成极其严重的事故。
观察超过性能拐点后，系统是否会出现假死、崩溃等高风险事件。
性能指标
response time
响应时间
包括一个请求从发出到接收到反馈之前的时间差。
response time = 发起请求网络传输时间 + 服务器处理时间 + 数据库系统处理时间 + 返回响应网络传输时间
response time + 前端页面渲染时间就是用户侧的感知的”响应时间“。
Average Latency
平均等待时间
相当于response time 除去网络传输过程的时间（服务器处理时间 + 数据库系统处理时间）
TPS
Transactions per second ，每秒执行事务数
jmeter实际每秒发出的请求数量，可以是一个请求也可以是多个请求。
QPS
Queries per second，每秒请求数量
服务端实际每秒接收的请求数量 。
有的时候也可以翻译成：每秒查询率，即在数据库中每秒执行 SQL 数量
PS: 一个请求可能会执行多条 SQL
OPS
operation per second，每秒执行次数
在不同的系统中有不同的含义，在DB中就相当于每秒执行的sql数量。
Throughput
吞吐量
吞吐量是指系统在单位时间内处理请求的数量。
网络没有瓶颈时，吞吐量≈TPS
成功率
请求成功的次数占总请求数的比例。
如果 QPS 和响应时间都满足性能要求时，请求成功率只有 50%，用户也是不会接受的。
资源利用率
服务器资源的使用程度，比如服务器（应用、服务器）的CPU利用率，内存利用率，磁盘利用率，网络带宽利用率
一般不超过80%
