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

目录

一、性能测试的指标

1、并发量

2、响应时间

3、错误率

4、吞吐量

5、资源使用率

二、压测全流程

三、其他注意点

1、并发和吞吐量的关系

2、并发和线程的关系

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

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

2. 如何搭建分布式集群

3. 实施集群压测及监控

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

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

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

7. 开发压测监控大屏

8. 汇总多个测试报告

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

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

11. 性能分析及测试结论

12. 区分压测问题与程序问题

13. 内存溢出与性能问题标注

14. 与 BI 项目的关联

四、调优（待仔细学习）

1. 缓存调优

2. 集群调优

3. MQ（消息队列）中间件调优

4. 分布式微服务全链路压测

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

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. 压测场景分析

2. 在做性能测试之前，先做接口测试

3. 收集性能指标

4. 分析性能数据

5. 梳理性能报告

三、其他注意点

1、并发和吞吐量的关系

• 并发请求：发送给服务器的请求数量

• 吞吐量：服务器每秒能处理的请求数量

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

(2) 并发量>吞吐量

2、并发和线程的关系

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

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

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

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

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

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

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

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

2. 如何搭建分布式集群

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

1. 准备多台施压机： 确保所有施压机和控制机（JMeter Controller）在同一网络中，能够相互通信。

2. 配置 JMeter：

   • 在所有施压机上安装与控制机相同版本的 JMeter。

   • 修改

     jmeter.properties

     文件，确保

     remote_hosts

     配置项包含所有施压机的 IP 地址。例如：

     remote_hosts=192.168.1.2,192.168.1.3,192.168.1.4

3. 启动 JMeter Server：

   • 在每台施压机上，通过命令行启动 JMeter Server：

     jmeter-server

4. 启动测试：

   • 在控制机上打开测试计划，选择 Run > Remote Start All 或选择特定的施压机启动测试。

3. 实施集群压测及监控

集群实施步骤：

• 测试计划设计： 确保测试计划是分布式友好的，例如避免使用非线程安全的元素。

• 同步资源： 所有施压机应使用相同的测试脚本和资源文件。

• 启动测试： 通过控制机统一启动所有施压机的测试。

监控压测情况：

• 实时监控工具： 使用 JMeter 自带的监听器或更高级的工具（如 Grafana 与 InfluxDB）进行实时监控。

• 集中监控平台： 可以开发一个监控大屏，将各施压机的性能指标汇总展示。

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

应对策略：

1. 自动化监控与报警： 实时监控每台施压机的状态，若发现某台施压机报错或宕机，立即触发报警。

2. 自动恢复机制： 配置自动重启脚本，确保施压机故障后能自动重启 JMeter Server。

3. 测试任务再分配： 如果施压机长时间故障，可以手动或自动将其负载转移到其他施压机。

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

关键点：

• 资源稳定性： 确保施压机和被测系统在长时间压测下资源不泄漏（如内存、文件句柄）。

• 断点续测： 设计测试计划时考虑断点续测机制，以防测试中断后能够恢复。

• 日志管理： 合理配置日志级别，避免长时间压测产生过多日志，影响系统性能。

• 定期检查： 在压测过程中定期检查施压机和被测系统的性能指标，及时发现潜在问题。

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

实现方法：

• 用户思考时间： 在 JMeter 中使用 Timers（定时器） 元素，如 Gaussian Random Timer 或 Constant Timer，模拟用户思考时间。

• 多个服务压测： 在测试计划中设计多线程组，每个线程组针对不同的服务进行压测，或在同一线程组中配置不同的请求，确保多个服务同时承受压力。

• 逻辑控制： 使用 Controllers（控制器） 元素，如 Transaction Controller 或 Module Controller，管理复杂的测试逻辑。

7. 开发压测监控大屏

监控大屏开发步骤：

1. 数据收集：

   • 使用 JMeter Backend Listener 将性能数据发送到时序数据库，如 InfluxDB。

   • 配置监控工具（如 Grafana）连接 InfluxDB 以实时获取数据。

2. 展示内容：

   • 施压机性能指标： CPU、内存、磁盘使用率。

   • 被测服务指标： 响应时间、吞吐量、错误率。

   • 应用层指标： JVM 内存使用、垃圾回收情况、数据库性能指标（如 MySQL 的连接数、查询性能）。

3. 可视化设计：

   • 使用 Grafana 创建仪表板，将各类指标以图表、仪表盘等形式展示。

   • 设置阈值和警报规则，实时标注异常情况。