你的网站要上线了，或者要搞促销活动。你心里没底：服务器能扛多少并发？会不会崩？
你跑了个ab命令，看到Requests per second: 500，觉得还行。但你不知道这500是在什么场景下测的，也不知道瓶颈在哪，更不知道该怎么调。
压力测试不是跑一个命令看一个数字。它是一个完整流程：定目标→写脚本→加压→分析→调优→复测。今天走一遍这个流程。
先看一个数据
某电商网站大促前做压测，发现登录接口在300并发时响应时间从200ms飙升到3s。优化了数据库连接池后，同样并发下响应时间降到400ms。如果没有压测，大促当天用户登录要等3秒，流失率至少30%。
压测不是技术炫耀，是风险排查。你不知道系统的极限在哪，系统就会在你最需要它的时候告诉你。
第一步：定目标——你要测什么？
没有目标的压测是瞎跑。先问自己几个问题：
- 预期并发是多少？ 业务部门给的峰值预估，比如“同时在线5000人”
- 可接受的最大响应时间是多少？ 比如API接口<200ms，页面<1s
- 可接受的最大错误率是多少？ 通常<0.1%
压测目标示例：
在1000并发下，首页接口P99响应时间<500ms，错误率<0.1%，持续5分钟。
有了目标，压测才有方向。
第二步：选工具——用什么压？
| 工具 | 适合场景 | 优点 | 缺点 |
|---|---|---|---|
ab (Apache Bench) | 简单单接口压测 | 系统自带，命令简单 | 不支持复杂场景、不支持HTTP/2 |
wrk | 高性能HTTP压测 | 单机并发高、延迟准确 | Lua脚本有一定学习成本 |
JMeter | 复杂业务场景 | 图形化、支持分布式、丰富断言 | 重量级，资源消耗大 |
siege | 简单模拟多用户 | 支持多URL、支持随机延迟 | 并发能力一般 |
选择建议：
- 简单测单接口：
ab或wrk - 模拟真实用户行为（登录→浏览→下单）：
JMeter - 首选
wrk，性能好、延迟数据准确，单机可压几万并发。
第三步：写脚本——模拟真实用户
压测脚本不是随便发几个请求。要模拟真实用户行为：
- 思考时间：用户不会一秒点10次，加随机延迟
- 参数化：每个请求用不同参数（不同商品ID、不同用户）
- 关联：先登录拿token，再用token请求其他接口
JMeter示例：线程组设100线程，循环10次，加随机定时器，用CSV数据文件参数化。
wrk示例（Lua脚本）：
lua
-- 随机生成用户ID
request = function()
local user_id = math.random(1, 100000)
path = "/api/user/" .. user_id
return wrk.format("GET", path)
end
脚本越贴近真实业务，压测结果越可信。
第四步：执行压测——阶梯加压
不要一上来就1000并发。从低到高，阶梯式加压：
| 阶段 | 并发数 | 时长 | 目的 |
|---|---|---|---|
| 1 | 10 | 2分钟 | 验证脚本正确、系统正常 |
| 2 | 50 | 3分钟 | 观察低负载表现 |
| 3 | 100 | 3分钟 | 记录基线数据 |
| 4 | 200 | 3分钟 | 观察变化 |
| 5 | 500 | 3分钟 | 找拐点 |
| 6 | 1000 | 3分钟 | 看极限 |
监控指标：
- 被压服务器：CPU、内存、磁盘I/O、网络、数据库连接数、慢查询
- 压测客户端：CPU、网络（压测客户端本身不能成为瓶颈，建议用多台分布式压测）
发现响应时间突然飙升、错误率增加的点，就是系统的拐点。记录这个并发数作为系统容量上限。
第五步：分析结果——定位瓶颈
压测不是跑完就完事了。看这些指标：
| 指标 | 含义 | 多少算好 |
|---|---|---|
| QPS | 每秒请求数 | 越高越好 |
| P99响应时间 | 99%请求的耗时 | 业务可接受范围内 |
| 错误率 | 失败请求占比 | <0.1% |
| CPU使用率 | 被压服务器 | <80% |
| 内存使用率 | 被压服务器 | <80% |
发现响应时间变长了，怎么判断瓶颈在哪？
| 现象 | 可能瓶颈 | 验证方法 |
|---|---|---|
| CPU高，响应时间长 | CPU不足 | top看CPU使用率 |
| 内存高，有SWAP | 内存不足 | free -h看SWAP |
| 磁盘I/O高 | 磁盘慢或日志太多 | iostat -x 1看%util |
| 数据库连接数满 | 连接池太小 | SHOW PROCESSLIST |
| 网络延迟高 | 带宽不够或网络抖动 | ping、mtr |
反常识点：有时候响应时间变长，被压服务器CPU并不高。可能瓶颈在数据库、下游服务，或者压测客户端本身成了瓶颈。所以被压服务器和压测客户端要一起监控。
第六步：调优——针对瓶颈做优化
找到瓶颈后，针对性调优：
| 瓶颈 | 优化方向 |
|---|---|
| CPU高 | 优化代码（减少循环、加缓存）、升级配置、横向扩容 |
| 内存高 | 排查内存泄漏、调大内存、用Redis卸压 |
| 磁盘I/O高 | 日志异步写入、换SSD、数据库加索引 |
| 数据库慢 | 加索引、读写分离、分库分表 |
| 网络带宽满 | 压缩传输、上CDN、升级带宽 |
调优后，回到第四步，重新压测。验证优化效果。
第七步：出报告——把结果讲清楚
压测报告要能让非技术人员看懂：
- 测试环境：服务器配置、软件版本
- 测试场景：接口、并发阶梯、时长
- 测试结果：最大QPS、P99响应时间拐点、错误率
- 瓶颈分析：哪里先扛不住
- 优化建议：怎么改能扛更高
- 结论：系统能扛多少并发，是否满足业务需求
报告结论示例：
首页接口在500并发下，P99响应时间280ms，错误率0%。600并发时响应时间飙升至1.2s，错误率0.5%。建议将系统容量上限设为500并发，或优化数据库查询后复测。
一个真实案例
一个在线考试系统，上线前压测发现，100用户同时提交答案时，接口响应时间从200ms飙升到5s。分析发现是数据库写入锁竞争。改为批量写入后，同样100并发下响应时间降到300ms。上线当天5000人同时考试，系统稳定。
如果在不上线前发现这个问题，当天可能就是事故。
最后一句
压测不是“跑一下看看”，是一个完整闭环。定目标、选工具、写脚本、阶梯加压、分析瓶颈、调优、复测、出报告。
下次有人问你“服务器能扛多少并发”，你不再需要猜。把压测报告甩给他。