性能测试基础

一、常用术语

1.1 响应时间

合理的响应时间取决于实际用户需求()

1.2 并发用户数

并发的定义
- 狭义上的并发：所有用户在同一时间点进行同样的操作，一般指同一类型的业务场景，比如1000个用户同时登陆系统；
- 广义上的并发：多个用户与系统发生了交互，这些业务场景可以是相同的也可以是不同的，交叉请求和处理较多；
用于估算并发用户数的公式（仅供参考）
- 平均用户并发数：C=n×L÷T
- 峰值并发用户数：
  - C是平均并发数
  - n是用户从登陆到退出系统的时间段
  - L是系统使用时间段的平均值
  - T是使用系统的时间段数值
  - C›指并发用户数的峰值
对于企业内部使用的web系统，还有精度更小的一种公式
- 平均用户并发数：C=n÷10
- 峰值用户并发数：C›≈r×C
  - r值一般取2—3.这种方法要求不太严格，只有很少数据支持分析的性能测试中使用

1.3 负载

定义: 指系统所承受的工作量或任务量。它可以是并发用户数、并发请求数量等

1.4 吞吐量

定义：单位时间内系统处理客户请求的数量（一般来说，请求数/每秒OR页面数/每秒来衡量）
- 从业务角度来说，访问人数/天OR处理的业务数/小时来衡量（PV、UV）
- 从网络角度来说，字节数/天来考察网络流量
- 对于交互式应用，吞吐量指标反映服务器承受的压力，在容量规划测试中，吞吐量是个很重要的指标，因为它能说明系统级别的负载能力

1.4.1 常见问题

吞吐量和负载之间的关系：
- 上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比；
- 平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动；
- 下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比；

a1面积越大，说明系统的性能能力越强，a2面积越大，说明系统稳定性越好，a3面积越大，说明系统的容错能力越好

总结：在相同的负载下，系统的吞吐量越高，表示系统处理请求数量的能力越强

TPS和QPS之间的关系
- TPS: 是一个广泛用于事务性系统（如金融交易系统、支付系统等）的指标，用于衡量系统在每秒钟内能够处理的事务数量。
  - 一个事务可以包含多个数据库查询或其他操作步骤，因此 TPS 不仅涵盖了数据库查询，还包括了更复杂的操作流程。
  - 例如，一笔银行转账可以包含多个数据库读写操作和交易验证，这个整体的事务在 TPS 计算中被计算为一个单独的事务
- QPS: 是一个用于数据库、网络服务、API 等非事务性系统的指标，用于衡量系统在每秒钟内能够处理的查询请求数量
  - 通常用于描述数据库查询频率或网络服务的请求频率
  - 例如，一个 Web 服务器处理的 HTTP 请求数量可以用 QPS 来衡量

总结：看到很多博客或性能测试人员将QPS和TPS混为一谈，个人认为，他们是以测试结果的统计得到该结论的；QPS是查询，而TPS是事务，事务是查询的入口，也包含其他类型的业务场景，因此QPS应该是TPS的子集！

1.4.2 计算公式

Web系统的性能测试中，吞吐量指标可以在两个方面发挥作用
- 协助设计性能测试场景，以及衡量性能测试场景是否达到预期的设计目标
- 协助分析性能瓶颈
- 没有遇到瓶颈之前，吞吐量和并发用户之间存在的关系可以用下面的公式表达：
- F=N（vu）×R÷T
  - F表示吞吐量
  - N(vu) 表示并发用户数
  - R表示每个VU发送的请求（点击）数量即请求数
  - T表示性能测试所用的时间
- 不同并发用户数量情况下，对同一系统施加相同的吞吐量，很可能得到不同结果
PS：大部分性能测试中，单击数（Hits）指客户端发出的HTTP的请求数量，而不是指用户在页面上的一次单击事件。
- 场景示例：一次单击事件请求页面A，页面A包含3张图片和一个框架（Frame），则这次单击共产生了5个Hits（包括对页面A本身的请求）

1.5 性能计数器（Counter)

定义：描述服务器或者操作系统性能的一些数据指标
作用：监控、分析系统可扩展性，进行性能瓶颈的定位时，计数器取值非常关键
相关指标：资源利用率：系统各种资源的使用情况
- CPU 使用率：监测 CPU 的负载情况，包括总体使用率、每个核心的使用率等。
  - CPU 使用率过高：
  - 场景示例：应用程序响应变慢，用户反馈系统性能不佳。
  - 解决方案：使用 CPU 使用率计数器监测 CPU 的负载情况，查看是否存在持续高负载。如果是，可能需要优化代码、减少并发操作或考虑升级硬件。
- 内存使用率：跟踪系统内存的使用情况，包括可用内存、已用内存、缓存和交换空间等。
  - 内存不足：
  - 场景示例：系统运行缓慢，应用程序频繁出现崩溃或无响应。
  - 解决方案：使用内存使用率计数器监测系统内存的使用情况。如果内存占用过高，可能需要检查是否存在内存泄漏或者考虑增加可用内存。
- 磁盘 I/O：记录磁盘读取和写入的速度，以及磁盘队列的长度等。
  - 磁盘 I/O 瓶颈：
  - 场景示例：应用程序读写操作较慢，数据库响应时间延迟。
  - 解决方案：使用磁盘 I/O 计数器监测磁盘读写速度和队列长度。如果队列长度持续增长，可能存在磁盘瓶颈，需要优化数据库查询、增加磁盘吞吐量或使用缓存等方法。
- 网络带宽：监测网络流量、带宽使用率和传输速度。
  - 网络带宽问题：
  - 场景示例：网络传输速度慢，影响应用程序性能。
  - 解决方案：使用网络带宽计数器监测网络流量和传输速度。如果带宽使用率高，可能需要优化网络连接、使用压缩技术或增加带宽。
- 进程计数器：跟踪各个进程的资源使用情况，如CPU时间、内存占用等。
  - 进程资源占用：
  - 场景示例：某个进程占用过多 CPU 或内存，导致系统性能下降。
  - 解决方案：使用进程计数器监测各个进程的资源使用情况。定位高资源消耗的进程，分析其行为，可能需要进行优化或隔离。
- 线程计数器：跟踪线程的运行状况和资源消耗。
  - 线程问题：
  - 场景示例：应用程序出现线程阻塞或死锁，导致无响应。
  - 解决方案：使用线程计数器监测各个线程的运行状态和资源消耗。检查是否存在线程阻塞或死锁情况，进行相应的线程优化和调整。
- 硬盘空间：监控硬盘分区的可用空间。
  - 硬盘空间告警：
  - 场景示例：硬盘空间逐渐耗尽，可能影响系统运行。
  - 解决方案：使用硬盘空间计数器监测硬盘分区的可用空间。及时进行硬盘清理或扩容，避免硬盘空间耗尽。

1.6 思考时间（Think Time）

思考时间：用户操作时间每个请求的间隔时间
体现在脚本中，就是操作之间放一个Think函数，使脚本在执行两个操作之间等待一段时间

公式F=N（vu）×R÷T
- F 表示吞吐量
- N(vu) 表示并发用户数
- R表示每个VU发送的请求（点击）数量即请求数
- T表示性能测试所用的时间
计算思考时间的方法示例：
- 计算并发用户数：确定在性能测试中要模拟的并发用户数。
- 统计平均吞吐量：监测性能测试期间系统的平均吞吐量。
- 统计平均每用户发出的请求数量：计算每个用户在单位时间内发出的请求数量。
- 计算请求时间：使用公式 R=T÷Ts 计算请求时间，其中 Ts 为您期望的思考时间。
- 计算思考时间：将计算得出的请求时间作为思考时间。您可以根据实际情况，可能需要添加一个最小的固定思考时间，以确保模拟用户操作之间有适当的等待时间。
最终，将计算得出的思考时间用于脚本中，通过在操作之间插入 Think 函数，模拟用户操作之间的等待时间。

场景示例：比如用户注册的时候，在打开注册页面到提交注册页面之间，是有一段思考时间的（用户在填写个人信息）

二、测试策略

性能测试实施过程中，针对不同的业务场景，我们经过分析和场景建模后，会选择不同的测试策略。下面的测试策略，覆盖了绝大多数的场景

2.1 常见方式

并发测试
- 模拟客户端请求，在单位时间内(S)同时发起一定量的请求，验证系统是否具有并发性的问题。
负载测试
- 不断增加请求压力，直到服务器某个资源项达到饱和（比如CPU使用率达到90%+）或某个指标达到安全临界值（比如运维的监控告警阈值or拐点），验证系统在既有测试环境不同的请求压力下能否正常运行。示例如下：
容量测试
- 采用负载测试策略，验证在现有测试环境下被测系统的最大性能表现（可接受的最大性能表现，不一定是最优性能表现）
极限测试
- 在既有测试环境下，不考虑资源占用率的极限情况（CPU使用率达到95%以上或IO异常繁忙或Load值较高），在系统不宕机的情况下的最大处理能力。
配置测试
- 不断调整系统各方面的配置（软硬件、参数配置等），验证在性能达到最优时（最优的性能一定是权衡各方面因素找到的平衡点）的最佳配置。
浪涌测试
- 验证系统在某段时间内并发突增或请求量波动较大的情况下，系统能否正常稳定的提供服务。
- 这种测试策略使用的也相对较少，主要针对不确定性的短期的峰值流量涌入场景（比如某微博的离婚、恋爱、分手话题）。
稳定性测试
- 以恒定的并发数（根据负载测试的结果，CPU使用率在70%时对应的并发数），验证系统在混合场景下的性能表现
批处理测试
- 验证待测系统在既有环境下，系统的批处理（一般都是一个crontab或者触发式的job）业务能力能否满足生产的业务需求指标
高可用测试
- 在集群多节点或分布式的情况下，破坏其中一个或多个集群节点，验证系统能否及时恢复服务能力。
容错恢复测试
- 验证系统能否在出现故障的情况下仍能保持正常提供服务的能力或出现故障后的自我恢复能力

2.2 适用场景

三、性能监控以及工具部署

工具准备
- Jmeter
  - 性能压测工具
  - 插件：
    - org.apache.jmeter.visualizers.backend.influxdb.HttpMetricsSender后端监听器
    - jp@gc - Stepping Thread Group线程组
    - 吞吐量控制器
    - 同步定时器
    - if 控制器
    - ......
- InfluxDB
  - 开源时序型数据库，按时间标签的方式存放各种性能测试指标
- Grafana
  - 开源可视化监控工具，生成各种漂亮的性能指标图，方便插入性能测试报告中
- telegraf
  - 服务器性能代理程序，收集性能服务器的各种系统资源指标
前提条件：前面所述工具已经部署完成,分布式压测环境搭建完成

3.1 Jmeter

为了在分布式压测阶段避免频繁打开jmter的.jmx文件修改线程数，并及时调整施压机的.jmx文件线程数。经过尝试可以使用下述方式：
```
jmeter -n -t yxd_postorder.jmx -JthreadNum=100 -JloopNum=1 -JrampupTime=10 -JsynchronizeNum=100
```
指定远程Slave机压测
- JthreadNum 线程数
- JloopNum 循环次数
- JrampupTime 循环时间
- JsynchronizeNum 同步定时器线程数
- 192.168.1.143 远程Slave机ip
```
jmeter -r -n -t yxd_postorder.jmx -G synchronizeNum=100 -G threadNum=100 -G loopNum=1 -G rampupTime=10 -R 192.168.1.143
```