性能测试这件事说到底是给系统上强度之前的一次全面体检。我做了十多年测试见过太多团队在压测工具选型上反复横跳有人抱着 JMeter 不放有人一窝蜂转向 k6还有人用 Locust 写了几千行 Python 脚本最后发现维护成本比业务代码还高。工具本身没有绝对的好坏关键在于它跟你的团队技术栈、压测场景、报告需求是否匹配。这篇盘点把 2026 年市面上 13 款主流压测工具拉出来逐个拆解从协议支持、脚本编写方式、分布式能力、报告可视化到实际踩坑点尽量讲透。不管你是刚接触性能测试的新人还是正在做工具迁移决策的资深工程师都能从中找到适合自己的那一款。1. 选压测工具之前先搞清楚你在压什么很多人一上来就问哪个工具最好用这个问题本身就问错了。压测工具的选择取决于你要压什么、谁来写脚本、报告给谁看。我见过一个团队用 JMeter 压 gRPC 接口折腾了两周插件最后还是换了工具也见过有人用 k6 压一个需要复杂前置数据构造的业务流脚本写到怀疑人生。所以先花几分钟把下面几个维度想清楚比盲目对比工具参数有用得多。1.1 协议覆盖范围决定了工具的下限压测工具支持的协议种类直接决定了它能不能用在你的项目上。HTTP/HTTPS 是最基础的几乎所有工具都支持。但一旦涉及 gRPC、WebSocket、MQTT、Dubbo、Thrift 这些协议可选范围就大幅缩小了。JMeter 靠插件生态覆盖了大部分协议但插件质量参差不齐有些插件几年没更新了。k6 原生支持 HTTP、WebSocket、gRPC扩展性靠 Go 编写的扩展模块。Locust 基于 Python 的 requests 库理论上只要 Python 能调的协议它都能压但需要自己封装。Gatling 原生支持 HTTP、WebSocket、SSE对 gRPC 的支持还在完善中。实操建议如果你的系统涉及多种协议混合压测优先考虑 JMeter 或 Locust它们的扩展成本相对可控。如果只压 HTTP 接口k6 和 Gatling 的体验会更好。1.2 脚本编写方式决定了团队的上手成本脚本编写方式是选型时最容易被低估的因素。JMeter 用 GUI 拖拽元件上手快但复杂场景维护困难k6 用 JavaScript 写脚本对前端背景的测试人员友好Locust 用 Python适合有开发能力的团队Gatling 用 Scala DSL学习曲线陡但表达能力强。我个人的经验是如果团队里测试人员以功能测试转岗为主JMeter 的 GUI 模式能让他们快速出活如果团队有专职性能测试开发代码化工具k6、Locust、Gatling在版本管理和 CI 集成上优势明显。别小看这个差异我见过一个团队强行让功能测试人员写 Locust 脚本结果每次需求变更都要找开发帮忙改脚本效率反而更低。1.3 报告能力决定了压测结果能不能说服人压测做完了报告是给谁看的给开发看需要详细的响应时间分布、错误率、吞吐量曲线给领导看需要简洁的结论和对比数据给运维看需要资源占用和瓶颈定位信息。JMeter 的 HTML 报告模板经过多年迭代已经比较完善但默认样式确实不太好看社区有汉化模板可以替换。k6 的报告输出比较简洁适合 CI 流水线里快速判断通过与否深度分析需要配合 Grafana 等工具。Gatling 的报告是公认最好看的自带响应时间分布图和请求链路分析。Locust 的 Web UI 实时性好但历史报告需要自己对接存储。2. 13 款主流压测工具逐个拆解下面按工具类型分组逐个讲清楚每款工具的核心特点、适用场景和实际使用中的坑。分组不是绝对的有些工具跨类别我按主要使用方式来归类。2.1 JMeter绕不开的行业基准JMeter 是 Apache 基金会的开源项目Java 编写跨平台运行。它的核心优势是生态成熟、资料丰富、插件众多。你遇到的大部分压测需求网上都能找到现成的解决方案。安装配置这块JMeter 需要先装 JDK推荐 JDK 8 或 JDK 11JDK 17 以上部分插件兼容性有问题。下载官方二进制包解压后配置JMETER_HOME环境变量把bin目录加入PATH就能用。Windows 下双击jmeter.batLinux/Mac 下执行jmeter.sh。内存不够的话改bin/jmeter文件里的HEAP参数默认 1G 压高并发容易 OOM。脚本编写方面JMeter 的元件体系包括线程组、取样器、逻辑控制器、断言、监听器等。一个典型的压测脚本结构是线程组设置并发数和循环次数HTTP 请求取样器配置接口地址和参数响应断言校验返回结果聚合报告收集数据。!-- JMeter 线程组配置示例 -- ThreadGroup stringProp nameThreadGroup.num_threads100/stringProp stringProp nameThreadGroup.ramp_time10/stringProp boolProp nameThreadGroup.schedulertrue/boolProp stringProp nameThreadGroup.duration300/stringProp /ThreadGroupBeanShell 断言是 JMeter 里用得最多的脚本断言方式可以写 Java 代码校验响应。比如校验返回 JSON 里某个字段的值// BeanShell 断言示例 import org.json.JSONObject; String response prev.getResponseDataAsString(); JSONObject json new JSONObject(response); if (json.getInt(code) ! 200) { Failure true; FailureMessage 返回码不是200实际为 json.getInt(code); }While 控制器配合条件判断可以实现轮询等待场景比如提交任务后不断查询状态直到完成。动态调整 QPS可以通过 Constant Throughput Timer 或者用 BeanShell 脚本动态修改线程数来实现后者更灵活但需要小心线程安全问题。上传文件场景用 HTTP 请求里的文件上传选项卡注意勾选Use multipart/form-data。录制 HTTPS 脚本需要先配置 JMeter 的代理和证书在浏览器里导入 JMeter 的 CA 证书后就能录制。Cookie 管理用 HTTP Cookie Manager 元件可以自动管理会话也可以手动添加固定 Cookie。分布式压测是 JMeter 的强项一台 master 控制多台 slave 就能突破单机并发限制。配置时注意 slave 机器的 JMeter 版本要一致防火墙要放行 1099 和 50000 端口。踩坑提醒JMeter GUI 模式只用来写脚本和调试真正压测必须用命令行模式jmeter -n -t script.jmx -l result.jtl -e -o report否则 GUI 本身会消耗大量资源影响压测结果。2.2 k6为 CI/CD 而生的现代压测工具k6 是 Grafana Labs 维护的开源工具用 Go 编写脚本用 JavaScript。它的设计理念就是测试即代码非常适合集成到 CI/CD 流水线里。k6 的脚本结构很清晰一个典型的 HTTP 压测脚本长这样import http from k6/http; import { check, sleep } from k6; export const options { stages: [ { duration: 30s, target: 50 }, { duration: 1m, target: 100 }, { duration: 30s, target: 0 }, ], thresholds: { http_req_duration: [p(95)500], http_req_failed: [rate0.01], }, }; export default function () { const res http.get(https://api.example.com/users); check(res, { status is 200: (r) r.status 200, response time 500ms: (r) r.timings.duration 500, }); sleep(1); }k6 的thresholds机制是它的一大亮点可以直接在脚本里定义性能门槛CI 流水线里跑完自动判断通过还是失败不需要人工看报告。stages配置支持阶梯式加压模拟真实流量爬坡场景。k6 的分布式能力相对弱一些官方推荐用 k6 Operator 在 Kubernetes 里跑分布式压测配置门槛比 JMeter 高。但单机性能很强一台 8 核 16G 的机器跑几千并发问题不大。实操心得k6 的sleep(1)是模拟用户思考时间但要注意它不占用 VU 资源。如果你需要精确控制请求间隔用sleep就够了如果需要控制每秒请求数得用constant-arrival-rate执行器。2.3 LocustPython 技术栈的首选Locust 是开源 Python 压测工具最大特点是脚本用纯 Python 写扩展性极强。如果你的团队 Python 技术栈为主Locust 几乎是自然选择。Locust 的脚本核心是定义用户行为from locust import HttpUser, task, between class WebsiteUser(HttpUser): wait_time between(1, 3) def on_start(self): self.client.post(/login, json{username: test, password: 123456}) task(3) def view_items(self): self.client.get(/items) task(1) def create_order(self): self.client.post(/orders, json{item_id: 1, quantity: 2})task(3)里的数字是权重表示这个任务被执行的概率是另一个的 3 倍。wait_time控制用户思考时间。on_start在每个用户启动时执行一次适合做登录等前置操作。Locust 的Web UI实时性很好能看到实时 RPS、响应时间、失败率曲线。分布式模式下一台 master 加多台 worker通过--master和--worker参数启动。Locust 的坑主要在性能上Python 的 GIL 限制了单进程的并发能力高并发场景需要开多个 worker 进程。另外 Locust 的 HTTP 客户端基于 requests 库连接池配置不当容易出现端口耗尽问题。2.4 Gatling报告最漂亮的压测工具Gatling 是法国公司开源的压测工具基于 Scala 和 Akka 构建后来推出了 Java DSL。它的报告是公认最好看的自带响应时间分布图、请求链路瀑布图、活跃用户曲线。Gatling 的 Java DSL 脚本示例public class BasicSimulation extends Simulation { HttpProtocolBuilder httpProtocol http .baseUrl(https://api.example.com) .acceptHeader(application/json); ScenarioBuilder scn scenario(BasicScenario) .exec(http(GetUsers) .get(/users) .check(status().is(200))) .pause(1); { setUp( scn.injectOpen( rampUsers(100).during(Duration.ofSeconds(30)), constantUsersPerSec(20).during(Duration.ofMinutes(2)) ) ).protocols(httpProtocol); } }Gatling 的injection模型比 JMeter 的线程组更灵活支持多种加压策略组合。checks机制类似断言可以校验响应状态、内容、响应时间等。Gatling 的分布式能力靠 Gatling Enterprise商业版或者自己用 Docker 编排。开源版单机性能不错但报告生成会消耗较多内存压测机配置要够。2.5 wrk 和 wrk2轻量级 HTTP 压测利器wrk 是用 C 写的轻量级 HTTP 压测工具单机性能极强适合快速验证接口吞吐量。wrk2 是 wrk 的改进版修正了 wrk 的延迟统计问题能输出更准确的延迟分布。wrk 的基本用法wrk -t12 -c400 -d30s --latency https://api.example.com/users-t12是 12 个线程-c400是 400 个连接-d30s压 30 秒--latency输出延迟统计。wrk 支持 Lua 脚本扩展可以自定义请求和校验逻辑。wrk 的局限很明显只支持 HTTP不支持复杂场景编排报告只有命令行输出。它适合做接口级别的快速压测不适合做端到端的业务流压测。2.6 ab最古老的压测工具abApacheBench是 Apache 自带的压测工具几乎每台 Linux 机器上都有。用法极其简单ab -n 10000 -c 100 https://api.example.com/users-n是总请求数-c是并发数。ab 的优点是零依赖、上手快缺点是只支持 HTTP/1.0不支持 Keep-Alive压测结果偏悲观。它适合做最简单的接口验证正式压测不建议用。2.7 VegetaGo 编写的命令行压测工具Vegeta 是 Go 编写的 HTTP 压测工具命令行操作支持恒定速率压测。它的特点是能精确控制每秒请求数适合做稳定性测试。echo GET https://api.example.com/users | vegeta attack -rate100 -duration30s | vegeta reportVegeta 支持多种输出格式包括 JSON、CSV、HTML 图表。它的-rate参数控制每秒请求数比 JMeter 的线程模型更直观。2.8 Tsung老牌多协议压测工具Tsung 是 Erlang 编写的开源压测工具支持 HTTP、WebSocket、MQTT、XMPP 等多种协议。它的分布式能力很强单集群可以模拟百万级并发。Tsung 的配置用 XML 文件学习曲线较陡。它的报告是 HTML 格式包含详细的统计图表。Tsung 的社区活跃度不如 JMeter资料相对少一些。2.9 ArtilleryNode.js 生态的压测工具Artillery 是 Node.js 编写的压测工具脚本用 YAML 或 JavaScript。它的特点是上手快、报告清晰适合 Node.js 技术栈的团队。config: target: https://api.example.com phases: - duration: 60 arrivalRate: 10 scenarios: - flow: - get: url: /users - think: 1Artillery 支持插件扩展可以对接 Datadog、New Relic 等监控平台。它的分布式能力靠 Artillery Pro商业版。2.10 Siege简单直接的压测工具Siege 是 C 编写的 HTTP 压测工具用法简单支持基本的认证和 Cookie。它的特点是配置简单适合快速验证。siege -c 100 -t 30s https://api.example.com/usersSiege 的报告比较基础只有请求数、成功率、响应时间等核心指标。它适合做简单的负载验证复杂场景支持有限。2.11 Locust4jJava 版的 LocustLocust4j 是把 Locust 的核心理念用 Java 重新实现的版本适合 Java 技术栈团队。它的 API 设计跟 Locust 类似但生态和资料远不如原版 Locust。2.12 NeoLoad商业压测工具的代表NeoLoad 是 Tricentis 旗下的商业压测工具提供 GUI 脚本录制、分布式压测、实时监控、AI 辅助分析等功能。它的优势是开箱即用、技术支持完善缺点是价格不菲。NeoLoad 适合预算充足、需要快速上手的企业团队。它的报告和监控集成做得很好能直接对接 APM 工具定位瓶颈。2.13 LoadRunner老牌商业压测工具LoadRunner 是 Micro Focus 旗下的商业压测工具历史悠久功能全面。它支持几乎所有主流协议分布式能力强报告详细。缺点是笨重、价格高、学习曲线陡。LoadRunner 在金融、电信等传统行业还有大量存量用户但互联网公司用得越来越少。3. 工具选型的决策框架和对比表讲了这么多工具到底怎么选我总结了一个决策框架按优先级排序第一步确定协议需求。只压 HTTP 的话选择面很宽涉及 gRPC、WebSocket 等协议优先考虑 JMeter、k6、Locust。第二步确定团队技术栈。Java 团队选 JMeter 或 GatlingPython 团队选 LocustNode.js 团队选 k6 或 Artillery不想写代码选 JMeter GUI 或商业工具。第三步确定集成需求。要进 CI/CD 流水线优先 k6、Gatling、Locust要跟监控平台对接看工具的插件生态。第四步确定预算。开源工具免费但需要自己维护商业工具省心但价格高。下面这张对比表把 13 款工具的核心维度拉平了看工具脚本语言协议支持分布式报告能力上手难度适用场景JMeterGUI/Java极广强中低通用压测k6JavaScriptHTTP/WS/gRPC中中中CI/CD 集成LocustPython依赖库强中中Python 团队GatlingScala/JavaHTTP/WS中强高报告要求高wrk/wrk2LuaHTTP弱弱低接口快速压测ab无HTTP弱弱低简单验证Vegeta无HTTP弱中低恒定速率压测TsungXML多协议强中高多协议大规模ArtilleryYAML/JSHTTP/WS中中低Node.js 团队Siege无HTTP弱弱低简单负载Locust4jJava依赖库中中中Java 团队NeoLoadGUI广强强低企业商业LoadRunnerGUI/脚本极广强强高传统行业选型提醒不要只看工具本身还要看社区活跃度和资料丰富度。JMeter 和 k6 的社区最活跃遇到问题容易找到答案一些小众工具出问题只能自己啃源码。4. 从零搭建一次压测的完整流程工具选好了接下来讲怎么从零跑通一次完整的压测。我以 JMeter 为例因为它的流程最典型其他工具的思路类似。4.1 环境准备和脚本编写先装 JDK再装 JMeter。JDK 版本建议 8 或 11装完后java -version验证。JMeter 解压后配置环境变量命令行执行jmeter -v能看到版本信息就说明装好了。脚本编写在 GUI 里进行。新建测试计划添加线程组设置并发数、ramp-up 时间、循环次数。添加 HTTP 请求默认值元件配置服务器地址和端口。添加 HTTP 请求取样器配置接口路径和方法。添加响应断言校验返回状态码。添加聚合报告和查看结果树监听器方便调试。调试阶段先用 1 个并发跑一遍确认接口能通、断言能过。然后逐步增加并发观察响应时间和错误率变化。4.2 参数化和关联处理真实压测需要模拟不同用户这就涉及参数化。JMeter 用 CSV Data Set Config 元件读取 CSV 文件把用户名、密码等数据参数化。文件路径建议用相对路径方便脚本迁移。关联处理是指从上一个请求的响应里提取数据传给下一个请求。比如登录后拿到 token后续请求都要带上。JMeter 用 JSON Extractor 或正则表达式提取器实现。!-- JSON Extractor 配置示例 -- JSONPostProcessor stringProp nameJSONPostProcessor.referenceNamestoken/stringProp stringProp nameJSONPostProcessor.jsonPathExprs$.data.token/stringProp stringProp nameJSONPostProcessor.match_numbers1/stringProp /JSONPostProcessor提取到的 token 用${token}在后续请求里引用。4.3 命令行压测和报告生成脚本调试好后用命令行模式压测jmeter -n -t test.jmx -l result.jtl -e -o report-n非 GUI 模式-t指定脚本-l指定结果文件-e压测后生成报告-o指定报告输出目录。报告目录必须为空否则会报错。生成的 HTML 报告包含响应时间分布、吞吐量曲线、错误率统计等。默认报告是英文的社区有汉化模板可以替换bin/report-template目录下的文件。4.4 分布式压测配置单机压不够就上分布式。master 机器上改jmeter.properties里的remote_hosts配置写上所有 slave 的 IP 和端口。slave 机器上启动jmeter-server。master 执行jmeter -n -t test.jmx -R slave1_ip,slave2_ip -l result.jtl-R指定 slave 列表。压测结果会汇总到 master 的结果文件里。分布式踩坑slave 机器的 JMeter 版本必须和 master 一致JDK 版本也要一致。CSV 参数文件要手动同步到每台 slaveJMeter 不会自动分发。网络延迟会影响压测结果slave 和被测系统尽量在同一内网。5. 压测中那些文档不会告诉你的坑这部分是我这些年踩过的坑文档里基本不会写但实际压测中经常遇到。5.1 端口耗尽和 TIME_WAIT 堆积高并发压测时压测机容易出现端口耗尽。Linux 默认的本地端口范围是 32768 到 60999大概 28000 个端口。如果每个请求都新建连接几万请求就能把端口用完。解决办法是调整内核参数# 扩大本地端口范围 sysctl -w net.ipv4.ip_local_port_range1024 65535 # 开启 TIME_WAIT 重用 sysctl -w net.ipv4.tcp_tw_reuse1 # 减少 TIME_WAIT 时间 sysctl -w net.ipv4.tcp_fin_timeout30JMeter 这边要开启 Keep-Alive在 HTTP 请求里勾选Use KeepAlive减少连接创建次数。5.2 压测机自身成为瓶颈压测机 CPU 跑满、内存不够、网络带宽打满都会导致压测结果失真。压测前先用top、free、iftop看看压测机资源。JMeter 的 GUI 模式特别吃资源正式压测一定用命令行。判断压测机是否是瓶颈有个简单方法看压测机的 CPU 使用率。如果压测机 CPU 超过 80%而被测系统 CPU 很低那瓶颈很可能在压测机这边。5.3 断言写太复杂拖慢压测JMeter 的断言是在压测线程里执行的断言逻辑太复杂会拖慢压测速度。BeanShell 断言性能尤其差因为它每次都要编译执行。能用 JSON 断言就用 JSON 断言能用响应断言就用响应断言实在不行再用 JSR223 断言配合 Groovy 脚本。5.4 报告里的响应时间到底看哪个JMeter 聚合报告里有平均值、中位数、90% 线、95% 线、99% 线、最大值、最小值。平均值容易被极端值拉偏参考价值有限。我一般重点看 95% 线和 99% 线这两个指标更能反映大多数用户的体验。如果 95% 线是 200ms99% 线是 2s说明有 1% 的请求特别慢需要重点排查。这种长尾问题往往比平均响应时间更值得关注。5.5 压测环境和生产环境的差异压测环境跟生产环境配置不一致压测结果参考价值大打折扣。常见差异包括数据库数据量不同、缓存命中率不同、网络拓扑不同、机器配置不同。理想情况下压测环境应该跟生产环境 1:1 配置但成本太高。折中方案是按比例缩容比如生产环境 10 台机器压测环境 2 台压测结果乘以 5 估算生产容量。但要注意这种估算只在线性扩展假设下成立实际系统往往有非线性瓶颈。6. 压测脚本的版本管理和团队协作压测脚本也是代码需要版本管理。我见过太多团队把脚本放在某个人电脑里人一走脚本就找不到了。JMeter 的.jmx文件是 XML 格式适合用 Git 管理。但要注意 GUI 保存时会重排 XML 结构导致 diff 很乱。建议在 GUI 里编辑后用命令行跑一遍确认没问题再提交。参数化用的 CSV 文件也要纳入版本管理但敏感数据如真实用户密码不要提交用占位符代替实际压测时替换。团队协作方面建议把压测脚本按业务模块拆分每个人负责自己的模块通过 CI 流水线定期跑回归压测。k6 和 Gatling 在这方面天然有优势因为脚本本身就是代码跟业务代码用同一套 CI 流程。7. 云原生时代的压测新思路现在越来越多系统跑在 Kubernetes 上压测方式也在变化。传统压测机部署在集群外压测流量经过入口网关跟真实用户流量路径一致。但这种方式压测机本身可能成为瓶颈。另一种思路是把压测工具也部署到 K8s 集群里用 k6 Operator 或 JMeter Operator 动态创建压测 Pod。这种方式扩展性好但压测流量走集群内网跟真实用户路径有差异需要根据压测目标选择。还有一种做法是用服务网格的流量镜像功能把生产环境的真实流量复制一份到压测环境。这种方式最接近真实场景但需要服务网格支持且要注意脱敏和流量控制。云原生压测提醒K8s 集群里的 Pod 资源限制CPU/内存 limit会影响压测结果。压测 Pod 的 limit 设置太低压测机自己先被限流了。建议压测 Pod 不设 CPU limit或者设得足够高。8. 关于压测工具我个人的几点体会用了这么多年压测工具我最大的体会是工具只是手段压测的目标是发现系统的性能瓶颈和容量上限。不要为了用某个工具而用某个工具也不要迷信某个工具的压测结果。JMeter 依然是通用场景下最稳妥的选择生态成熟、资料丰富、遇到问题容易解决。k6 在 CI/CD 集成场景下体验最好脚本即代码的理念很适合现代研发流程。Locust 适合 Python 团队扩展性强但要注意性能调优。Gatling 的报告最好看适合需要向非技术人员汇报的场景。最后分享一个小技巧不管用哪个工具压测前先用小并发跑一遍完整流程确认脚本逻辑没问题、断言能过、参数化生效。这一步能避免很多低级错误比如参数文件路径写错、断言条件写反、关联提取失败等。我见过太多次压测跑了半小时才发现脚本有问题白白浪费时间。压测这件事脚本写得好不好直接决定了压测结果有没有参考价值。多花时间打磨脚本比多压几轮更有意义。 
长河君 · 2026/9/24 20:38:01 · 阅读 1.2k 2026年13款主流性能测试工具选型指南：JMeter、k6、Locust等深度对比
性能测试这件事说到底是给系统上强度之前的一次全面体检。我做了十多年测试见过太多团队在压测工具选型上反复横跳有人抱着 JMeter 不放有人一窝蜂转向 k6还有人用 Locust 写了几千行 Python 脚本最后发现维护成本比业务代码还高。工具本身没有绝对的好坏关键在于它跟你的团队技术栈、压测场景、报告需求是否匹配。这篇盘点把 2026 年市面上 13 款主流压测工具拉出来逐个拆解从协议支持、脚本编写方式、分布式能力、报告可视化到实际踩坑点尽量讲透。不管你是刚接触性能测试的新人还是正在做工具迁移决策的资深工程师都能从中找到适合自己的那一款。1. 选压测工具之前先搞清楚你在压什么很多人一上来就问哪个工具最好用这个问题本身就问错了。压测工具的选择取决于你要压什么、谁来写脚本、报告给谁看。我见过一个团队用 JMeter 压 gRPC 接口折腾了两周插件最后还是换了工具也见过有人用 k6 压一个需要复杂前置数据构造的业务流脚本写到怀疑人生。所以先花几分钟把下面几个维度想清楚比盲目对比工具参数有用得多。1.1 协议覆盖范围决定了工具的下限压测工具支持的协议种类直接决定了它能不能用在你的项目上。HTTP/HTTPS 是最基础的几乎所有工具都支持。但一旦涉及 gRPC、WebSocket、MQTT、Dubbo、Thrift 这些协议可选范围就大幅缩小了。JMeter 靠插件生态覆盖了大部分协议但插件质量参差不齐有些插件几年没更新了。k6 原生支持 HTTP、WebSocket、gRPC扩展性靠 Go 编写的扩展模块。Locust 基于 Python 的 requests 库理论上只要 Python 能调的协议它都能压但需要自己封装。Gatling 原生支持 HTTP、WebSocket、SSE对 gRPC 的支持还在完善中。实操建议如果你的系统涉及多种协议混合压测优先考虑 JMeter 或 Locust它们的扩展成本相对可控。如果只压 HTTP 接口k6 和 Gatling 的体验会更好。1.2 脚本编写方式决定了团队的上手成本脚本编写方式是选型时最容易被低估的因素。JMeter 用 GUI 拖拽元件上手快但复杂场景维护困难k6 用 JavaScript 写脚本对前端背景的测试人员友好Locust 用 Python适合有开发能力的团队Gatling 用 Scala DSL学习曲线陡但表达能力强。我个人的经验是如果团队里测试人员以功能测试转岗为主JMeter 的 GUI 模式能让他们快速出活如果团队有专职性能测试开发代码化工具k6、Locust、Gatling在版本管理和 CI 集成上优势明显。别小看这个差异我见过一个团队强行让功能测试人员写 Locust 脚本结果每次需求变更都要找开发帮忙改脚本效率反而更低。1.3 报告能力决定了压测结果能不能说服人压测做完了报告是给谁看的给开发看需要详细的响应时间分布、错误率、吞吐量曲线给领导看需要简洁的结论和对比数据给运维看需要资源占用和瓶颈定位信息。JMeter 的 HTML 报告模板经过多年迭代已经比较完善但默认样式确实不太好看社区有汉化模板可以替换。k6 的报告输出比较简洁适合 CI 流水线里快速判断通过与否深度分析需要配合 Grafana 等工具。Gatling 的报告是公认最好看的自带响应时间分布图和请求链路分析。Locust 的 Web UI 实时性好但历史报告需要自己对接存储。2. 13 款主流压测工具逐个拆解下面按工具类型分组逐个讲清楚每款工具的核心特点、适用场景和实际使用中的坑。分组不是绝对的有些工具跨类别我按主要使用方式来归类。2.1 JMeter绕不开的行业基准JMeter 是 Apache 基金会的开源项目Java 编写跨平台运行。它的核心优势是生态成熟、资料丰富、插件众多。你遇到的大部分压测需求网上都能找到现成的解决方案。安装配置这块JMeter 需要先装 JDK推荐 JDK 8 或 JDK 11JDK 17 以上部分插件兼容性有问题。下载官方二进制包解压后配置JMETER_HOME环境变量把bin目录加入PATH就能用。Windows 下双击jmeter.batLinux/Mac 下执行jmeter.sh。内存不够的话改bin/jmeter文件里的HEAP参数默认 1G 压高并发容易 OOM。脚本编写方面JMeter 的元件体系包括线程组、取样器、逻辑控制器、断言、监听器等。一个典型的压测脚本结构是线程组设置并发数和循环次数HTTP 请求取样器配置接口地址和参数响应断言校验返回结果聚合报告收集数据。!-- JMeter 线程组配置示例 -- ThreadGroup stringProp nameThreadGroup.num_threads100/stringProp stringProp nameThreadGroup.ramp_time10/stringProp boolProp nameThreadGroup.schedulertrue/boolProp stringProp nameThreadGroup.duration300/stringProp /ThreadGroupBeanShell 断言是 JMeter 里用得最多的脚本断言方式可以写 Java 代码校验响应。比如校验返回 JSON 里某个字段的值// BeanShell 断言示例 import org.json.JSONObject; String response prev.getResponseDataAsString(); JSONObject json new JSONObject(response); if (json.getInt(code) ! 200) { Failure true; FailureMessage 返回码不是200实际为 json.getInt(code); }While 控制器配合条件判断可以实现轮询等待场景比如提交任务后不断查询状态直到完成。动态调整 QPS可以通过 Constant Throughput Timer 或者用 BeanShell 脚本动态修改线程数来实现后者更灵活但需要小心线程安全问题。上传文件场景用 HTTP 请求里的文件上传选项卡注意勾选Use multipart/form-data。录制 HTTPS 脚本需要先配置 JMeter 的代理和证书在浏览器里导入 JMeter 的 CA 证书后就能录制。Cookie 管理用 HTTP Cookie Manager 元件可以自动管理会话也可以手动添加固定 Cookie。分布式压测是 JMeter 的强项一台 master 控制多台 slave 就能突破单机并发限制。配置时注意 slave 机器的 JMeter 版本要一致防火墙要放行 1099 和 50000 端口。踩坑提醒JMeter GUI 模式只用来写脚本和调试真正压测必须用命令行模式jmeter -n -t script.jmx -l result.jtl -e -o report否则 GUI 本身会消耗大量资源影响压测结果。2.2 k6为 CI/CD 而生的现代压测工具k6 是 Grafana Labs 维护的开源工具用 Go 编写脚本用 JavaScript。它的设计理念就是测试即代码非常适合集成到 CI/CD 流水线里。k6 的脚本结构很清晰一个典型的 HTTP 压测脚本长这样import http from k6/http; import { check, sleep } from k6; export const options { stages: [ { duration: 30s, target: 50 }, { duration: 1m, target: 100 }, { duration: 30s, target: 0 }, ], thresholds: { http_req_duration: [p(95)500], http_req_failed: [rate0.01], }, }; export default function () { const res http.get(https://api.example.com/users); check(res, { status is 200: (r) r.status 200, response time 500ms: (r) r.timings.duration 500, }); sleep(1); }k6 的thresholds机制是它的一大亮点可以直接在脚本里定义性能门槛CI 流水线里跑完自动判断通过还是失败不需要人工看报告。stages配置支持阶梯式加压模拟真实流量爬坡场景。k6 的分布式能力相对弱一些官方推荐用 k6 Operator 在 Kubernetes 里跑分布式压测配置门槛比 JMeter 高。但单机性能很强一台 8 核 16G 的机器跑几千并发问题不大。实操心得k6 的sleep(1)是模拟用户思考时间但要注意它不占用 VU 资源。如果你需要精确控制请求间隔用sleep就够了如果需要控制每秒请求数得用constant-arrival-rate执行器。2.3 LocustPython 技术栈的首选Locust 是开源 Python 压测工具最大特点是脚本用纯 Python 写扩展性极强。如果你的团队 Python 技术栈为主Locust 几乎是自然选择。Locust 的脚本核心是定义用户行为from locust import HttpUser, task, between class WebsiteUser(HttpUser): wait_time between(1, 3) def on_start(self): self.client.post(/login, json{username: test, password: 123456}) task(3) def view_items(self): self.client.get(/items) task(1) def create_order(self): self.client.post(/orders, json{item_id: 1, quantity: 2})task(3)里的数字是权重表示这个任务被执行的概率是另一个的 3 倍。wait_time控制用户思考时间。on_start在每个用户启动时执行一次适合做登录等前置操作。Locust 的Web UI实时性很好能看到实时 RPS、响应时间、失败率曲线。分布式模式下一台 master 加多台 worker通过--master和--worker参数启动。Locust 的坑主要在性能上Python 的 GIL 限制了单进程的并发能力高并发场景需要开多个 worker 进程。另外 Locust 的 HTTP 客户端基于 requests 库连接池配置不当容易出现端口耗尽问题。2.4 Gatling报告最漂亮的压测工具Gatling 是法国公司开源的压测工具基于 Scala 和 Akka 构建后来推出了 Java DSL。它的报告是公认最好看的自带响应时间分布图、请求链路瀑布图、活跃用户曲线。Gatling 的 Java DSL 脚本示例public class BasicSimulation extends Simulation { HttpProtocolBuilder httpProtocol http .baseUrl(https://api.example.com) .acceptHeader(application/json); ScenarioBuilder scn scenario(BasicScenario) .exec(http(GetUsers) .get(/users) .check(status().is(200))) .pause(1); { setUp( scn.injectOpen( rampUsers(100).during(Duration.ofSeconds(30)), constantUsersPerSec(20).during(Duration.ofMinutes(2)) ) ).protocols(httpProtocol); } }Gatling 的injection模型比 JMeter 的线程组更灵活支持多种加压策略组合。checks机制类似断言可以校验响应状态、内容、响应时间等。Gatling 的分布式能力靠 Gatling Enterprise商业版或者自己用 Docker 编排。开源版单机性能不错但报告生成会消耗较多内存压测机配置要够。2.5 wrk 和 wrk2轻量级 HTTP 压测利器wrk 是用 C 写的轻量级 HTTP 压测工具单机性能极强适合快速验证接口吞吐量。wrk2 是 wrk 的改进版修正了 wrk 的延迟统计问题能输出更准确的延迟分布。wrk 的基本用法wrk -t12 -c400 -d30s --latency https://api.example.com/users-t12是 12 个线程-c400是 400 个连接-d30s压 30 秒--latency输出延迟统计。wrk 支持 Lua 脚本扩展可以自定义请求和校验逻辑。wrk 的局限很明显只支持 HTTP不支持复杂场景编排报告只有命令行输出。它适合做接口级别的快速压测不适合做端到端的业务流压测。2.6 ab最古老的压测工具abApacheBench是 Apache 自带的压测工具几乎每台 Linux 机器上都有。用法极其简单ab -n 10000 -c 100 https://api.example.com/users-n是总请求数-c是并发数。ab 的优点是零依赖、上手快缺点是只支持 HTTP/1.0不支持 Keep-Alive压测结果偏悲观。它适合做最简单的接口验证正式压测不建议用。2.7 VegetaGo 编写的命令行压测工具Vegeta 是 Go 编写的 HTTP 压测工具命令行操作支持恒定速率压测。它的特点是能精确控制每秒请求数适合做稳定性测试。echo GET https://api.example.com/users | vegeta attack -rate100 -duration30s | vegeta reportVegeta 支持多种输出格式包括 JSON、CSV、HTML 图表。它的-rate参数控制每秒请求数比 JMeter 的线程模型更直观。2.8 Tsung老牌多协议压测工具Tsung 是 Erlang 编写的开源压测工具支持 HTTP、WebSocket、MQTT、XMPP 等多种协议。它的分布式能力很强单集群可以模拟百万级并发。Tsung 的配置用 XML 文件学习曲线较陡。它的报告是 HTML 格式包含详细的统计图表。Tsung 的社区活跃度不如 JMeter资料相对少一些。2.9 ArtilleryNode.js 生态的压测工具Artillery 是 Node.js 编写的压测工具脚本用 YAML 或 JavaScript。它的特点是上手快、报告清晰适合 Node.js 技术栈的团队。config: target: https://api.example.com phases: - duration: 60 arrivalRate: 10 scenarios: - flow: - get: url: /users - think: 1Artillery 支持插件扩展可以对接 Datadog、New Relic 等监控平台。它的分布式能力靠 Artillery Pro商业版。2.10 Siege简单直接的压测工具Siege 是 C 编写的 HTTP 压测工具用法简单支持基本的认证和 Cookie。它的特点是配置简单适合快速验证。siege -c 100 -t 30s https://api.example.com/usersSiege 的报告比较基础只有请求数、成功率、响应时间等核心指标。它适合做简单的负载验证复杂场景支持有限。2.11 Locust4jJava 版的 LocustLocust4j 是把 Locust 的核心理念用 Java 重新实现的版本适合 Java 技术栈团队。它的 API 设计跟 Locust 类似但生态和资料远不如原版 Locust。2.12 NeoLoad商业压测工具的代表NeoLoad 是 Tricentis 旗下的商业压测工具提供 GUI 脚本录制、分布式压测、实时监控、AI 辅助分析等功能。它的优势是开箱即用、技术支持完善缺点是价格不菲。NeoLoad 适合预算充足、需要快速上手的企业团队。它的报告和监控集成做得很好能直接对接 APM 工具定位瓶颈。2.13 LoadRunner老牌商业压测工具LoadRunner 是 Micro Focus 旗下的商业压测工具历史悠久功能全面。它支持几乎所有主流协议分布式能力强报告详细。缺点是笨重、价格高、学习曲线陡。LoadRunner 在金融、电信等传统行业还有大量存量用户但互联网公司用得越来越少。3. 工具选型的决策框架和对比表讲了这么多工具到底怎么选我总结了一个决策框架按优先级排序第一步确定协议需求。只压 HTTP 的话选择面很宽涉及 gRPC、WebSocket 等协议优先考虑 JMeter、k6、Locust。第二步确定团队技术栈。Java 团队选 JMeter 或 GatlingPython 团队选 LocustNode.js 团队选 k6 或 Artillery不想写代码选 JMeter GUI 或商业工具。第三步确定集成需求。要进 CI/CD 流水线优先 k6、Gatling、Locust要跟监控平台对接看工具的插件生态。第四步确定预算。开源工具免费但需要自己维护商业工具省心但价格高。下面这张对比表把 13 款工具的核心维度拉平了看工具脚本语言协议支持分布式报告能力上手难度适用场景JMeterGUI/Java极广强中低通用压测k6JavaScriptHTTP/WS/gRPC中中中CI/CD 集成LocustPython依赖库强中中Python 团队GatlingScala/JavaHTTP/WS中强高报告要求高wrk/wrk2LuaHTTP弱弱低接口快速压测ab无HTTP弱弱低简单验证Vegeta无HTTP弱中低恒定速率压测TsungXML多协议强中高多协议大规模ArtilleryYAML/JSHTTP/WS中中低Node.js 团队Siege无HTTP弱弱低简单负载Locust4jJava依赖库中中中Java 团队NeoLoadGUI广强强低企业商业LoadRunnerGUI/脚本极广强强高传统行业选型提醒不要只看工具本身还要看社区活跃度和资料丰富度。JMeter 和 k6 的社区最活跃遇到问题容易找到答案一些小众工具出问题只能自己啃源码。4. 从零搭建一次压测的完整流程工具选好了接下来讲怎么从零跑通一次完整的压测。我以 JMeter 为例因为它的流程最典型其他工具的思路类似。4.1 环境准备和脚本编写先装 JDK再装 JMeter。JDK 版本建议 8 或 11装完后java -version验证。JMeter 解压后配置环境变量命令行执行jmeter -v能看到版本信息就说明装好了。脚本编写在 GUI 里进行。新建测试计划添加线程组设置并发数、ramp-up 时间、循环次数。添加 HTTP 请求默认值元件配置服务器地址和端口。添加 HTTP 请求取样器配置接口路径和方法。添加响应断言校验返回状态码。添加聚合报告和查看结果树监听器方便调试。调试阶段先用 1 个并发跑一遍确认接口能通、断言能过。然后逐步增加并发观察响应时间和错误率变化。4.2 参数化和关联处理真实压测需要模拟不同用户这就涉及参数化。JMeter 用 CSV Data Set Config 元件读取 CSV 文件把用户名、密码等数据参数化。文件路径建议用相对路径方便脚本迁移。关联处理是指从上一个请求的响应里提取数据传给下一个请求。比如登录后拿到 token后续请求都要带上。JMeter 用 JSON Extractor 或正则表达式提取器实现。!-- JSON Extractor 配置示例 -- JSONPostProcessor stringProp nameJSONPostProcessor.referenceNamestoken/stringProp stringProp nameJSONPostProcessor.jsonPathExprs$.data.token/stringProp stringProp nameJSONPostProcessor.match_numbers1/stringProp /JSONPostProcessor提取到的 token 用${token}在后续请求里引用。4.3 命令行压测和报告生成脚本调试好后用命令行模式压测jmeter -n -t test.jmx -l result.jtl -e -o report-n非 GUI 模式-t指定脚本-l指定结果文件-e压测后生成报告-o指定报告输出目录。报告目录必须为空否则会报错。生成的 HTML 报告包含响应时间分布、吞吐量曲线、错误率统计等。默认报告是英文的社区有汉化模板可以替换bin/report-template目录下的文件。4.4 分布式压测配置单机压不够就上分布式。master 机器上改jmeter.properties里的remote_hosts配置写上所有 slave 的 IP 和端口。slave 机器上启动jmeter-server。master 执行jmeter -n -t test.jmx -R slave1_ip,slave2_ip -l result.jtl-R指定 slave 列表。压测结果会汇总到 master 的结果文件里。分布式踩坑slave 机器的 JMeter 版本必须和 master 一致JDK 版本也要一致。CSV 参数文件要手动同步到每台 slaveJMeter 不会自动分发。网络延迟会影响压测结果slave 和被测系统尽量在同一内网。5. 压测中那些文档不会告诉你的坑这部分是我这些年踩过的坑文档里基本不会写但实际压测中经常遇到。5.1 端口耗尽和 TIME_WAIT 堆积高并发压测时压测机容易出现端口耗尽。Linux 默认的本地端口范围是 32768 到 60999大概 28000 个端口。如果每个请求都新建连接几万请求就能把端口用完。解决办法是调整内核参数# 扩大本地端口范围 sysctl -w net.ipv4.ip_local_port_range1024 65535 # 开启 TIME_WAIT 重用 sysctl -w net.ipv4.tcp_tw_reuse1 # 减少 TIME_WAIT 时间 sysctl -w net.ipv4.tcp_fin_timeout30JMeter 这边要开启 Keep-Alive在 HTTP 请求里勾选Use KeepAlive减少连接创建次数。5.2 压测机自身成为瓶颈压测机 CPU 跑满、内存不够、网络带宽打满都会导致压测结果失真。压测前先用top、free、iftop看看压测机资源。JMeter 的 GUI 模式特别吃资源正式压测一定用命令行。判断压测机是否是瓶颈有个简单方法看压测机的 CPU 使用率。如果压测机 CPU 超过 80%而被测系统 CPU 很低那瓶颈很可能在压测机这边。5.3 断言写太复杂拖慢压测JMeter 的断言是在压测线程里执行的断言逻辑太复杂会拖慢压测速度。BeanShell 断言性能尤其差因为它每次都要编译执行。能用 JSON 断言就用 JSON 断言能用响应断言就用响应断言实在不行再用 JSR223 断言配合 Groovy 脚本。5.4 报告里的响应时间到底看哪个JMeter 聚合报告里有平均值、中位数、90% 线、95% 线、99% 线、最大值、最小值。平均值容易被极端值拉偏参考价值有限。我一般重点看 95% 线和 99% 线这两个指标更能反映大多数用户的体验。如果 95% 线是 200ms99% 线是 2s说明有 1% 的请求特别慢需要重点排查。这种长尾问题往往比平均响应时间更值得关注。5.5 压测环境和生产环境的差异压测环境跟生产环境配置不一致压测结果参考价值大打折扣。常见差异包括数据库数据量不同、缓存命中率不同、网络拓扑不同、机器配置不同。理想情况下压测环境应该跟生产环境 1:1 配置但成本太高。折中方案是按比例缩容比如生产环境 10 台机器压测环境 2 台压测结果乘以 5 估算生产容量。但要注意这种估算只在线性扩展假设下成立实际系统往往有非线性瓶颈。6. 压测脚本的版本管理和团队协作压测脚本也是代码需要版本管理。我见过太多团队把脚本放在某个人电脑里人一走脚本就找不到了。JMeter 的.jmx文件是 XML 格式适合用 Git 管理。但要注意 GUI 保存时会重排 XML 结构导致 diff 很乱。建议在 GUI 里编辑后用命令行跑一遍确认没问题再提交。参数化用的 CSV 文件也要纳入版本管理但敏感数据如真实用户密码不要提交用占位符代替实际压测时替换。团队协作方面建议把压测脚本按业务模块拆分每个人负责自己的模块通过 CI 流水线定期跑回归压测。k6 和 Gatling 在这方面天然有优势因为脚本本身就是代码跟业务代码用同一套 CI 流程。7. 云原生时代的压测新思路现在越来越多系统跑在 Kubernetes 上压测方式也在变化。传统压测机部署在集群外压测流量经过入口网关跟真实用户流量路径一致。但这种方式压测机本身可能成为瓶颈。另一种思路是把压测工具也部署到 K8s 集群里用 k6 Operator 或 JMeter Operator 动态创建压测 Pod。这种方式扩展性好但压测流量走集群内网跟真实用户路径有差异需要根据压测目标选择。还有一种做法是用服务网格的流量镜像功能把生产环境的真实流量复制一份到压测环境。这种方式最接近真实场景但需要服务网格支持且要注意脱敏和流量控制。云原生压测提醒K8s 集群里的 Pod 资源限制CPU/内存 limit会影响压测结果。压测 Pod 的 limit 设置太低压测机自己先被限流了。建议压测 Pod 不设 CPU limit或者设得足够高。8. 关于压测工具我个人的几点体会用了这么多年压测工具我最大的体会是工具只是手段压测的目标是发现系统的性能瓶颈和容量上限。不要为了用某个工具而用某个工具也不要迷信某个工具的压测结果。JMeter 依然是通用场景下最稳妥的选择生态成熟、资料丰富、遇到问题容易解决。k6 在 CI/CD 集成场景下体验最好脚本即代码的理念很适合现代研发流程。Locust 适合 Python 团队扩展性强但要注意性能调优。Gatling 的报告最好看适合需要向非技术人员汇报的场景。最后分享一个小技巧不管用哪个工具压测前先用小并发跑一遍完整流程确认脚本逻辑没问题、断言能过、参数化生效。这一步能避免很多低级错误比如参数文件路径写错、断言条件写反、关联提取失败等。我见过太多次压测跑了半小时才发现脚本有问题白白浪费时间。压测这件事脚本写得好不好直接决定了压测结果有没有参考价值。多花时间打磨脚本比多压几轮更有意义。