零基础学习性能测试第三章:jmeter监听器及性能测试结果分析


掌握JMeter监听器与结果分析是性能测试的 核心能力。以下为零基础用户设计的极简实操指南,包含配置模板、分析框架和典型问题诊断方法:


一、必用监听器配置清单(附场景解析)

监听器类型配置路径核心作用推荐场景
聚合报告监听器 → Aggregate Report关键指标总览(TPS/RT/错误率)所有测试结果概览
响应时间曲线监听器 → Response Time Graph可视化响应时间波动趋势定位性能拐点
TPS吞吐量曲线监听器 → Transactions per Second实时监控系统处理能力容量规划测试
后端监听器监听器 → Backend Listener实时写入InfluxDBGrafana动态监控
断言结果监听器 → Assertion Results捕获业务逻辑错误验证接口功能正确性

配置示例(InfluxDB+Grafana实时监控):

# 后端监听器配置
backend=influxdb
influxdbMetricsSender=org.apache.jmeter.visualizers.backend.influxdb.HttpMetricsSender
influxdbUrl=http://localhost:8086/write?db=jmeter
application=MyApp
measurement=jmeter
summaryOnly=true

二、性能指标四维分析框架

▶ 维度1:用户感知(前端指标)
指标健康标准异常分析方向
90%响应时间≤ 3秒网络延迟/服务端阻塞
错误率≤ 0.5%代码缺陷/资源不足
吞吐量(TPS)≥ 预期值120%线程数不足/外部依赖瓶颈

分析工具:聚合报告 + 响应时间曲线
典型问题

现象:90%响应时间突增到8秒
定位:对比服务器监控,发现此时MySQL CPU达100%

▶ 维度2:资源消耗(服务端指标)
资源层关键监控项阈值警戒线工具推荐
CPU使用率>75%Grafana+Node_Exporter
内存使用率/剩余内存>80%
磁盘IO等待时间>30msiostat
数据库活跃连接数/慢查询>连接池80%Prometheus+MySQ监控

分析工具:PerfMon插件 + 服务器监控
典型问题

现象:TPS波动大,伴随磁盘IO Wait飙升
结论:磁盘成为瓶颈,需升级SSD或优化写入策略

▶ 维度3:中间件瓶颈
中间件关键指标异常值
Redis内存使用率/命中率命中率<90%
Kafka消息堆积量>1000条
Nginx5xx错误率>1%

分析工具:各中间件自监控 + JMeter插件
典型问题

现象:TPS骤降,Redis监控显示连接超时
解决:增加Redis连接池大小

▶ 维度4:链路跟踪(微服务场景)
工具核心功能定位问题类型
SkyWalking慢调用链追踪服务间调用阻塞
Arthas方法级执行耗时代码性能热点

三、五大经典性能问题诊断图谱

问题1:响应时间阶梯上升(容量不足)
响应时间曲线
阶梯状上升
线程组用户数持续增加
系统资源达到瓶颈
增加服务器资源/优化代码
问题2:TPS波动锯齿(线程竞争)
TPS曲线锯齿状
检查数据库锁
发现行锁等待
优化SQL+索引
问题3:错误率突增(资源耗尽)
错误率飙升
查看错误类型
连接超时
检查连接池
5xx错误
服务器过载
问题4:低负载高延迟(外部依赖瓶颈)

现象:50并发用户时RT已达5秒
诊断:

  • traceroute检测网络延迟
  • 检查第三方API响应时间(在JMeter中单独测试)
问题5:内存泄漏(长时间压测)

现象:运行2小时后OOM崩溃
分析:

  1. jstat -gcutil [pid] 1000观察内存增长
  2. 压测后生成heap dump:jmap -dump:live,format=b,file=heap.bin [pid]
  3. MAT工具分析泄漏对象

四、零基础分析实战模板

步骤1:基础指标筛查(聚合报告)
LabelSamplesError%90% RTTPS结论
/login100000.10%1200ms85达标
/pay80005.20%5300ms32需优化
步骤2:趋势分析(响应时间图)
  • /pay RT在300用户后飙升 → 定位数据库慢查询
  • 使用筛选器排除网络抖动:>> 图标 → Filter → 排除>10000ms的点
步骤3:关联资源指标(Grafana看板)
JMeter TPS下降
Grafana看板
MySQL CPU 100%
优化慢SQL
步骤4:生成测试报告
# 命令行生成HTML报告
jmeter -g result.jtl -o report_folder

五、高频问题解决方案速查

  1. JMeter自身成为瓶颈

    • 现象:压测机CPU 100%
    • 解决:
      • 命令行模式运行:jmeter -n -t test.jmx -l result.jtl
      • 分布式压测:添加-R 192.168.1.101,192.168.1.102
  2. 结果文件过大

    • 配置jmeter.save.saveservice属性:
      jmeter.save.saveservice.response_data=false
      jmeter.save.saveservice.samplerData=false
      
  3. Grafana无数据

    • 检查InfluxDB写入权限:curl -i -XPOST http://localhost:8086/query --data-urlencode "q=CREATE DATABASE jmeter"

六、分析报告模板(可直接套用)

性能测试报告
一、测试概述

  • 目标:验证500并发下系统稳定性
  • 场景:用户登录→搜索→下单
  • 时长:30分钟

二、关键指标

指标预期实际是否达标
90%响应时间≤3秒2.8秒
TPS≥10085
错误率≤0.5%0.2%

三、问题分析

  1. TPS不达标
    • 定位:支付接口TPS仅32
    • 根因:数据库锁竞争(监控显示锁等待超时)
    • 证据:
      SHOW ENGINE INNODB STATUS;  -- 发现`PAY_ORDER`表行锁等待
      

四、优化建议

  1. 数据库:将支付状态更新改为异步队列
  2. 代码:添加Redis分布式锁减少竞争

立即行动

  1. 下载Sample CSV报告练习分析
  2. 安装Grafana:导入JMeter仪表盘模板
  3. 用Arthas工具分析代码热点:profiler start / profiler stop

性能分析的本质是寻找指标之间的关联性。掌握“用户感知-资源消耗-中间件-代码链路”的四层定位法,结合可视化工具,即使零基础也能快速揪出系统瓶颈!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值