性能测试基础
理解性能测试基础是学习性能测试工具的前提。以下是核心概念和知识的详细展开，帮助新手建立系统性认知：
一、 性能测试的核心目标
- 验证系统能力：系统能否在预期用户量和请求量下正常运行？
- 发现性能瓶颈：CPU、内存、磁盘 I/O、网络、数据库、代码等环节是否存在瓶颈？
- 评估稳定性：高负载或长时间运行下，系统是否会出现崩溃、内存泄漏等问题？
- 优化依据：通过测试结果指导开发、运维团队进行调优。
二、性能测试的主要类型
| 测试类型 | 定义和场景 | 示例 |
|---|---|---|
| 基准测试 | 单用户、单请求场景下的性能基线（Baseline）。 | 测试一个用户登录接口的响应时间。 |
| 负载测试 | 逐步增加并发用户数，观察系统在预期负载下的表现。 | 模拟 1000 用户同时浏览商品页，持续 10 分钟。 |
| 压力测试 | 超过系统预期负载（如 2 倍用户量），测试系统的极限和故障恢复能力。 | 5000 用户同时抢购限量商品，观察系统是否崩溃。 |
| 并发测试 | 验证多用户同时操作同一功能时的正确性。如：抢红包、抢购、秒杀活动、库存扣减等。 | 100 用户同时提交同一商品的订单。 |
| 稳定性测试 | 长时间运行（如 24 小时、一周）下，系统资源使用是否平稳，有无内存泄漏。 | 持续模拟 500 用户在线，检查内存占用趋势。 |
| 容量测试 | 确定系统能支撑的最大用户量或数据量，关注系统在极限情况下的各种极限参数值。如：数据库存储上限，最大TPS，最大连接数，最大并发数，最多数据条数等。 | 逐步增加用户数，直到系统响应时间超过阈值。 |
三、关键性能指标（KPIs）
包括响应时间、并发数、吞吐量（TPS、QPS）、错误率、点击数、资源利用率。
1. 用户感知指标
提示
从用户角度出发，软件使用是否卡顿、好用、体验流畅、能返回正确的信息。
（1）响应时间（Response Time）
- 定义：从发送请求到接收完整响应的时间（通常包含网络延迟）。
- 细分：可分解为服务器处理时间、数据库查询时间、网络传输时间等。
- 示例：用户点击“支付”按钮后，平均 2 秒收到支付成功提示。
（2）并发用户数（Number of concurrent users）
定义：某一物理时刻同时向系统提交请求的用户数。
示例：淘宝当前正在使用系统的用户数：500万。
（3）吞吐量（Throughput）
定义：单位时间内系统处理的请求数（如请求数/秒）。 衡量服务器性能好坏的直接指标。
从不同维度来衡量吞吐量：
- 业务维度：业务数/秒，业务数/小时，业务数/天
- 网络维度：字节数/秒，字节数/小时，字节数/天；
- 技术维度：TPS（每秒事务数）、QPS（每秒请求数）。
相关信息
QPS：
- 定义：服务器每秒钟处理的接口请求数量。
- 解释：一个服务器中有多个接口，QPS指的是在同一个单位时间内的接口处理数量之和。
- 示例：5次支付操作（3个接口请求），服务器的QPS为15。
TPS：
- 定义：服务器每秒钟处理的事务请求数量。
- 解释：一个事务通常指的是界面上的一个操作，一个事务可以包含一个或者多个接口请求。
- 示例：5次支付操作（3个接口请求），服务器的TPS为5。
（5）错误率（Error Rate）
- 定义：失败请求数占总请求数的百分比。
- 常见错误：HTTP 5xx 服务器错误、超时、业务逻辑错误（如库存不足未处理）。
（6）点击数（number of hits）
定义：点击数不是指在页面上的一次点击，页面（html代码、图片、js...）加载时，向服务器发送的请求数量，可以用每秒点击数来衡量web服务器的处理能力。
示例：登录操作，支持1000人同时点击登录，除了登录请求，还会发送请求其它的资源的请求。
注意
点击数是衡量Web服务器处理能力的一个重要指标。
只有web项目才有此指标。
2. 系统资源指标
- CPU 利用率：超过 80% 可能成为瓶颈（需结合上下文，如计算密集型任务可能合理）。
- 内存占用：持续增长可能提示内存泄漏。
- 磁盘 I/O：频繁读写可能导致延迟（如数据库未合理索引）。
- 网络带宽：吞吐量受限于网络带宽（如大文件上传场景）。
提示
通常，没有特殊需求的话。
建议CPU不高于88%（±5）；
在电脑里的所有处理请求（操作系统运行、软件程序、磁盘拷贝等） 都由CPU完成。
内存不高于80% ；
所有程序在运行时要消耗的空间，（存储程序运行的数据）。
磁盘不高于90%；
需预留空间存储本地数据文件。
网络不高于80%；
影响数据在网络中的传输速度。
四、常见性能问题
| 问题类型 | 表现与原因 | 解决方法 |
|---|---|---|
| 慢 SQL 查询 | 数据库响应时间长，CPU 或 I/O 占用高。 | 优化 SQL 语句，添加索引，分库分表。 |
| 线程阻塞 | 线程池满，请求排队等待（如数据库连接池不足）。 | 调整线程池大小，优化锁机制。 |
| 缓存失效 | 缓存击穿/穿透导致大量请求直接访问数据库。 | 使用布隆过滤器、设置热点数据永不过期。 |
| 外部服务瓶颈 | 第三方 API 响应慢（如支付接口）。 | 增加超时设置，引入熔断机制（如 Hystrix）。 |
| 资源竞争 | 多线程共享资源（如全局变量）导致死锁或数据不一致。 | 使用原子操作、分布式锁（如 Redis Lock）。 |
五、学习方法建议
理论结合实践
- 阅读《性能测试从零开始》等书籍，理解基础概念。
- 动手搭建简单系统（如 Spring Boot + MySQL），模拟性能问题并修复。
观察与分析
- 使用工具监控资源：Windows 用
PerfMon，Linux 用top、vmstat、nmon。 - 可视化集群监控软件：
Prometheus+Grafana。 - 分析日志：通过日志定位慢请求（如 Nginx 的
access.log）。
- 使用工具监控资源：Windows 用
对比不同场景
- 对比单机与集群部署的性能差异。
- 测试有无缓存时的吞吐量变化。
六、基础工具入门
- JMeter：后续学习的核心工具，支持 HTTP、JDBC、JMS 等协议。
- Postman：手动测试 API 功能，辅助调试。
- Grafana + Prometheus：监控服务器资源并可视化。
七、典型问题思考
- 为什么响应时间正常，但用户仍感觉“卡顿”？
→ 可能是前端资源加载慢（如未压缩的图片或 JavaScript 文件）。 - TPS 达到峰值后为何突然下降？
→ 可能触发了系统限流，或数据库连接池耗尽。 - 如何区分网络延迟和服务端延迟？
→ 使用curl -w分析各阶段时间，或通过浏览器开发者工具查看 Waterfall 图。
提示
Waterfall的内容后续学习。
掌握这些基础后，再学习 JMeter 时会更容易理解其设计逻辑（如线程组模拟用户、定时器控制请求频率）。后续可结合具体项目，从简单接口逐步过渡到复杂场景的压测。