全面指南：使用JMeter进行性能压测与性能优化（中间件压测、数据库压测、分布式集群压测、调优）

甜甜不吃芥末

已于 2024-09-22 17:04:32 修改

阅读量5.5k

点赞数 39

文章标签： jmeter 性能优化中间件

于 2024-09-22 17:04:05 首次发布

本文链接：https://blog.youkuaiyun.com/skvjw/article/details/142439770

版权

6. 处理混合场景：用户思考时间及多个服务同时压测

7. 开发压测监控大屏

8. 汇总多个测试报告

9. 监控服务器的 CPU、内存、磁盘

10. 监控 Java 程序、Nginx、MySQL 数据库及 JVM 指标

五、连接数据库进行数据库压测（待仔细学习）

1、步骤

2、性能测试指标

3.性能瓶颈发现方法

一、性能测试的指标

1、并发量

定义：描述一个系统所面临的压力，服务器收到多少请求（多少/秒）
用的人多，服务器收到请求多，并发量就高。
用来描述场景

2、响应时间

定义：请求开始到获取结果的时长（毫秒 1000ms=1s）
直观反映了用户体验
统计方式：平均响应时间（按响应时间分布 90% 95% 99%）
平均响应时间：是对所有请求的响应时间取平均值，代表整体性能的一个平均水平。

百分位数（90%、95%、99%）：
- 90%百分位数：表示90%的请求响应时间都小于这个值，也就是说有10%的请求响应时间是比这个值更长的。
- 95%百分位数：表示95%的请求响应时间都小于这个值，也就是说有5%的请求响应时间比这个值更长。
- 99%百分位数：表示99%的请求响应时间都小于这个值，也就是说有1%的请求响应时间比这个值更长。

3、错误率

定义：高并发海量请求场景，系统出错误的比例。

错误率=出错请求数量/整体请求数量

4、吞吐量

定义：服务器1秒内处理了多少请求
吞吐量和并发量的区别：并发量是服务器收到请求，吞吐量是服务器处理请求
细分概念
- QPS (Queries Per Second)：QPS 指的是每秒能够处理的查询数量，通常用于描述Web服务**或数据库在一定时间内处理请求的能力。
- TPS (Transactions Per Second)：TPS 指的是每秒能够处理的事务数量，这里的事务通常指的是一系列逻辑上的操作，这些操作可能包含多个查询、插入、更新等。一个事务需要满足ACID属性（原子性、一致性、隔离性、持久性）。

5、资源使用率

定义：程序在测压中，服务器资源的占用情况
程序运行代码需要占用服务器资源，CPU/内存、磁盘、网络...

这个是网络的指标不是性能测试的指标：

1、带宽

定义：网络吞吐量，系统或网络在单位时间内能够传输的数据量
单位：比特每秒（bps）为单位，常见的单位有10mb/s（兆比特每秒）

2、时延

二、压测全流程

(压力测试及压力测试前的接口测试详细请看另一个文章)

压测场景分析
在做性能测试之前，先做接口测试
收集性能指标
分析性能数据
梳理性能报告

三、其他注意点

1、并发和吞吐量的关系

并发请求：发送给服务器的请求数量
吞吐量：服务器每秒能处理的请求数量

(1) 先有并发，再有吞吐量（现有请求再有处理）。

(2) 并发量>吞吐量

2、并发和线程的关系

（1）并发量不等于线程数

有时候一个线程一秒钟能产生多次请求
有时候一个线程一秒钟不能完成一次请求

（2）线程数量=并发量*最大响应时间（秒）

四、调优及分布式集群压测（待仔细学习）

（性能测试需要剥夺业务层的干扰，有时候也需要对中间件直接压测，查看其性能）

1.线程数量超过单机承载能力时的解决方案

当单台运行 JMeter 的机器无法再增加线程数量时，可以采用 分布式集群 的方式，通过多台施压机（JMeter Server）共同承担压测任务。

2. 如何搭建分布式集群

（1）分布式集群搭建步骤如下：

准备多台施压机： 确保所有施压机和控制机（JMeter Controller）在同一网络中，能够相互通信。
配置 JMeter：
- 在所有施压机上安装与控制机相同版本的 JMeter。
- 修改
```
jmeter.properties
```
  文件，确保
```
remote_hosts
```
  配置项包含所有施压机的 IP 地址。例如：
```
remote_hosts=192.168.1.2,192.168.1.3,192.168.1.4
```
启动 JMeter Server：
- 在每台施压机上，通过命令行启动 JMeter Server：
```
jmeter-server
```
启动测试：
- 在控制机上打开测试计划，选择 Run > Remote Start All 或选择特定的施压机启动测试。

3. 实施集群压测及监控

集群实施步骤：

测试计划设计： 确保测试计划是分布式友好的，例如避免使用非线程安全的元素。
同步资源： 所有施压机应使用相同的测试脚本和资源文件。
启动测试： 通过控制机统一启动所有施压机的测试。

监控压测情况：

实时监控工具： 使用 JMeter 自带的监听器或更高级的工具（如 Grafana 与 InfluxDB）进行实时监控。
集中监控平台： 可以开发一个监控大屏，将各施压机的性能指标汇总展示。

4. 处理集群中单台施压机报错的情况

应对策略：

自动化监控与报警： 实时监控每台施压机的状态，若发现某台施压机报错或宕机，立即触发报警。
自动恢复机制： 配置自动重启脚本，确保施压机故障后能自动重启 JMeter Server。
测试任务再分配： 如果施压机长时间故障，可以手动或自动将其负载转移到其他施压机。

5. 长时间压测（10小时）的注意事项

关键点：

资源稳定性： 确保施压机和被测系统在长时间压测下资源不泄漏（如内存、文件句柄）。
断点续测： 设计测试计划时考虑断点续测机制，以防测试中断后能够恢复。
日志管理： 合理配置日志级别，避免长时间压测产生过多日志，影响系统性能。
定期检查： 在压测过程中定期检查施压机和被测系统的性能指标，及时发现潜在问题。

6. 处理混合场景：用户思考时间及多个服务同时压测

实现方法：

用户思考时间： 在 JMeter 中使用 Timers（定时器） 元素，如 Gaussian Random Timer 或 Constant Timer，模拟用户思考时间。
多个服务压测： 在测试计划中设计多线程组，每个线程组针对不同的服务进行压测，或在同一线程组中配置不同的请求，确保多个服务同时承受压力。
逻辑控制： 使用 Controllers（控制器） 元素，如 Transaction Controller 或 Module Controller，管理复杂的测试逻辑。

7. 开发压测监控大屏

监控大屏开发步骤：

数据收集：
- 使用 JMeter Backend Listener 将性能数据发送到时序数据库，如 InfluxDB。
- 配置监控工具（如 Grafana）连接 InfluxDB 以实时获取数据。
展示内容：
- 施压机性能指标： CPU、内存、磁盘使用率。
- 被测服务指标： 响应时间、吞吐量、错误率。
- 应用层指标： JVM 内存使用、垃圾回收情况、数据库性能指标（如 MySQL 的连接数、查询性能）。
可视化设计：
- 使用 Grafana 创建仪表板，将各类指标以图表、仪表盘等形式展示。
- 设置阈值和警报规则，实时标注异常情况。

最低0.47元/天解锁文章