locust压测golang微服务tps更高，因其gevent协程与go非阻塞io模型匹配，调度开销低；jmeter默认线程模型易在高并发下因os线程耗尽导致假瓶颈，需关闭keep-alive、禁用冗余监听器并精准对齐pprof采样窗口。
Locust 和 JMeter 都能压测 Golang 微服务，但选哪个，取决于你压的是什么、谁来写脚本、以及你关心的瓶颈在哪——不是并发数字越大越好，而是数据能不能帮你定位到 http.Server 的 ReadTimeout 设置不合理，或者 goroutine 泄漏。
为什么 Locust 压 Golang 服务时 TPS 反而更高？
关键在 IO 模型匹配：Golang HTTP 服务默认用非阻塞网络模型，而 Locust 的 gevent 协程也是非阻塞的，两者在高并发短连接场景下调度开销低；JMeter 的每个线程都独占一个 OS 线程，当并发超过 2000，runtime.GOMAXPROCS 和 JVM 线程栈会快速吃光内存和 CPU 调度资源。
实操建议：
- 若压测目标是单个
gin或echo接口，且请求体小、响应快（如 JSON ping），Locust 更易打满网卡或服务端net.Conn数量上限 - JMeter 在这种场景下容易出现“假瓶颈”：比如
java.lang.OutOfMemoryError: unable to create new native thread，其实是压测机扛不住了，不是服务不行 - 别信“Locust 性能差”的旧结论——那是没关日志、没换
FastHttpUser、没调GEVENT_MONKEY_PATCH的配置
JMeter 压 Golang 微服务时，哪些配置必须改？
默认配置下，JMeter 对 Golang 服务的压测结果严重失真：它会复用连接（keep-alive），而很多 Golang 服务在反向代理（如 Nginx）后默认关闭长连接，导致大量 Connection reset 错误。
实操建议：
- HTTP 请求采样器中，勾选
Use keepAlive→ 改为 不勾选，强制每请求新建连接 - 线程组设置里，把
Thread Group的Same user on each iteration?设为false，避免 Cookie/Session 复用干扰 - 添加
JSR223 PreProcessor，用 Groovy 动态生成唯一X-Request-ID，方便在 Golang 日志里追踪链路 - 禁用所有监听器（尤其是
View Results Tree），否则 JVM GC 会拖慢吞吐，掩盖真实服务延迟
要验证 Golang 的 pprof 数据，该用哪个工具采集？
Locust 的实时指标流（/stats/responses）和 JMeter 的 Backend Listener 都能推数据，但对 Golang 服务而言，真正关键的是你能把压测流量和 http://localhost:6060/debug/pprof/goroutine?debug=2 的堆栈快照对齐。
实操建议：
- Locust 场景下，在
@task方法里加time.sleep(0.1)模拟思考时间，避免协程密集打点，否则pprof里全是runtime.selectgo栈帧，看不出业务瓶颈 - JMeter 场景下，用
JSR223 Timer插入随机 delay，再配合__time()函数记录压测起始时间戳，便于和 Golangpprof时间窗口对齐 - 无论用哪个工具，压测前务必在 Golang 启动参数加
-gcflags="-m -m"观察逃逸分析，避免压测时因频繁堆分配放大 GC 压力
真正难的不是跑出高 TPS，而是让压测流量像真实用户一样“呼吸”——有间隔、有失败重试、有 header 差异、有 body 随机性。Locust 写起来快，但得懂 Python 和协程生命周期；JMeter 配置多，但团队里没写过代码的人也能调参。别被“分布式”“协程”这些词带偏，先看你的 Golang 服务是不是开了 http.Server.ReadTimeout，再决定用哪个工具去撞它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
