三大压测工具对比：JMeter/Locust/k6

可视化演示

展示JMeter、Locust、k6三大压力测试工具的工作原理，模拟并发请求负载生成与系统性能指标采集过程。

三大工具全家福

你给餐厅做营业压力预演时，三支队伍长相完全不同。宴会厅 JMeter 是 Apache 基金会的“老法师”，打开界面就是树状菜单、线程组、采样器、监听器，像一张巨大的固定菜单，能容纳非常多的业务流程。移动餐车 Locust 的看家本领是把“顾客行为”写成 Python 代码，主厨想改哪一道菜就直接改代码，改完立刻能重新出摊。自动化快闪店 k6 则用 JavaScript 描述点单流程，后厨是 Go 语言打造的流水线，既能快速接单，又能把数据实时投到监控大屏上。

三支队伍虽然风格不同，但服务的都是同一个目标：用可控的并发流量试探系统的“接待上限”。做压测时，我们关心的不是“一共点了多少桌”，而是“每秒能处理多少笔点单”，这就是吞吐量。于是有了最常用的性能指标公式：

回到餐厅比喻：无论你请宴会厅、餐车还是快闪店，最终要回答的都是“每秒能接多少单、每单要等多久、会不会把某道工序堵死”。先认识三支队伍擅长什么，再谈选哪个，才不会在开业当天手忙脚乱。

脚本编写方式

宴会厅的服务员习惯用固定点菜器：经理在 JMeter 图形界面上拖拽线程组、添加 HTTP 采样器、配置断言，最后保存成一个 .jmx 文件。这个文件本质上是 XML，记录了一整棵“组件树”。优点是测试同学不用写代码，鼠标点一点就能跑起来；缺点是文件一复杂，团队协作和版本管理就会头疼。

移动餐车的主厨更喜欢写 Python。Locust 的核心脚本是一个普通 Python 文件，你定义一个继承 HttpUser 的类，用 @task 装饰器标记哪些操作是顾客高频动作。因为本质是代码，所以可以很方便地接入 Git、Code Review 和 CI/CD。

自动化快闪店则用 JavaScript 写场景，k6 的脚本结构非常简洁：import http from 'k6/http' 引入客户端，在 default 函数里写请求行为，再用 options 声明并发数。写起来像写接口测试，读起来也像一份点单流程图。

简单对比三者的脚本方式：JMeter 是“可视化表单 + XML”，适合不喜欢写代码的团队；Locust 是“Python 类与装饰器”，适合后端 Python 开发者；k6 是“JavaScript 函数”，适合前端或全栈工程师。选哪支服务团队，本质上是在选“你们厨房里谁最会读这份菜谱”。

协议支持对比

一家餐厅要服务不同口味的客人：有人用微信扫码点餐，有人直接付现金，还有人用会员卡积分。压测工具也一样，至少要支持被测系统使用的“点餐方式”，也就是网络协议。

JMeter 的开箱协议覆盖最广，HTTP、HTTPS、FTP、JDBC、JMS 都可以通过采样器直接压测。它还可以通过插件扩展更多协议，就像宴会厅准备了从筷子到刀叉的全套餐具。如果企业里有大量历史系统用的是数据库连接、消息队列或老接口，JMeter 常常是最稳妥的选择。

Locust 默认只对 HTTP/HTTPS 提供开箱即用的 HttpUser，但因为是 Python 写的，你可以写自定义客户端来压测 WebSocket、gRPC 或私有 TCP 协议。这有点像移动餐车只带基础厨具，但主厨手艺好，想做什么都能临时搭个灶台。

k6 更聚焦现代 Web 和云原生环境，原生支持 HTTP/1.1、HTTP/2、WebSocket 和 gRPC，和 Kubernetes、微服务架构配合得很顺。快闪店菜单虽然不长，但每道菜都对应现今年轻人最喜欢的口味。选工具前先盘一盘自己的“点餐方式”，协议支持边界就是压测工具的边界。

并发模型与扩展

宴会厅接客的方式很“实在”：每来一桌客人，就安排一个服务员全程跟桌。JMeter 也是这样，一个线程就是一个虚拟用户，线程越多，占用的 JVM 内存越多。假如你想模拟 5000 个并发用户，往往需要启动分布式模式，让多台压测机一起“加桌子”。

移动餐车接客的方式更聪明：一个主厨可以同时照看很多口锅，不用每口锅配一个厨师。Locust 使用 gevent 协程，把大量“等待网络响应”的时间省出来，因此单台机器能模拟的用户数通常比 JMeter 高。不过它跑在 Python 进程里，遇到 CPU 密集型任务时依然受到 GIL 的限制。

k6 的快闪店把出餐流程做成了 Go 的并发流水线，goroutine 非常轻量，单台机器就能撑起很高的虚拟用户数。三种工具的并发模型差异，可以用 Little's Law 来理解：

在团队规模不大、只想快速验证服务上限时，协程和 goroutine 明显更省资源；但如果压测场景复杂、需要兼容大量老协议，宴会厅“人海战术”也有它的安全边界。理解并发模型，你就知道为什么“同样 1000 并发”，不同工具对压测机资源的要求截然不同。

报告与监控

营业预演结束，不能只说“今天接待了很多人”，你还要知道哪条队伍排最长、哪个环节最慢。三支服务团队给出的账单也不一样。

JMeter 最经典的是聚合报告，里面展示每个接口的样本数、平均响应时间、中位数、错误率和吞吐量。你还可以用命令行执行后用 -e -o 生成一份静态 HTML 报告，像宴会厅给你打印一本厚厚的营业报表。

Locust 自带一个 Web 页面，压测过程中实时刷新请求数、响应时间、失败率，还能看到每秒并发用户的曲线。厨师在浏览器里就能看到出餐速度是不是稳。

k6 最擅长和 Grafana 生态联动。它会把指标流式输出到 Prometheus、InfluxDB，或直接对接 Grafana 数据源，天生就适合挂在可视化大屏上。快闪店不仅告诉你结果，还把你带到监控室看实时大盘。

报告的价值不是“好看”，而是帮你定位瓶颈：如果 QPS 曲线一直是平的但延迟在涨，可能说明资源已经打满；如果错误率在某个并发点突然升高，可能说明限流或连接池不够。无论选哪支团队，都要让它把“过程数据”而不是“最终结论”完整交给你。

场景应用选型

周末家庭宴请，你会选宴会厅；街头做快闪活动，你会选移动餐车；科技园区的外卖快闪店，你可能会选自动化 k6。选压测工具不是比参数，而是比“匹配度”。

首先是团队语言：团队熟悉 Python，选 Locust 的维护成本最低；团队熟悉 JavaScript，k6 的脚本几乎没有心智负担；团队主要是测试工程师且不写代码，JMeter 的 GUI 最容易上手。其次是被测系统：老系统用 JDBC、JMS 或 FTP，JMeter 最从容；云原生微服务用 HTTP/2、gRPC，k6 最顺手；混合链路且需要快速自定义协议，Locust 的 Python 扩展最灵活。

最后是压测规模与报告生态：需要分布式压测时，JMeter 主从模式成熟、Locust master/worker 简单、k6 也有云服务和 Kubernetes Operator 可以扩展。需要给老板看大屏，k6 + Grafana 最直观；需要导出 Excel 报表，JMeter 的传统监听器更符合测试团队习惯。

选型之后就要学会定位瓶颈：先用小并发暖场，再阶梯式加压，观察 QPS 增长是否线性、延迟是否突变、错误率是否抬头。正如你不会让宴会厅和快闪店在完全相同的时刻接待同样多的客人，每次压测都要设计好场景数据、用户行为和监控指标。选对工具，只是这场容量规划演练的开始。

---

AI 应用场景

Python 演示

import timeimport urllib.requestfrom concurrent.futures import ThreadPoolExecutor  class MiniLoadTester:    """一个 30 行的迷你压测器, 用来体会 Locust 的并发思想."""     def __init__(self, url, concurrency=20, duration=10):        self.url = url        self.concurrency = concurrency        self.duration = duration        self.success_count = 0        self.error_count = 0     def _send(self, _):        start = time.perf_counter()        try:            urllib.request.urlopen(self.url, timeout=5)            self.success_count += 1        except Exception:            self.error_count += 1        return time.perf_counter() - start     def run(self):        deadline = time.time() + self.duration        latencies = []        with ThreadPoolExecutor(max_workers=self.concurrency) as pool:            while time.time() < deadline:                futures = [                    pool.submit(self._send, i)                    for i in range(self.concurrency)                ]                for future in futures:                    latencies.append(future.result())        total = self.success_count + self.error_count        qps = self.success_count / self.duration        avg_latency = sum(latencies) / max(len(latencies), 1)        return {            "total": total,            "success": self.success_count,            "errors": self.error_count,            "qps": round(qps, 2),            "avg_latency": round(avg_latency, 4),        }  if __name__ == "__main__":    result = MiniLoadTester(        "http://127.0.0.1:8000/health", concurrency=20, duration=5    ).run()    print(result)

1. ThreadPoolExecutor(max_workers=self.concurrency)同时安排 n 个“服务员”并行发请求，模拟并发用户。
2. pool.submit(self._send, i)把每个请求任务投递给空闲线程，类似用户进店后立刻开台。
3. futures = [...]收集这一批请求的 Future 对象，表示所有任务都已派发。
4. for future in futures: latencies.append(future.result())等服务团队全部回单，再统计每笔耗时。
5. qps = self.success_count / self.duration串联第 1 节的 QPS 公式，用成功数除以压测时长。
6. avg_latency = sum(latencies) / max(len(latencies), 1)计算平均响应时间，判断服务是快还是慢。

常见误区

面试题