本文目录导读：
开源项目的压力测试，通常不仅仅是为了测出系统能抗多少并发（QPS/TPS），更是为了找到系统的瓶颈、验证稳定性、以及为后续的容量规划提供依据。
针对开源项目（尤其是Web服务、API、数据库中间件、消息队列等）,一套完整且靠谱的压力测试流程可以分为以下几步：
第一步：明确目标与准备环境
在开始压测前,先问自己几个问题：
- 测什么？ 某个核心API接口？整个登录流程？数据库读写？还是消息队列的吞吐？
- 预期指标是什么？ 目标QPS（每秒查询数）是多少？允许的最大延迟（P99延迟）是多少？CPU和内存的阈值是多少？
- 环境隔离： 绝对不要在生产环境压测！ 准备一套与生产环境配置（CPU核数、内存、磁盘类型）尽量一致的压测环境，最好能独占一台服务器,避免其他进程干扰。
第二步：选择合适的压测武器
根据你的技术栈和项目类型,选择以下主流开源工具：
| 工具 | 适用场景 | 语言/特点 |
|---|---|---|
| wrk | HTTP/HTTPS API、Go/Java Web服务 | 基于C，性能极高，适合对延迟敏感的场景。 |
| ab | 简单的HTTP接口 | Apache自带，最轻量，但功能单一（单URL）。 |
| JMeter | 复杂业务流、协议（JDBC，JMS）、GUI配置 | Java系，功能最全面，插件丰富，但资源消耗大。 |
| Locust | 模拟用户行为、分布式压测 | Python写脚本，可编程性强，Web界面友好。 |
| Vegeta | Go服务、命令行爱好者、持续集成 | Go编写，安装简单，结果输出漂亮。 |
| Tsung | 高并发、分布式、多协议（XMPP, MQTT等） | Erlang编写，适合长连接和实时通信。 |
| sysbench | 数据库（MySQL, PostgreSQL） | 专门针对数据库的OLTP基准测试。 |
| ghz | gRPC服务 | 专为gRPC协议设计，支持protobuf。 |
推荐组合：
- 快速测API性能：
wrk或Vegeta - 复杂业务流程：
JMeter或Locust - 测数据库/中间件：
sysbench或YCSB（Yahoo! Cloud Serving Benchmark）
第三步：制定测试策略（压力模型）
不要一上来就“死磕”最大并发,通常按以下步骤进行：
- 基准测试： 1个并发用户，持续运行几分钟,目的是看单次请求的理想延迟和基础吞吐。
- 负载测试： 逐渐增加并发（比如从10 -> 50 -> 100 -> 500），观察延迟和吞吐量随压力的变化，找到“拐点”——即吞吐量不再线性增长、延迟开始暴增的点。
- 压力测试： 在目标负载（比如预期QPS的1.5倍）下，持续运行较长时间（比如30分钟到1小时），观察系统是否稳定，有没有内存泄漏、CPU飙升不降、连接池耗尽等问题。
- 稳定性测试： 在常规负载下运行 12-24小时，监测内存、线程数是否持续增长（泄漏迹象）。
- 尖峰测试： 瞬间将并发从很低加到很高，看系统能否扛住流量毛刺，以及扩容/熔断机制是否生效。
第四步：监控与分析（最关键的一环）
压测结果不仅仅是“跑了多少QPS”，必须同时监控被压测方和压测机的状态。
你需要监控的指标：
- 服务端（开源项目所在机器）：
- 资源： CPU（用户态/内核态/等待I/O）、内存、磁盘I/O（await, %util）、网络带宽。
- 应用层： JVM（堆内存、GC次数/时间、线程状态）、Go runtime（Goroutine数、GC）、连接数（TCP连接、数据库连接池）。
- 系统底层： 上下文切换（
vmstat 1）、中断数、文件描述符数（ulimit -n）。
- 客户端（压测机）：
确保压测机自己没有成为瓶颈（CPU跑满、网络带宽打满）。
常用监控工具：
top/htop：实时查看CPU和内存。vmstat 1：查看CPU、内存、IO。pidstat 1：查看特定进程的线程数、上下文切换。Perf：分析CPU热点函数（性能瓶颈）。Prometheus + Grafana：最专业的监控方案,适合长期运行。arthas（Java项目）：在线诊断，看调用链、线程堆栈。
第五步：解读结果与优化
压测结束后，你会得到一组数据，常见的“症状”及对策：
| 现象 | 可能原因 | 对策 |
|---|---|---|
| CPU打满，QPS上不去 | 业务逻辑复杂、缺乏缓存、序列化效率低 | 优化算法、加本地缓存、改用Protobuf/FlatBuffers |
| CPU不高，QPS上不去 | 阻塞在I/O上（磁盘I/O慢、网络I/O慢、锁竞争） | 优化数据库查询、改用SSD、减少锁粒度、增加线程池 |
| 延迟忽高忽低（毛刺） | GC停顿（Java）、内存换页（Swap）、连接池耗尽 | 调整GC参数（改用G1/ZGC）、禁用Swap、增大连接池 |
| 内存持续增长不下降 | 内存泄漏 | 使用内存分析工具（如MAT, pprof）定位泄漏源 |
| 连接数满，拒绝连接 | 文件描述符限制（Too many open files） | 修改 ulimit -n 和内核参数 net.core.somaxconn |
| CPU在sys（内核态）占用高 | 频繁的系统调用（如大量读写文件、网络收发） | 使用零拷贝技术（sendfile）、批量操作、优化网络IO |
避坑指南（非常重要）
- 压测机不能成为瓶颈： 压测机CPU、网络、端口必须充裕，如果压测机CPU都100%了，测出来的结果不准，尽量用多台机器做分布式压测（如Locust、JMeter分布式）。
- 预热： 很多开源项目（特别是JVM系的）需要预热（JIT编译、缓存填充）,压测前先跑几分钟流量。
- 清理缓存： 如果测数据库（MySQL/Redis），要避免数据全在内存里没落盘，可以
echo 3 > /proc/sys/vm/drop_caches清理系统缓存再去测（但要注意业务数据一致性）。 - 控制变量： 一次只改一个参数，比如从“单次查询”改为“批量查询”，或从同步改为异步,不要同时修改代码和配置。
- 结果要带百分位： 只看平均延迟没意义，一定要看 P99（99%的请求延迟） 和 P999，P99哪怕高一点,用户体验可能就很差。
一个快速上手的“最小可行流程”
假设你要压测一个 Go Web 服务 的 /api/v1/users 接口：
-
环境： 一台4核8G的Linux机器（服务端），另一台同网段机器（压测端）。
-
工具：
wrk。 -
命令：
# 1. 基准测试 (1个连接，跑10s) wrk -t1 -c1 -d10s http://192.168.1.10:8080/api/v1/users # 2. 逐步加压 (从50并发到200并发) wrk -t4 -c50 -d30s http://... wrk -t8 -c100 -d30s http://... # 3. 最大压力 (模拟大量用户) wrk -t8 -c200 -d60s http://...
-
同时监控： 在服务端开另一个终端运行
htop和vmstat 1。 -
分析： 对比不同并发下的QPS和延迟，观察CPU/内存变化，如果QPS在100并发后就上不去了，且CPU还没满，那就很可能是I/O瓶颈（比如数据库连接池不够）。
开源项目的压力测试，本质上是一个“观测-假设-验证-优化”的循环，工具只是手段，找到系统在真实压力下的“薄弱环节”才是最终目的。
