网站压测工具对比的难点，不是把 wrk、k6、Locust 的参数背下来，而是弄清楚它们分别解决什么问题。很多站长在网站上线前只看首页能不能打开，却没有验证 100、500 或 1000 个并发访问下，登录、下单、查询接口会不会变慢。本文会帮助你用更清晰的方式判断：什么时候用 wrk 快速打点，什么时候用 k6 做可复现脚本，什么时候用 Locust 模拟更复杂的用户行为。
如果你正在排查网站性能，建议先把压测目标写成可验证的问题，例如“商品详情页在 300 并发下 P95 响应时间是否低于 800ms”，而不是只说“测一下服务器扛不扛”。这样选择工具时，就能围绕场景、脚本、并发和报告四个维度做判断。
先明确压测目标：吞吐、延迟还是业务流程
压测前最容易犯的错，是一上来就安装工具。正确顺序应该是先定义指标，再选择工具。静态资源、接口吞吐、完整业务路径，对工具能力的要求完全不同。比如只想观察 Nginx 静态页面极限吞吐，wrk 的命令行模式足够轻；如果要把登录、浏览、提交表单串成一条链路，k6 或 Locust 会更合适。
你可以把目标拆成 3 个层次：单接口基线、关键页面链路、真实用户路径。单接口基线关注 requests per second、平均延迟和 P95/P99；关键页面链路需要覆盖首页、列表页、详情页等多个 URL；真实用户路径还要加入 think time、登录态、Cookie 和不同请求比例。对于运行在 VPS（虚拟专用服务器） 或 独立服务器 上的网站，先做基线再做链路测试，能更快区分瓶颈来自应用、数据库还是主机资源。
wrk：适合快速测接口极限，不适合复杂业务
wrk 的优势是轻、快、启动成本低。它基于多线程和事件驱动模型，常见命令只需要指定线程数、连接数、测试时长和 URL。例如下面这条命令，可以用 8 个线程、400 个连接，对某个接口持续压测 60 秒：
wrk --latency -t8 -c400 -d60s https://example.com/api/products
这类测试特别适合建立“单接口基线”。如果压测前后服务器 CPU 从 35% 升到 90%，P95 延迟从 120ms 升到 900ms，你就能快速判断是否需要继续分析应用层、数据库查询或缓存命中率。配合 网站优化 相关排查，wrk 能让问题定位更快进入数据阶段。
但 wrk 的短板也明显。它不适合复杂登录流程，不擅长多步骤场景，报告维度也相对简单。虽然可以写 Lua 脚本扩展请求逻辑，但当测试场景开始涉及动态参数、Token、不同用户行为比例时，维护成本会迅速升高。因此，wrk 更像一把“压力尺”：用来量接口上限很好，用来模拟真实用户旅程就不够自然。
k6：适合团队复用的脚本化压测
k6 更适合需要版本管理、持续集成和团队协作的场景。它使用 JavaScript 编写脚本，可以把虚拟用户数、阶段性增压、断言阈值都放进同一个文件。下面的例子设置了 3 个阶段：30 秒升到 50 个虚拟用户，60 秒保持压力，再用 30 秒降回 0：
export const options = {
stages: [
{ duration: '30s', target: 50 },
{ duration: '60s', target: 50 },
{ duration: '30s', target: 0 },
],
thresholds: {
http_req_duration: ['p(95)<800'],
http_req_failed: ['rate<0.01'],
},
};
k6 的价值在于“可复现”。脚本可以放进 Git，每次代码上线前跑同一套压力曲线；阈值失败时，流水线直接阻塞发布。对于 WordPress、商城或营销站来说，你可以把首页、文章页、搜索页分别写成请求组，并结合 WordPress 主机 的实际运行环境观察缓存、PHP Worker、数据库响应变化。
Locust：适合复杂用户行为和 Python 团队
Locust 使用 Python 描述用户行为，更适合把“人怎么用网站”写进测试脚本。它不是只对一个 URL 重复请求，而是可以定义登录、浏览、搜索、提交等任务，并按权重分配请求比例。例如 70% 的用户浏览详情页，20% 搜索，10% 提交表单，这种模型更接近真实流量。
Locust 的另一个特点是可读性好。Python 团队可以把业务逻辑、随机数据、接口签名、数据库准备动作整合到测试代码里。对于需要测试会员中心、订单流程或多角色权限的网站，Locust 的表达能力通常比 wrk 更自然，也比纯 JavaScript 脚本更容易和后端测试代码复用。
它的代价是环境更重。你需要维护 Python 依赖、分布式 worker、Web UI，以及更完整的测试数据。小网站只测 1 个公开接口时，Locust 可能显得过度；但当你需要模拟 500 个用户在 5 条业务路径之间切换，并观察每条路径的 P95 延迟时，它的优势会体现出来。
三者怎么选：用场景而不是热度决策
下面这组判断可以作为初筛，不必把工具选择变成“谁更高级”的争论：
- 如果目标是 10 分钟内测出单接口吞吐，用 wrk，重点看 RPS、P95、错误率和服务器 CPU。
- 如果目标是每次发布前自动跑同一套脚本，用 k6，重点看 thresholds、阶段压力和 CI 失败条件。
- 如果目标是模拟多角色、多路径用户行为，用 Locust，重点看任务权重、测试数据和分布式 worker。
- 如果团队没有固定测试代码仓库，先用 wrk 建基线，再把稳定场景迁移到 k6 或 Locust。
- 如果压测涉及登录态、Cookie、动态 Token，不要硬用 wrk 扩展脚本，后期维护成本通常更高。
这组选择逻辑也适用于主机方案评估。比如同一个站点在虚拟主机（多用户共享的 Web 主机）上 P95 延迟波动较大，而迁移到云服务器（可弹性分配计算资源的服务器）后更稳定，你仍然需要用同一套脚本复测，避免把缓存预热、访问低峰误判成环境提升。
结果怎么读：不要只盯平均响应时间
压测报告里最容易误导人的指标是平均值。假设平均响应时间是 210ms，但 P99 已经达到 2.8 秒，真实用户仍可能频繁遇到卡顿。我们更建议同时看 4 类数据：吞吐量、P95/P99 延迟、错误率、资源曲线。吞吐量告诉你系统处理能力，延迟分位数反映用户体验，错误率说明稳定性，资源曲线帮助定位瓶颈。
如果错误率从 0.1% 升到 5%，先不要急着换工具。你需要检查应用日志、数据库慢查询、Web 服务连接数、系统文件描述符上限，以及网络带宽（单位时间内可传输的数据量）是否触顶。涉及 DNS（域名解析系统）、SSL（安全传输协议）握手或 CDN（内容分发网络）缓存时，还要把首包时间、回源比例和证书协商耗时分开看，否则很容易把网络层问题误认为应用代码问题。
对外贸站或内容站来说，压测还要避开生产高峰，并设置明确边界。比如先从 50 并发开始，每 5 分钟升一级，到 300 并发后停止观察；每轮测试记录时间、版本号、服务器规格、缓存策略和数据库配置。后续如果更换 Hostease 的主机方案或调整缓存插件，就能用同一份记录做横向比较，而不是凭体感判断“好像快了”。
推荐流程：从轻量基线到业务压测
比较稳妥的流程是三步走。第一步，用 wrk 对首页、列表页和 1 个核心接口建立 60 秒基线，记录 RPS、P95、错误率和 CPU 峰值。第二步，用 k6 把关键页面写成脚本，设置 3 到 5 个压力阶段，并把 P95 小于 800ms、错误率低于 1% 写成阈值。第三步，如果业务路径复杂，再用 Locust 模拟真实用户权重，重点观察登录、搜索、提交等动作的分布式表现。
在执行层面，每轮压测都应该保留一份“环境快照”：代码版本、缓存状态、数据库数据量、服务器规格、测试地区、测试时长。没有这些上下文，两个报告即使数字不同，也很难证明是优化有效、流量路径变化，还是测试环境不一致。
总结：先问要验证什么，再决定用哪把尺
总结来看，wrk 适合快速、直接、低成本的接口基线；k6 适合可复现、可纳入发布流程的脚本化压测；Locust 适合复杂业务路径和 Python 团队维护的用户行为模型。三者不是替代关系，而是覆盖不同阶段：先用轻工具发现边界，再用脚本固定标准，最后用业务模型验证真实访问路径。
如果你需要为线上网站做压测，我们建议先从 2 到 3 个关键页面开始，不要一次覆盖全站。把目标写成“P95 小于多少、错误率低于多少、并发阶梯如何变化”，再选择工具。对于准备迁移、扩容或优化缓存的站点，也可以结合 服务器性能 与 虚拟主机 场景评估，先用数据确认瓶颈，再决定是否升级配置、拆分数据库或调整缓存策略。这样得到的结论更可靠，也更容易在下一次发布前复用。