为什么要进行压力测试
你家楼下有家早餐店，早上七点准时排起长队。老板觉得生意好，想再开一家分店。但他不确定新的店面能不能扛住早高峰的订单量。服务器也是一样，上线新功能、扩容或迁移之前，得知道它到底能承受多大的访问压力。
不做压力测试，系统可能在用户高峰期直接崩溃。比如促销活动开始的一瞬间，页面打不开，订单提交失败，损失的是真金白银。
明确测试目标
别一上来就跑工具。先问自己几个问题：你想测什么？是想看最大并发用户数？还是接口响应时间？或者是系统资源占用情况？
比如你开发了一个商品详情页接口，目标是支持每秒500次访问，响应时间不超过300毫秒。这个就是你的压测目标。有了目标，才知道怎么设计测试场景。
选择合适的工具
市面上有不少现成的工具，选一个顺手的就行。常用的有 JMeter、wrk、ab（Apache Bench）和 Locust。
JMeter 功能全面，适合复杂场景，有图形界面，上手相对容易。比如你要模拟用户登录后再访问订单页面，JMeter 可以设置 Cookie 和请求顺序。
wrk 性能强，轻量，适合高并发测试。用命令行操作，适合放在脚本里自动化执行。
比如用 wrk 测试一个 API 接口：
wrk -t12 -c400 -d30s http://api.example.com/product/123意思是：启动12个线程，保持400个并发连接，持续30秒，压测指定地址。
准备测试环境
别拿生产环境当试验田。最好搭建一个和线上配置接近的测试环境，包括服务器数量、数据库、网络结构等。
如果条件有限，至少保证被测服务单独部署，避免和其他服务争抢资源。就像练车不能直接上高速，得先在封闭场地熟悉操作。
设计测试场景
真实用户不会只访问一个接口。你可以设计多步骤流程，比如：获取首页 → 搜索商品 → 查看详情 → 加入购物车。
在 JMeter 中，可以用“线程组”模拟用户，“HTTP 请求”定义接口调用，“聚合报告”查看结果。
设置并发用户数时，建议从低到高逐步加压。比如先100并发，观察系统表现，再升到300、500，找到性能拐点。
监控系统状态
压测时不能只看外部指标。要同时监控服务器的 CPU、内存、磁盘 IO、网络带宽，还有数据库连接数和慢查询。
比如发现 CPU 跑满但 QPS 上不去，可能是代码里有死循环或算法效率低；如果数据库连接被打爆，就得考虑加连接池或优化 SQL。
Linux 下可以用 top、htop、iostat 实时查看资源使用情况，也可以用 Prometheus + Grafana 做长期监控图表。
分析测试结果
压测结束后，重点看几个数据：平均响应时间、错误率、吞吐量（Requests/sec）、P95/P99 延迟。
如果错误率超过1%，或者响应时间严重超时，说明系统在该负载下不稳定。这时候要回溯日志，查服务有没有报错，中间件有没有超时断连。
比如你发现 P99 响应时间突然从300ms跳到2秒，可能是某个依赖服务在高负载下响应变慢，拖累了整体性能。
优化与再测试
发现问题后，该调优就调优。可能是增加缓存、调整 JVM 参数、拆分大查询、加索引，或者横向扩容服务实例。
改完之后，重新跑一遍压测，验证是否有效。就像修完车得试驾，不能只看仪表盘灯灭了就完事。
压测不是一次性的任务。每次大版本更新、架构调整，都应该重新评估系统承载能力。把它当成常规体检，早发现问题，少出线上事故。