目录[-]

Jmeter 为什么可以做性能测试？

 

1. 多线程架构

  • 虚拟用户模拟：通过线程组（Thread Group）模拟大量并发用户，每个线程独立执行测试脚本，真实还原用户并发场景。

  • 资源高效：基于Java的多线程机制，单机可模拟数千并发（需合理配置）。

2. 完备的协议支持

  • Web/API测试：原生支持HTTP/HTTPS（可录制浏览器操作）。

  • 数据库测试：通过JDBC直接压测MySQL/Oracle等数据库。

  • 其他协议：FTP/SOAP/REST/JMS等，满足多样化测试需求。

  • 扩展性：插件支持如WebSocket、MQTT等新兴协议。

3. 精确的负载控制

  • 阶梯式加压：使用Stepping Thread Group插件逐步增加并发数，观察系统临界点。

  • 持续负载：设置线程持续运行时间，测试系统稳定性。

  • 定时器（Timers）：模拟思考时间（Think Time），避免瞬时峰值不真实。

4. 全面的监控与断言

  • 性能指标采集：

    • 响应时间（Response Time）

    • 吞吐量（Throughput）

    • 错误率（Error Rate）

    • 服务器资源（CPU/内存，需配合插件）。

  • 断言机制：验证响应内容/状态码，确保功能正确性。

5. 分布式测试能力

  • 跨机器协作：通过Master-Slave模式，多台机器共同施压，突破单机性能瓶颈。

  • 云集成：支持与AWS、Azure等云平台结合，快速搭建测试集群。

6. 结果分析与可视化

  • 实时监控：View Results Tree、Summary Report等监听器实时查看数据。

  • 图表报告：生成HTML报告，包含响应时间分布、吞吐量趋势等可视化图表。

  • 数据导出：结果可导出为CSV/XML，便于用其他工具（如Grafana）深度分析。

7. 灵活的测试逻辑

  • 参数化：CSV文件或函数生成动态测试数据。

  • 条件逻辑：使用If Controller实现分支判断。

  • 关联提取：正则表达式/JSON提取器捕获响应数据供后续请求使用。

8. 生态系统支持

  • 插件库：通过JMeter Plugins Manager扩展功能（如服务器监控、高级图表）。

  • CI/CD集成：与Jenkins、GitLab CI等工具联动，实现自动化性能测试。

————

Jmeter 在测试过程中，需要关注哪些指标？

 

  1. 响应时间：可参考1、3、5原则，或2、5、8原则，比如1s内是很快，3秒是正常，5秒是慢；如果超5秒，甚至是30秒超时，那就非常有问题
  2. TPS（Transactions Per Second）：每秒处理数，也可以理解为，一个请求从发送到接收是一个事务，处理事务的数量
  3. 错误率：最好是100%成功率，但是在高并发下，不可能存在不报错的情况，需要考虑的是，在高并发下，超时在所难免，这时就要关注业务上的表现，最早的12306，在高并发量下，甚至造成了服务器崩溃，需要重启的情况
  4. CPU、内存、磁盘IO：性能指标，在早期的 Jmeter ，需要将一个单独的文件 serveragent 放置在服务器上并启动，进而获取服务器的性能指标，或者是连接到服务器并使用top等命令获取指标，随着云服务器的发展，kuboard集群运维和grafana数据可视化工具的应用，监控指标就不用这么麻烦了

————

什么是线程，Jmeter里的线程指的是什么？

 

先说一个概念，进程、线程是什么，进程由多个线程组成，Jmeter每一次的请求，都是以线程为单位，打个比方，一个进程是一个车间，而线程就是车间里的工人，多个工人做不同的事，最终使车间实现既定的目标，我们讨论也大多是以“进程”来讨论，比如windows系统，CTRL+ALT+DELETE打开任务管理器，运行的每一个程序都是进程，杀掉进程后，会让进程下的所有线程停止工作。

Jmeter单进程能够创建的“测试线程数（虚拟用户）”主要取决于：

  • 内存：每个线程默认占用 1~2 MB 栈空间
    • 公式：最大线程数=可用内存/线程栈大小
    • 例如：8GB 内存的机器，理论支持 4000~8000 线程（需预留其他内存）
  • CPU：线程数超过物理核心数时，上下文切换开销增加

可以通过调整 jmeter.bat 中的JVM参数，比如下图，最小2G，最大4G，也就是大概能创建1000~2000线程组，本地创建太多线程，也有可能造成一个问题，就是压测机的性能不足够承载这么大的并发量，如本地CPU、内存、带宽等，所以在制定压测目标和分析时，需判断，要不要使用分布式，多台压测机进行测试

# 减小线程栈大小（默认1MB，64位系统可设为256KB）
JVM_ARGS="-Xss256k" 

# 增加堆内存（避免OOM）
JVM_ARGS="-Xms2g -Xmx4g"

Jmeter线程组，多条线程依次处理，可以理解为多个工人在同一间车间做事，而性能指标，可以针对车间也可以针对具体的工人（线程）————

下面放一张性能测试的图片

=

  1. 同步定时器，Synchronizing Timer，如右图，意思是1000毫秒内启动200个并发线程
  2. 线程组：
    1. 线程属性：
      1. Ramp-Up时间（秒），指的是在1s内，启动200线程组
      2. 循环次数（永远）：压测过程中，不可能存在压测1次的情况，都是需要持续一定时间
    2. 调度器：
      1. 持续时间（秒）：压测持续多少时间

        

      3.聚合报告：Jmeter最重要的性能测试指标

————

Jmeter 性能指标分析

 

一、核心性能指标

1. 吞吐量（Throughput）

  • 定义：单位时间内系统处理的请求数（请求数/秒）

  • 计算：吞吐量 = 总请求数 / 测试时长

  • 健康值：越高越好，需对比系统设计目标

  • 异常分析：

    • 吞吐量低 → 检查服务器CPU/内存/数据库瓶颈

    • 吞吐量波动大 → 网络抖动或资源竞争

2. 响应时间（Response Time）

指标 说明
Average 平均响应时间
Median 50%请求的响应时间
90% Line 90%请求的响应时间（更关注慢请求）
Min/Max 最快/最慢响应时间

  • 健康值：根据业务需求设定阈值（如API需<500ms）

  • 异常分析：

    • 响应时间陡增 → 检查代码慢查询或锁竞争

    • Max值异常高 → 可能存在死锁或资源泄漏

3. 错误率（Error %）

  • 计算：错误率 = 失败请求数 / 总请求数 × 100%

  • 健康值：<1%（金融类系统要求<0.1%）

  • 常见错误类型：

    • 4xx → 客户端问题（参数错误/鉴权失败）

    • 5xx → 服务端问题（代码异常/服务超载）

4. 并发用户数（Active Threads）

  • 监控方式：使用 jp@gc - Active Threads Over Time 插件

  • 关键观察：

    • 并发增长时系统性能是否线性下降

    • 最大支持并发数（性能拐点）

二、服务器资源指标

1. CPU 使用率

  • 健康值：<70%（长期>80%需扩容）

  • 工具：

    • JMeter插件：PerfMon Metrics Collector

    • 命令行：top（Linux）、Performance Monitor（Windows）

2. 内存使用

  • 监控项：

    • JVM堆内存（Java应用）

    • 系统剩余内存

  • 异常现象：

    • 内存泄漏 → 内存使用率持续上升不释放

3. 磁盘I/O

  • 关键指标：

    • IOPS（每秒读写次数）

    • 吞吐量（MB/s）

    • 等待时间（await）

  • 健康值：util < 60%（Linux iostat工具）

4. 网络带宽

  • 计算：带宽需求 = 平均响应大小 × 吞吐量

  • 瓶颈判断：

    • 网卡吞吐接近上限时出现丢包

三、JMeter 结果分析方法

1. 基础报告解读

通过 Aggregate Report 监听器查看：

Label, Samples, Average, Min, Max, Std. Dev., Error %, Throughput
Login API, 10000, 235ms, 120ms, 1200ms, 45ms, 0.2%, 450.2/s

2. 可视化分析工具

工具/插件 用途
jp@gc - Response Times Over Time 响应时间趋势图
jp@gc - Transactions per Second 实时TPS监控
BlazeMeter Analyzer 生成专业HTML报告

3. 拐点识别方法

通过阶梯加压测试（如 Concurrency Thread Group）

四、性能瓶颈定位流程

  1. 收集数据：JMeter结果 + 服务器监控（CPU/内存/IO）

  2. 指标关联：

    • 高错误率时段是否伴随CPU跑满？

    • 响应时间增长时磁盘IO是否飙升？

  3. 分层排查

  4. 五、优化建议

    高频问题解决方案

    问题现象 可能原因 优化方案
    高错误率+低吞吐量 数据库连接池耗尽 增加连接池大小/优化SQL
    响应时间逐渐变长 内存泄漏 分析Heap Dump
    吞吐量无法突破阈值 网络带宽限制 压缩数据/升级网络

    报告示例结论

1. 系统在2000并发下达到极限：
   - 最大吞吐量: 1200 TPS
   - 平均响应时间: 650ms（超过500ms SLA）
2. 主要瓶颈:
   - MySQL CPU使用率95%（慢查询导致）
   - 应用服务器线程池排队
3. 优化建议:
   - 添加数据库索引（优化`SELECT * FROM orders`）
   - 扩容应用服务器线程池至200

————

测试报告编写

 

测试模板五花八门，但是具体的指标，还是图中这些

 

————

Lniux 服务器压测流程（原始版）

 

第一步：压测之前，需要知道服务器配置策略，比如哪里存放的是业务服务器、哪里存放数据库服务器等等，如果是运维配置了grafana，那就比较容易分辨了

比如，这里有一个ip地址，业务服务器、redis、数据库mysql，都存放在同一个服务器里，压测地址：10.10.180.90，需要先使用ping命令，确保客户端有访问权限。如果是下图这种，就需要询问运维，是否需要跳板机（堡垒机）、VPN，还有账号访问权限等。

————

第二步：使用工具 Xshell 连接服务器，连接成功时，如下图，此时域名172.20.xx.xx:xx，就是真实的服务器地址

————

第三步：使用top命令，获取当前服务器的信息，如CPU、内存、I/O等内容

  1. 下图可以明显看到有4个CPU，证明服务器是4核，也可以使用命令：cat /proc/cpuinfo | grep "physical id" | uniq | wc -l    如果是单核处理器，load average的值小于1，表示不堵塞；等于1，表示没有额外资源了；大于1，则有阻塞                            如果是多和处理器，比如4核，核数4*0.7计算负载=2.8，在不超过2.8时，服务器畅通无阻
  2. sar -u 1 5    命令，每1秒采集一次cpu使用率，采集5次，得到 CPU平均空闲率

    3. 内存使用情况（memory）：总内存8010844、已使用内存2428136、空闲内存4027716、缓存内存1554992，
  空闲率百分比4027716/8010844=0.5027*100%也就是50.27%空闲率

————