性能测试

性能测试分类

压力测试：通过模拟系统在高负荷、高并发和繁忙环境下的性能表现，以评估系统的响应能力和稳定性。压力测试的核心逻辑：压力测试的逻辑

收集数据 -> 数据分析 -> 创建场景-> 加压过程 → 收集指标 → 指标评定 ->定位瓶颈 → 优化验证

（例：数据库崩溃时需检查）

连接池最大连接数是否过小
SQL是否存在慢查询
是否触发了OOM机制
负载测试：通过模拟系统在不同负载和流量下的性能特征和响应时间，以评估系统的容量、可扩展性和吞吐量。
容量测试：通过模拟预期使用量、数据量和用户量不断增加的情况下，评估系统的容量、稳定性和资源利用率。
稳定性测试：通过长时间、持续的测试，以评估系统在长期运营和使用的情况下的稳定性。

性能测试指标

性能测试关注的指标：响应时间ms，TPS/QPS/RPS，错误率以及资源利用率，资源利用率一般在压测的过程中需要开发人员参与协助一起关注。

TPS：每秒事务数，衡量完整事务的处理能力，一个事务包含多步操作（需全部成功才算1次）
QPS：每秒查询数，衡量查询类请求的处理能力，侧重单次查询操作（如数据库查询、简单接口查询）
RPS：每秒请求数，衡量所有请求的处理能力，最宽泛的指标（无论请求类型、是否包含多步操作）

三者差异

TPS强调业务
- 电商下单业务，包含3个操作：
- 检验库存（调用库存接口）->创建订单（调用订单接口）->扣减余额（调用支付接口）。只有这3步全部执行成功，才算1次下单事务，统计为1TPS。
- 常用于评估系统的业务处理能力（如每秒能处理多少笔订、多少笔转账）
- TPS=1000ms/响应时间（ms）*压力机线程数
QPS强调数据读取

QPS的核心是每次查询操作 ，只要请求成功就统计为1次QPS。QPS更贴近技术视角，常用于评估查询密集型系统的处理能力（如搜索引擎、商品列表页、数据库只读服务）。

QPS不一定等于接口调用次数，若一个接口内部包含3次数据库查询，接口调用1次算1QPS，但数据库层面会产生3次查询操作（此时数据库的QPS是3）。
RPS聚集所有请求

RPS统计的是每秒发送的所有请求数据，无论请求类型、是否包含多步操作、是否成功，只要发送了请求，就会被统计。
- 每秒改善50次下单请求（每个下单包含3步接口调用）--接口层面的RPS就是50*3=150，业务层面的RPS就是50.
- RPS是通用指标，常用于初步评估系统的请求承载量（如压测工具JMeter）
计算：数量/总时间（单位时间内完成的数量）

事务通常是由多个请求或者查询来完成，查询商品的事务（查询商品分类请求，查询商品数量请求，查询价格请求）可以去认定为当前服务器1T/S，RPS:3R/S。

性能测试需要定个目标1000r/s 响应时间1000ms

10000用户选80%基准用户

什么情况要压爆服务器；看下服务器的极限到底在哪里

性能测试场景分类

基准测试场景

单业务的容量测试

作用：在无压力场景下，单业务响应时间标准，以及获取单业务最大容量，为后期混合测试场景提供参考。
容量场景

也即根据生产实际情况，按比例混合待测试的所有业务。
稳定性场景

针对混合比例业务场景，选取一个容量，进行长时间的压测，观察系统的响应。
异常场景

根据系统实际的架构，模拟异常情况下系统的处理能力，以及系统恢复后，TPS、响应时间是否能够恢复。

压测模型

普通线程组：给定线程数，持续时间。
阶梯式加压：使用Ultimate Thread Group
多业务按比例加压假设业务1：业务2=1:2

业务名称	响应时间
业务1	200ms
业务2	500ms

现在设置阶梯式加压

线程数配置=TPS/(1000ms/预期响应时间)

在jmeter中多线程配置，在测试计算中添加两个线程组：每个线程组单独配置线程数和取样器。

二八模型

80%的请求都集中在20%的时间内

网站的注册用户1000w，日活跃用户大概是100w左右，那么最极端情况下，这100w人都会来签到，那么每天大概有100w次签到请求，80%的请求数就是100w*0.8=80w。其次确定系统的20%时间，大多数系统是24小时对外提供服务的，但是大多数系统在0点到6点之间访问量很少，可以忽略不计。减去6个小时，还剩下18个小时，那20%的时间=18小时*3600秒*0.2=12960秒。最终计算结果为80w请求/12960秒=61左右，即TPS满足61即可。再乘以冗余系统，一般在2-5之间。取3，61*3=183。

二八定律的算法为：80%的请求/20%的时间*冗余系数

单个接口加压

查找TPS没有明显增长的时间，对应时间的线程数，随着继续加压，线程数增多，TPS没有增多，响应时间增加，继续加压，响应时间会猛增，TPS到极限了，大致计算出TPS的极限

混合测试比例

根据多个接口请求的比例，进行分配TPS。不同阶段有不同的总TPS。

三个接口选择三个终极线程组

每个终极线程组的线程数量，启动时间，运行时间

Jmeter

线程组：就是虚拟用户

线程数：虚拟用户数量
Ramp-Up时间：创建完所有线程的时间，如果设置为0，表示多个线程同时并发
线程数是10，并且ramp up时间是10s，那么jmeter将用10秒加载10个线程，也就是平均1秒加载一个虚拟用户
循环次数：线程组每个线程的重复次数。设置成永远，则会一直重复运行。

自定义变量

${var}

http信息头管理器

可以设置Content-Type的类型

获取登录的token:请求登录接口后，从查看结果树，获取 json格式的响应体，得到token

http请求的取样器结果

Connect Time:jmeter和被测试系统建立TCP连接的时间，包括3次握手时间，如果连接复用，值为0
lantency:从发出请求到接收完第一个响应的时间
loadtime:从发出请求前到接收完所有响应的时间，如果是长消息，往往时长大于等于lantency，因为有多个响应

JMeter连接数据库

线程组->添加->配置元件->JDBC Connection Configuration

在JDBC Request中，需要配置以下信息：

在后续的HTTP请求或其他取样器中，可以通过${变量名_索引}的方式引用查询结果。例如，第一个name的值可以通过${name_1}引用

JMeter组件

聚合报告
吞吐量定时器

以指定数字的吞吐量（即指定TPS），要求指定每分钟的执行数。吞吐量计算的范围可以为指定为当前线程、当前线程组、所有线程组。
三个监听器插件

三个监听器
Custom Thread Groups插件

包含Stepping Thread Group（阶梯线程组）, **Ultimate Thread Group（终极线程组）**等常用元件
- start thread count:加载多少线程
- initial delay,sec:线程延迟多长时间开始运行
- startup time,sec:线程加载多长时间
- hold load for,sec:线程持续运行多长时间
- shutdown time:在多长时间内停止所有线程
响应时间258原则

基于用户角度实现：二秒内优秀、五秒一般、八秒问题

Response Times Distribution

响应时间分布：柱状图，x轴：响应时间，y轴：请求数量；查看不同响应时间的请求数量

当20个用户访问产品列表时，QPS达到30时的平均响应时间是多少

三个参数

操作步骤：

线程数：虚拟用户数，一个虚拟用户占用一个线程或进程
准备时长（单位s）：设置虚拟用户数需要多长时间全部启动，如果线程数是20，准备时长是10，那么需要10秒钟启动20个线程。也就是每秒启动2个线程。
循环次数：每个线程发送请求的次数。如果线程数为20，循环次数为5，那么每个线程发送5次请求，总请求数为100

Jmeter命令行

jmeter -n -t d:\xxx.jmx -l result.jtl -j run.log -R ip1:port1,ip2:port2

-n:不要图形化
-t:运行指定目录的jmx文件
-l:jmx运行的数据保存到result.jtl
-j:日志文件保存到run.log
-R ip1:port1,ip2:port2:使用远程负载机ip1和ip2，同时执行jmx脚本

如果使用jmeter执行24小时稳定性测试，在长时间无操作的情况下，一般终端工具会自动断开ssh连接，导致进程中断，可以配合使用nohup命令进行后台执行。nohup jmeter -n -t

使用jtl文件生成html报告，保存在当前目录html/test下：jmeter -g result.jtl -e -o html\test (jmeter.properties中，jtl文件也是配置为csv的情况下)

jmeter.properties中jmeter.save.saveservice.output_format=csv注释去掉

实现参数的传递
- ${_P(thread.num)}变量名thread.num
- ${_P(thread.num,1)}变量名thread.num，默认值1
- ${_property(thread.num,t_num,1)}变量名称thread.num赋值给变量t_num，默认值为

通过-D 来实现参数的传递

jmeter -n -t p.jmx -l result.jtl -D thread.num=5 -D rampUp.time=10 -D run.time=30 -e -o html/test命令执行测试，表示使用5并发，在10s尽快上用户，共执行30秒的测试场景