网站压力测试工具

去年双十一前夜，网站我们团队负责的压力电商后台突然崩了。凌晨两点，测试运维群里炸开锅——CPU飙到98%，工具数据库连接池爆满，网站用户下单页面转圈转到天荒地老。压力事后复盘，测试问题出在一个没做压力测试的工具新促销接口上。如果提前用工具模拟过峰值流量，网站这场事故完全可以避免。压力

压力测试工具干的测试事很直接：用机器模拟成千上万个用户同时捶打你的网站，看它什么时候扛不住、工具哪里先跪。网站这跟请一群人来家里开派对差不多——门能进多少人，压力厕所会不会堵，测试厨房够不够用，试过才知道。

主流工具，各有用武之地

JMeter 是绕不开的老牌选手。Apache 出品，Java 写的，界面丑但功能全。它能测 HTTP、FTP、数据库、消息队列，插件生态也丰富。我见过有人拿它压测到单机模拟五万并发——当然，得调优 JVM 参数，不然先崩的是 JMeter 自己。缺点是 GUI 模式吃内存，正式压测得用命令行跑。

Locust 走的是另一条路。Python 写脚本，用协程扛并发，一台机器能撑的并发数比 JMeter 高不少。代码长这样：

from locust import HttpUser, task class ApiUser(HttpUser): @task def get_products(self): self.client.get("/api/products")

写起来清爽，分布式部署也方便。但 Python 的 GIL 限制在那儿，真要压到十万级并发，得多台 worker 一起上。

k6 是近几年冒出来的新秀。Go 语言写的，单二进制文件，脚本用 JavaScript。启动快，资源占用低，CI/CD 里跑起来很顺。我们现在的流水线里就挂了个 k6 脚本，每次发版前自动跑一轮基准测试，超过阈值直接卡住不让上线。它的输出报告也好看，终端里直接出柱状图和百分位数据。

还有 wrk、ab 这类轻量级工具，适合快速验证单个接口的极限 QPS。ab 是 Apache 自带的，参数简单，但只支持 HTTP/1.0，测长连接场景不太准。wrk 支持 Lua 脚本，能发 HTTP/1.1 和 pipelining 请求，压静态资源很猛。

选工具，看场景

如果只是测个 REST API 的吞吐量，k6 或 wrk 足够。要做复杂的业务流程编排——比如登录、加购、下单、支付串起来跑——JMeter 或 Locust 更合适。团队里没人会写代码，那就 JMeter 的 GUI 拖拽最省事。追求高并发和低资源消耗，Locust 和 k6 是首选。

有个坑得提一句：压力测试工具本身也会消耗资源。用 JMeter GUI 模式压测，经常是工具先 OOM，被测服务还没啥感觉。正经压测一律用命令行模式，或者分布式部署，把压力机和服务器的资源隔离开。

指标比工具重要

工具只是手段，关键看你怎么解读数据。TPS、响应时间、错误率、P99 延迟——这些数字背后对应的是用户体验。我们内部有个粗暴的标准：核心接口 P99 超过 500ms 就算不合格。压测时盯着这个数，比看平均响应时间有用得多。平均值会骗人，一个 10 秒的慢请求能拉高整体均值，但 P99 能帮你抓住那些让用户骂娘的极端情况。

另外，压测环境尽量贴近生产。数据库数据量、缓存命中率、网络延迟，差一点结果就天差地别。我们曾经在测试环境压出 8000 TPS，上线后实际只跑到 3000，就是因为测试库只有几万条数据，生产库几千万条，SQL 执行计划完全不同。

工具选对了，指标看准了，剩下的就是反复调优、反复压。没有一次压测就能搞定的系统，就像没有一次健身就能练出的腹肌。