压测工具选型：JMeter、Locust、Gatling、wrk、ab、k6对比与决策矩阵

做性能压测这么多年，我经常被问到同一个问题：「到底该用哪个工具？」

说实话，没有银弹。每个工具都有自己的脾气。我见过有人用JMeter压出漂亮报告，也见过有人用wrk几行命令就搞定问题。关键是你得知道——什么场景下，该用哪把刀。

一、先看全景：六款工具一句话定位

在深入对比之前，我先给你一张全景图。这是我个人习惯的梳理方式——先看定位，再看细节。

二、逐个拆解：六款工具的实战体验

1. JMeter —— 老牌劲旅，功能最全

JMeter是我入行时用的第一个工具。说实话，它的界面确实有点「复古」，但功能是真的扎实。你想想看，一个工具能活十几年还在更新，肯定有它的道理。

核心优势：

支持几乎所有的协议：HTTP、HTTPS、JDBC、JMS、FTP……你能想到的它基本都有
图形化界面，拖拽式构建测试计划，适合非开发人员
插件生态极其丰富，从报告生成到分布式压测都有现成方案

我踩过的坑：

⚠️ 我曾经在一次压测中，用JMeter压2000并发，结果压测机自己先挂了。后来才发现——JMeter每个虚拟用户就是一个线程，2000个线程在JVM里可不是闹着玩的。建议单机不要超过1000并发，否则就用分布式模式。

2. Locust —— Python党的最爱

如果你团队里都是Python开发者，Locust绝对是首选。它的设计理念很优雅——用Python代码定义用户行为，而不是用XML或JSON配置。

# 一个简单的Locust脚本示例
from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 5)
    
    @task(3)
    def view_home(self):
        self.client.get("/")
    
    @task(1)
    def search(self):
        self.client.post("/search", json={"q": "性能测试"})

我个人习惯用Locust做复杂业务场景的压测。比如模拟用户先登录、再浏览、再下单——用Python写起来非常自然。

💡 小技巧：Locust的Web UI可以实时调整并发数，不用重启压测。这在调试阶段特别有用。

3. Gatling —— 高性能的Scala选手

Gatling给我的第一印象是「报告真好看」。它的HTML报告是六款工具里最精美的，图表、统计、响应时间分布一目了然。

但要注意——Gatling用Scala DSL写脚本。如果你团队没有Scala基础，学习成本会比较高。我建议：如果你们做的是长期、正式的压测项目，Gatling值得投入。

4. wrk —— 极简主义者的利器

wrk是我做快速验证时的首选。一条命令就能压起来：

wrk -t12 -c400 -d30s http://target.com/api

什么意思？12个线程、400个连接、持续30秒。就这么简单。

但wrk有个硬伤：它只支持HTTP协议，而且不能做复杂的业务逻辑。说白了，它就是一把「手术刀」——精准、快速，但功能单一。

🔑 适用场景：接口调优、容量评估、快速对比。我经常用它来验证代码改动前后的性能差异。

5. ab (Apache Bench) —— 最古老，也最基础

ab是Apache自带的压测工具，几乎每个Linux系统都预装了。它的命令比wrk还简单：

ab -n 10000 -c 100 http://target.com/

嗯，这里要注意——ab的并发模型比较原始，高并发下结果可能不准。我一般只用它做「能不能通」的验证，不会用它做正式的性能评估。

6. k6 —— 为云原生而生的新秀

k6是我最近两年用得越来越多的工具。它用JavaScript写脚本，天然适合前端/全栈工程师。而且它跟CI/CD集成得特别好——Jenkins、GitLab CI、GitHub Actions都有现成插件。

// k6脚本示例
import http from 'k6/http';
import { sleep } from 'k6';

export default function () {
  http.get('https://test.k6.io');
  sleep(1);
}

export const options = {
  vus: 10,
  duration: '30s',
};

我个人觉得k6最大的亮点是资源消耗极低。同样的并发数，k6占用的内存只有JMeter的十分之一。这在云上跑压测时，成本优势非常明显。

三、选型决策矩阵

说了这么多，到底怎么选？我整理了一个决策矩阵，你直接对着看就行：

选型维度	JMeter	Locust	Gatling	wrk	ab	k6
学习成本	中等	低（需Python）	高（需Scala）	极低	极低	低（需JS）
并发能力	中等（线程模型）	高（协程）	高（Akka）	极高（事件驱动）	低	极高（Go协程）
协议支持	★★★★★	★★★☆☆	★★★★☆	★☆☆☆☆	★☆☆☆☆	★★★☆☆
报告质量	★★★★☆	★★★☆☆	★★★★★	★★☆☆☆	★☆☆☆☆	★★★★☆
CI/CD集成	★★★☆☆	★★★★☆	★★★★☆	★★☆☆☆	★★☆☆☆	★★★★★
资源消耗	高	低	中	极低	低	极低
分布式支持	原生支持	原生支持	原生支持	需第三方	不支持	云原生

四、我的选型建议

根据我这些年的实战经验，给你几条「拿来就能用」的建议：

快速验证、单接口调优 → 用wrk或ab。别折腾，一条命令搞定。
复杂业务流程、多协议 → 用JMeter。虽然重，但稳。
团队是Python栈、需要灵活脚本 → 用Locust。写代码比拖拽快多了。
CI/CD流水线、云原生环境 → 用k6。资源省、集成好、报告也漂亮。
正式的性能验收、需要给老板看报告 → 用Gatling。那报告一出，谁看了都得说专业。

🔑 最后说一句：工具只是手段，不是目的。我见过有人用ab也能发现严重的性能问题，也见过有人用JMeter压了半天结果场景设计错了。选对工具很重要，但更重要的是——你知不知道自己在压什么、为什么压、结果怎么分析。

嗯，这一章就到这里。工具选型这块，你心里有数了吗？

📚 课程目录

压测工具选型：JMeter、Locust、Gatling、wrk、ab、k6对比与决策矩阵

一、先看全景：六款工具一句话定位

二、逐个拆解：六款工具的实战体验

1. JMeter —— 老牌劲旅，功能最全

2. Locust —— Python党的最爱

3. Gatling —— 高性能的Scala选手

4. wrk —— 极简主义者的利器

5. ab (Apache Bench) —— 最古老，也最基础

6. k6 —— 为云原生而生的新秀

三、选型决策矩阵

四、我的选型建议