拓冰网站定制 
JMeter5.6 是我在服务端压测里待得最久的一个版本也是不少团队从老版本往上升时最愿意停下来的那个区间。它没搞什么界面大改改动集中在 HTTP 协议实现和运行稳定性上对已经有一套压测流程在跑的人来说这种没什么惊喜本身就是好消息。它本质上是一个纯 Java 编写的开源负载发生器能做接口压测、容量评估、稳定性验证、回归对比也能当接口调试和自动化冒烟的工具用只要你会写 HTTP 请求、会看几个报表指标就能上手。这篇文章面向的是已经会一点开发或测试基础、准备把 JMeter5.6 真正用到项目里的人从环境准备、核心元件摆放、参数化关联到分布式施压和结果解读我会把踩过的坑和常见的错误配置一并说清楚。1. 版本选型与定位JMeter5.6 适合干哪类活1.1 它到底解决什么问题很多人第一次接触压测脑子里想的都是我想知道这个接口能扛多少并发然后就去找一个工具随便填个 1000 线程点开始看到报错一大片得出结论系统不行。这套流程里工具反而是最不重要的环节。JMeter5.6 的价值在于它把发请求这件事拆成了可以精确控制的几个维度多少个线程、多久爬上来、每个线程跑几轮、请求之间要不要等、响应怎么断言、结果存哪里。你把这些维度管住压测结论才有意义。它支持 HTTP/HTTPS、TCP、JDBC、JMS、FTP、SMTP 等一堆协议其中 HTTP 系列是绝大多数人真正会用到的部分也是 5.6 这个版本重点打磨过的部分。它自带命令行运行模式和 HTML 报告生成能力这意味着你可以把它塞进持续集成流程里每次发版跑一轮基准压测对比 TPS 和响应时间的波动比人工点一遍靠谱得多。至于谁适合看这篇东西我的判断是三类人一是后端开发想知道自己写的接口在并发上来之后是什么表现二是测试工程师需要搭一套可复用的压测脚本和报告体系三是运维或 SRE要验证扩容前后的容量差异。三类人关注点不完全一样但底层那套元件结构和参数逻辑是共通的。1.2 和同类工具横向比一比我不建议无脑吹某一个工具选型看场景。下面这张表是我自己在项目里做取舍时的判断依据你可以对照自己的需求看。工具脚本形式单机施压能力协议广度学习成本适合的场景JMeter5.6图形化元件树 少量脚本中等单机几千并发常见很广插件生态大低到中接口压测、业务流程压测、CI 集成wrk命令行 Lua很高只做 HTTP中单接口极限 QPS 摸底k6JavaScript 脚本高HTTP/WebSocket/gRPC中开发主导的脚本化压测LocustPython 脚本中到高易横向扩展HTTP 为主中复杂业务逻辑编排GatlingScala DSL高HTTP/WebSocket高长期维护的大型压测工程从表里能看出来JMeter 的强项不是单机极限性能而是什么协议都能碰一下 不用写代码就能搭出业务流程 报告开箱即用。如果你的目标是摸某个静态接口的物理上限wrk 更快如果你的目标是把登录、下单、支付这一整条链路压起来还要做参数关联和数据驱动JMeter 的元件树结构会让你少写很多胶水代码。1.3 5.6 这个版本带来的实际差异5.6 在 HTTP 取样器的实现下拉里提供了基于 HttpClient5 的可选实现老脚本默认走的 HttpClient4 链路依然保留所以升级上去的老脚本基本不会因为这一项就跑不起来。这一点很关键新实现给了你在连接复用、TLS 行为上多一种选择但默认值没动升级风险是可控的。另一个绕不开的是运行环境。这个版本对 Java 运行时的要求不算苛刻Java 8 起步就能跑但我在实际项目里更倾向统一到 JDK 17 这类长期支持版本原因是压测机常常要跑几个小时甚至过夜JVM 的 GC 表现和堆管理在高负载下差异会放大。GUI 界面的变化不大元素树、右键菜单、属性面板这些布局和老版本一致所以你之前积累的操作习惯不会白费。1.4 哪些场景别硬上 JMeter这句话我必须放在前面说如果你的测试计划复杂到需要在脚本里写几十行循环和条件判断那用 JMeter 会变得很别扭。它的表达式语言虽然能用但调试体验远不如直接写代码。这种场景我更推荐脚本化的压测工具代码复用和版本管理都更顺。还有就是我需要压到十万 QPS这种目标。单机 JMeter 到这个量级瓶颈往往出在压测机自己身上而不是被测系统上最后你测的是压测机的极限。真要压到这个量级要么把目标拆细要么老老实实上分布式要么换更轻量的工具。2. 环境准备与目录结构地基不打平后面全是坑2.1 JDK 的选择与安装细节JDK 这块最容易被忽略。压测机上装了两三个 JDK 是很常见的事然后你用which java看到的和 JMeter 实际用的是同一个但你的脚本读的却是另一个表现就是莫名其妙的类找不到或者 TLS 握手失败。我的习惯是先把环境清干净确认下面三条命令输出一致java -version echo $JAVA_HOME which java如果JAVA_HOME指向的是 JDK 8而 PATH 里第一个 java 是 JDK 17JMeter 启动脚本用的是JAVA_HOME你手动跑的命令行工具用的是 PATH两边就会打架。统一到一个目录然后把它写进压测机的环境变量文件里。版本上Java 8 可以跑但我更推荐用 17 这一档的长期支持版本。原因很实际压测过程中堆内存会被大量样本结果吃掉老版本 JVM 的垃圾回收在大堆场景下停顿更明显而 JMeter 本身又是 Java 写的GC 停顿会直接反映成你的响应时间抖动最后你分不清是系统慢还是压测机卡。2.2 目录结构你要动哪几个文件下载解压后整个目录里真正和你日常打交道的就是下面这几个位置其他基本都是文档和依赖。目录或文件作用你需要动它的频率bin/jmeterLinux/macOS 启动脚本偶尔改堆内存bin/jmeter.batWindows 启动脚本偶尔改堆内存bin/jmeter-server从节点启动脚本分布式压测时用bin/jmeter.properties主配置文件尽量别改bin/user.properties用户级覆盖配置主要改这个bin/saveservice.properties结果文件字段配置需要精简 jtl 时改bin/log4j2.xml日志配置日志爆盘时改lib/ext/放第三方插件和自定义取样器装插件时用lib/放额外依赖 jar需要时复制进来extras/辅助工具比如报表相关脚本基本不用这里有一条经验是花过代价换来的不要直接改jmeter.properties。这个文件在版本升级时会被覆盖你调过的参数会全部丢失。正确做法是把要覆盖的配置写进同目录的user.properties它会在主配置之后加载优先级更高升级时也不会被替换掉。2.3 GUI 模式只用来调脚本别用来施压这一点我说多少遍都不嫌多。GUI 模式下面板要实时刷新每一个样本的响应数据都要往表格里塞内存和 CPU 的开销非常大。你在 GUI 里跑 500 个线程测出来的响应时间很大一部分是界面刷新造成的。GUI 的唯一用途是搭元件树、点一次运行、看单次请求返回对不对。真正施压必须走命令行也就是所谓的非 GUI 模式jmeter -n -t plan.jmx -l result.jtl -j run.log这四个参数的含义是-n表示非 GUI-t指定测试计划文件-l指定结果数据文件-j指定运行日志文件。非 GUI 模式下没有任何界面渲染开销同样的机器能带起更多线程测出来的数据也更接近真实。2.4 搭出第一个能跑的脚本一个最小的可运行结构长这样右键 Test Plan 逐层添加测试计划Test Plan线程组Thread GroupHTTP 请求默认值HTTP Request DefaultsHTTP 信息头管理器HTTP Header ManagerHTTP Cookie 管理器HTTP Cookie Manager事务控制器Transaction ControllerHTTP 请求HTTP Request查看结果树View Results Tree这几层的摆放顺序是有讲究的。配置元件默认值、信息头、Cookie 管理器的生效范围是它的兄弟节点和子节点所以放在线程组下的第一层整个线程组内的所有请求都能继承。把服务地址、端口、公共 Header 这类东西写在默认值里以后换环境只改一处这是可维护性的基础。搭好之后先在线程组里填 1 个线程、1 次循环点运行在查看结果树里看到 200第一个脚本就算通了。这时候别急着加线程先把断言、参数化、事务这些都补齐脚本逻辑稳定之后再加压力。3. 核心元件拆解线程组、控制器、取样器怎么摆3.1 线程组三个参数的计算方法线程组是压力的源头它有三个字段需要理解透线程数、Ramp-up 时间、循环次数。线程数就是并发用户数。Ramp-up 表示用多少秒把这些线程全部启动完。循环次数表示每个线程执行多少轮。很多人忽略的是 Ramp-up 的含义如果你填 100 个线程、Ramp-up 填 1 秒那不是1 秒后开始压而是 JMeter 在 1 秒内尽量把 100 个线程拉起来瞬时冲击很强测出来的错误率会虚高。反过来 Ramp-up 填 100 秒配 100 个线程就是每秒启动 1 个线程爬坡很平缓。并发数怎么估用利特尔法则并发数 目标 TPS × 平均响应时间秒举个具体例子。你希望某个接口跑到 500 TPS预期平均响应时间是 100 毫秒也就是 0.1 秒那么需要的并发数是 500 × 0.1 50。也就是说 50 个线程理论上就能顶出 500 TPS前提是每个线程发完一个请求立刻发下一个中间不加等待。那 Ramp-up 填多少看你想多快爬到目标压力。50 个线程我一般给 25 到 30 秒相当于每秒爬 1.7 到 2 个线程爬坡过程中能顺便观察 TPS 曲线是否平稳上升。如果你想找系统的拐点就做阶梯加压50、100、200、400 各跑 5 分钟看哪个点开始响应时间抬头。循环次数有两种用法。一是固定次数比如 10 次跑完自动停适合功能验证。二是勾选永远并配合调度器设置持续时间比如跑 30 分钟适合稳定性测试。我强烈建议在正式压测时用第二种因为固定次数会让后面的线程早早结束实际并发数在后期是衰减的你算出来的平均值是失真的。还有一个选项叫延迟创建线程直到需要在内存吃紧的场景下勾上它能降低启动瞬间的堆占用代价是线程创建会稍微延后对结果影响不大。3.2 HTTP 请求里必须设置的几项打开一个 HTTP 请求取样器字段看着多真正影响结果的就那几个。协议、服务器名、端口、路径这些如果已经在 HTTP 请求默认值里配好了这里留空即可继承。方法按接口选需要注意的是 POST 请求体的两种填法一种是参数表格JMeter 会按表单格式编码另一种是消息体数据你自己贴 JSON 或 XML 原文。用错格式是导致 400 错误的头号原因贴 JSON 一定要选消息体数据并且记得在信息头管理器里加上Content-Type: application/json。超时设置是必填项我把它当成红线。连接超时和响应超时都不填的话一旦服务端卡住不返回线程会一直挂着压测机上的线程池越积越多最后整个测试计划形同瘫痪你还找不到原因。我的习惯是连接超时给 5 秒响应超时按业务预期给 10 到 30 秒超过就判失败让它进错误率统计。重定向这块跟随重定向和自动重定向效果不一样。跟随重定向会把重定向过程算作子样本你能看到每一跳的耗时自动重定向只保留最终结果耗时会合并。做登录链路压测时我会用跟随重定向方便定位是哪一跳慢。最后是对嵌入资源使用并发池这个选项。如果你压的是页面而不是接口勾上它会模拟浏览器并发加载图片、CSS、JS此时样本数的统计口径和纯接口压测完全不同做对比时别混着来。3.3 逻辑控制器把零散请求变成业务链路单个请求压测只能告诉你这个接口的极限真正有价值的是链路压测。逻辑控制器就是干这个的。事务控制器最常用。把一组请求拖进事务控制器下面它会把这组请求合并成一个父样本统计时你看到的是整条链路的耗时和成功率。这里有个开关叫生成父样本勾上才会有父样本如果你还需要看子请求的明细就把子样本的保存也打开但注意这会让结果文件变大很多。另一个选项是包含定时器和前后置处理器的耗时链路压测里我一般勾上因为真实用户等待的就是包含思考时间的总时长。只执行一次的控制器用来放登录、获取 token 这类动作。把它套在登录请求外面无论线程循环多少次登录只做一次之后所有迭代复用同一个会话。这个设计能避免你压登录接口的时候把认证服务压垮测出来的也不是业务接口的能力。循环控制器用于模拟用户在页面上反复操作比如浏览 5 个商品再下单。条件控制器配合表达式可以实现分支比如只在某个变量为真时才执行下单。表达式建议用__jexl3或__groovy函数老版本里的 JavaScript 支持已经不推荐用了。3.4 定时器与集合点让压力更像真实流量没有定时器的压测线程会以最快的速度连续发请求这在实际业务里几乎不存在。加上定时器有两个作用一是让请求节奏接近真人二是控制整体 TPS 上限。固定定时器最简单给一个毫秒值每个请求前都等这么久。均匀随机定时器给一个范围和偏差等待时间在这个区间内随机能避免所有线程同步造成的脉冲。高斯随机定时器和泊松随机定时器适合更贴近真实分布的模拟用的人少但做长稳测试时确实更平滑。恒定吞吐量定时器是控制 TPS 的利器注意它的单位是每分钟样本数不是每秒。想跑 300 TPS 就得填 18000。它的原理是动态调整请求间隔把吞吐量往目标值上压但前提是并发数足够不然它压不到目标值只能证明你的并发不够。更精确的是精确吞吐量定时器它在高并发下抖动更小。集合点用同步定时器实现。它的作用是让指定数量的线程先攒着攒够了同一瞬间一起发出去用来模拟秒杀这类瞬时并发。这里有个配置容易踩坑如果填了分组线程数却不填超时时间攒不满的线程会一直等下去整个测试就卡死了。超时时间建议给 1000 到 3000 毫秒攒不满就放行。定时器的作用域也要注意放在线程组下面它对组内所有取样器生效放在某个请求下面只对这个请求生效。压测时最常见的错误就是把定时器放错层级导致整条链路每个请求都等了一遍TPS 直接掉一半。3.5 断言没有断言的压测等于没测我见过太多人压测只看 HTTP 状态码是不是 200结果接口返回的是{code: 500, msg: 系统繁忙}状态码依然是 200。这种情况下错误率显示为 0但业务其实全挂了。响应断言是基础检查响应文本里是否包含某个关键词或者用正则匹配。JSON 断言可以直接用 JSONPath 判断某个字段的值比如$.code等于 200。持续时间断言用来标记超过 2 秒就算失败这个在 SLA 有明确要求的场景下特别有用能让慢请求直接进错误统计不会被平均值稀释掉。断言的作用域同样是继承的。放在线程组下会被所有请求执行如果不同接口的返回结构不一样就会大面积误报。我的做法是每个请求下面单独挂断言或者用事务控制器包一层在父节点上做统一断言。4. 关联与参数化让脚本能一口气跑一小时4.1 正则表达式提取器怎么用对关联的本质是把上一个请求的响应内容传给下一个请求当参数。最经典的场景就是登录拿到 token后续请求都要带上。正则表达式提取器有四个关键字段。引用名称是变量名后面用${变量名}引用。正则表达式本体要写好比如响应是token:a1b2c3d4你可以写token:(.?)这里的问号表示非贪婪匹配避免把后面所有内容都吃掉。模板填$1$表示取第一个捕获组。匹配数字填 0 表示随机取一个匹配填具体数字表示取第几个。缺省值这一项千万不要留空。默认情况下如果没匹配到变量会保持字面量${token}传下去请求发出去必然失败但错误信息很难看懂。填一个NOT_FOUND之类的内容报错时一眼就能看出是提取失败。4.2 JSON 提取器比正则更省心的场景如果响应是规整的 JSON我优先用 JSON 提取器不写正则直接写 JSONPath。取顶层字段用$.token取嵌套用$.data.user.id取数组里的所有 id 用$.data.list[*].id递归查找用$..id。匹配数字这一项的含义和正则提取器一致填 -1 表示取所有匹配并存成数组形式填 0 表示随机取一个。做多用户并发时随机取一个这个能力很有用能让不同线程拿到不同的数据。选择哪一种我的判断标准是响应结构稳定、是标准 JSON就用 JSON 提取器可读性好、不容易写错响应是 HTML 片段或者结构不规整才用正则。还有一种情况是响应格式是 JSON 但字段名带特殊字符正则反而更稳这时候别跟工具较劲。4.3 CSV 数据集的几个隐藏开关参数化最常用的手段是 CSV 数据集配置让每个线程从文件里读一行数据。看着简单坑不少。文件路径我建议用绝对路径。用相对路径时基准目录是 JMeter 的启动目录而不是脚本所在目录从命令行跑和从 GUI 跑基准目录可能不一样结果就是本地能跑、服务器上找不到文件。编码统一填 UTF-8文件本身也存成 UTF-8否则中文参数会变成乱码。各字段的含义我整理成了表格重点是后面三项。字段含义我的常用值文件名数据文件路径绝对路径文件编码字符集UTF-8变量名称列名逗号分隔按列定义分隔符列分隔符英文逗号遇到文件结束符再次循环读完后是否回到开头依场景遇到文件结束符停止线程读完后是否终止线程依场景共享模式变量在哪些线程间共享所有线程共享模式是三个选项所有线程共享一份数据、每个线程组一份、每个线程一份。默认是所有线程共享这意味着一群线程抢同一个游标读每个线程读到的行不一样。这个行为在绝大多数场景下就是你想要的。但如果你想让每个线程固定用一组账号跑完整轮就要选当前线程模式让它自己从头读到尾。遇到文件结束符的处理是另一个分水岭。做并发压测时如果数据行数远小于线程数同时又勾了停止线程你会看到线程一个个退出实际并发数不断下降TPS 曲线一路走低。所以要么数据准备足够多要么允许循环复用。4.4 函数与变量几个用了就离不开的JMeter 自带函数足够应付九成场景。生成随机数用__Random构造唯一标识用__UUID取当前时间戳用__time拿当前线程号用__threadNum做自增计数用__counter读取命令行传进来的属性用__P。这里有个概念必须分清变量是线程私有的属性是全局共享的。你在一个线程里设置了变量另一个线程看不到但设置成属性后就能互通。做跨线程组传参时全靠这个机制用__setProperty把值写进属性在另一个线程组里用__P或__property读出来。还有一个技巧是用__V做嵌套变量。比如你想根据线程号拼接出不同的变量名__V可以把变量名的字符串解析成真正的变量值。这个在需要多个用户池的场景下很好用。4.5 跨线程组传参的完整做法假设你的测试计划是一个线程组负责登录并拿到 token另一个线程组负责用这个 token 压业务接口。做法是新建一个 setUp 线程组放登录请求数量设为 1 个线程 1 次循环。登录响应里用提取器拿到 token。紧接着加一个 BeanShell 或 JSR223 取样器用__setProperty把 token 写入全局属性。在业务线程组里用${__P(token)}引用。这里有个执行顺序的细节setUp 线程组一定在其他线程组之前执行tearDown 线程组一定在之后执行这是官方约定的顺序不用靠定时器去凑。另外要注意属性只在同一个 JVM 内共享分布式压测时从节点各自跑各自的不会互相同步跨节点的数据同步得靠外部手段。5. 分布式压测与命令行实战5.1 主从架构的原理单机施压到一定量级会遇到天花板这时候需要多台机器一起发压。JMeter 的分布式模式叫主从也有人叫控制机与执行机主节点负责调度和汇总结果从节点负责真正发请求结果通过 RMI 通道回传给主节点。有个误区要澄清主节点默认不产生压力它只是个指挥。如果你希望主节点也参与施压需要把它自己的地址也写进远程主机列表里。还有一点从节点之间不会共享变量和计数器如果你的脚本依赖全局唯一序号分布式下会重复需要用线程号加节点标识自己拼。5.2 配置步骤和必须统一的几件事配置本身不复杂麻烦的是环境一致性。下面这几条我每次都要逐项检查所有节点的 JMeter 版本必须完全一致主从之间小版本不同都可能出现协议不兼容。所有节点的 JDK 大版本保持一致避免同一脚本在不同 JVM 上行为不同。所有节点的测试计划文件、CSV 数据文件、第三方 jar 保持完全一致路径也要一致。所有节点的时间同步否则结果文件的时间戳对不齐报告里会出现莫名其妙的空档。从节点上的 CSV 文件要单独准备且各节点数据不要重复否则同一批账号会被重复使用。启动从节点就是执行bin/jmeter-server。然后主节点的配置文件里把远程主机列出来格式是地址:端口多个用逗号分隔。默认端口是 1099走的是 RMI 协议。如果从节点所在环境对连接有验签要求通常会在配置里关掉 RMI 的加密开关以简化联调具体做法是在用户属性文件里配置对应的关闭项。端口如果被占用改配置里的服务端口和本地端口即可。5.3 命令行参数速查命令行用熟了会比 GUI 快很多尤其是配合脚本和定时任务。参数作用示例-n非 GUI 模式运行jmeter -n-t指定测试计划文件-t order.jmx-l指定结果数据文件-l result.jtl-j指定运行日志文件-j run.log-e压测结束后生成 HTML 报告-e-o指定报告输出目录-o report/-g从已有结果文件生成报告-g result.jtl-q加载额外的属性文件-q extra.properties-J设置 JMeter 属性-Jthreads200-G设置属性并传给所有从节点-Gthreads200-R指定本次使用的远程主机-R 10.0.0.1,10.0.0.2-X压测结束后退出从节点进程-X一个完整的分布式压测命令大概长这样jmeter -n -t order.jmx -R 10.0.0.1,10.0.0.2,10.0.0.3 \ -Gthreads200 -Gduration1800 \ -l result.jtl -j run.log -e -o report/注意-J和-G的区别前者只影响主节点后者会同步到从节点。分布式场景下要控制线程数必须用-G否则从节点拿不到这个值压力还是按脚本里写死的来。5.4 HTML 报告的生成方式报告有两种生成时机。一是压测时直接加-e -o 目录跑完自动出报告。二是先跑出 jtl 文件之后再用-g离线生成方式如下jmeter -g result.jtl -o report/这里有个高频报错报告输出目录必须不存在或者为空目录。如果目录里已经有上次的报告文件JMeter 会直接拒绝生成并报错提示目录非空。所以自动化脚本里一般会先删目录再生成。还有一点离线生成报告对结果文件的字段有要求。如果结果文件里缺少必要的时间、延迟、线程数等字段报告里的某些图表就是空的。建议在做正式压测前先用小规模跑一遍确认报告能正常出图别等跑了一小时才发现报告生成失败。6. 结果解读与问题排查别让数据骗了你6.1 关键指标怎么看才有意义聚合报告里字段很多我按重要性排个序。指标含义我的看法Samples样本总数用来核对请求是否真的发出去了Error %错误率高于 0.1% 就要查原因别只看 200Average平均响应时间容易被长尾拉偏只作参考Median中位数一半请求比它快比平均值稳90% Line90% 请求不超过该值我最常看的指标99% Line99% 请求不超过该值反映长尾做体验评估必看Throughput吞吐量每秒完成样本数核心指标看拐点Min / Max最快与最慢Max 异常大通常是 GC 或超时Received KB/sec接收速率判断是不是被带宽卡住我自己的判断顺序是先看错误率错误率不达标其他指标都没讨论价值再看 TPS 是否随并发上升如果在某个点之后不升反降、同时响应时间抬头那就是拐点最后看 99% 线它决定了最差的那批用户体验。找拐点的正确做法是阶梯加压。50 并发跑 5 分钟100 并发跑 5 分钟200、400 依次来把每个阶段稳定后的 TPS 和 90% 响应时间画成曲线。曲线开始变平的那个点就是这套系统在单机配置下的容量水位。6.2 常见问题速查表下面这些都 JMeter5.6 接口压测实战：线程组、参数化与分布式施压
JMeter5.6 是我在服务端压测里待得最久的一个版本也是不少团队从老版本往上升时最愿意停下来的那个区间。它没搞什么界面大改改动集中在 HTTP 协议实现和运行稳定性上对已经有一套压测流程在跑的人来说这种没什么惊喜本身就是好消息。它本质上是一个纯 Java 编写的开源负载发生器能做接口压测、容量评估、稳定性验证、回归对比也能当接口调试和自动化冒烟的工具用只要你会写 HTTP 请求、会看几个报表指标就能上手。这篇文章面向的是已经会一点开发或测试基础、准备把 JMeter5.6 真正用到项目里的人从环境准备、核心元件摆放、参数化关联到分布式施压和结果解读我会把踩过的坑和常见的错误配置一并说清楚。1. 版本选型与定位JMeter5.6 适合干哪类活1.1 它到底解决什么问题很多人第一次接触压测脑子里想的都是我想知道这个接口能扛多少并发然后就去找一个工具随便填个 1000 线程点开始看到报错一大片得出结论系统不行。这套流程里工具反而是最不重要的环节。JMeter5.6 的价值在于它把发请求这件事拆成了可以精确控制的几个维度多少个线程、多久爬上来、每个线程跑几轮、请求之间要不要等、响应怎么断言、结果存哪里。你把这些维度管住压测结论才有意义。它支持 HTTP/HTTPS、TCP、JDBC、JMS、FTP、SMTP 等一堆协议其中 HTTP 系列是绝大多数人真正会用到的部分也是 5.6 这个版本重点打磨过的部分。它自带命令行运行模式和 HTML 报告生成能力这意味着你可以把它塞进持续集成流程里每次发版跑一轮基准压测对比 TPS 和响应时间的波动比人工点一遍靠谱得多。至于谁适合看这篇东西我的判断是三类人一是后端开发想知道自己写的接口在并发上来之后是什么表现二是测试工程师需要搭一套可复用的压测脚本和报告体系三是运维或 SRE要验证扩容前后的容量差异。三类人关注点不完全一样但底层那套元件结构和参数逻辑是共通的。1.2 和同类工具横向比一比我不建议无脑吹某一个工具选型看场景。下面这张表是我自己在项目里做取舍时的判断依据你可以对照自己的需求看。工具脚本形式单机施压能力协议广度学习成本适合的场景JMeter5.6图形化元件树 少量脚本中等单机几千并发常见很广插件生态大低到中接口压测、业务流程压测、CI 集成wrk命令行 Lua很高只做 HTTP中单接口极限 QPS 摸底k6JavaScript 脚本高HTTP/WebSocket/gRPC中开发主导的脚本化压测LocustPython 脚本中到高易横向扩展HTTP 为主中复杂业务逻辑编排GatlingScala DSL高HTTP/WebSocket高长期维护的大型压测工程从表里能看出来JMeter 的强项不是单机极限性能而是什么协议都能碰一下 不用写代码就能搭出业务流程 报告开箱即用。如果你的目标是摸某个静态接口的物理上限wrk 更快如果你的目标是把登录、下单、支付这一整条链路压起来还要做参数关联和数据驱动JMeter 的元件树结构会让你少写很多胶水代码。1.3 5.6 这个版本带来的实际差异5.6 在 HTTP 取样器的实现下拉里提供了基于 HttpClient5 的可选实现老脚本默认走的 HttpClient4 链路依然保留所以升级上去的老脚本基本不会因为这一项就跑不起来。这一点很关键新实现给了你在连接复用、TLS 行为上多一种选择但默认值没动升级风险是可控的。另一个绕不开的是运行环境。这个版本对 Java 运行时的要求不算苛刻Java 8 起步就能跑但我在实际项目里更倾向统一到 JDK 17 这类长期支持版本原因是压测机常常要跑几个小时甚至过夜JVM 的 GC 表现和堆管理在高负载下差异会放大。GUI 界面的变化不大元素树、右键菜单、属性面板这些布局和老版本一致所以你之前积累的操作习惯不会白费。1.4 哪些场景别硬上 JMeter这句话我必须放在前面说如果你的测试计划复杂到需要在脚本里写几十行循环和条件判断那用 JMeter 会变得很别扭。它的表达式语言虽然能用但调试体验远不如直接写代码。这种场景我更推荐脚本化的压测工具代码复用和版本管理都更顺。还有就是我需要压到十万 QPS这种目标。单机 JMeter 到这个量级瓶颈往往出在压测机自己身上而不是被测系统上最后你测的是压测机的极限。真要压到这个量级要么把目标拆细要么老老实实上分布式要么换更轻量的工具。2. 环境准备与目录结构地基不打平后面全是坑2.1 JDK 的选择与安装细节JDK 这块最容易被忽略。压测机上装了两三个 JDK 是很常见的事然后你用which java看到的和 JMeter 实际用的是同一个但你的脚本读的却是另一个表现就是莫名其妙的类找不到或者 TLS 握手失败。我的习惯是先把环境清干净确认下面三条命令输出一致java -version echo $JAVA_HOME which java如果JAVA_HOME指向的是 JDK 8而 PATH 里第一个 java 是 JDK 17JMeter 启动脚本用的是JAVA_HOME你手动跑的命令行工具用的是 PATH两边就会打架。统一到一个目录然后把它写进压测机的环境变量文件里。版本上Java 8 可以跑但我更推荐用 17 这一档的长期支持版本。原因很实际压测过程中堆内存会被大量样本结果吃掉老版本 JVM 的垃圾回收在大堆场景下停顿更明显而 JMeter 本身又是 Java 写的GC 停顿会直接反映成你的响应时间抖动最后你分不清是系统慢还是压测机卡。2.2 目录结构你要动哪几个文件下载解压后整个目录里真正和你日常打交道的就是下面这几个位置其他基本都是文档和依赖。目录或文件作用你需要动它的频率bin/jmeterLinux/macOS 启动脚本偶尔改堆内存bin/jmeter.batWindows 启动脚本偶尔改堆内存bin/jmeter-server从节点启动脚本分布式压测时用bin/jmeter.properties主配置文件尽量别改bin/user.properties用户级覆盖配置主要改这个bin/saveservice.properties结果文件字段配置需要精简 jtl 时改bin/log4j2.xml日志配置日志爆盘时改lib/ext/放第三方插件和自定义取样器装插件时用lib/放额外依赖 jar需要时复制进来extras/辅助工具比如报表相关脚本基本不用这里有一条经验是花过代价换来的不要直接改jmeter.properties。这个文件在版本升级时会被覆盖你调过的参数会全部丢失。正确做法是把要覆盖的配置写进同目录的user.properties它会在主配置之后加载优先级更高升级时也不会被替换掉。2.3 GUI 模式只用来调脚本别用来施压这一点我说多少遍都不嫌多。GUI 模式下面板要实时刷新每一个样本的响应数据都要往表格里塞内存和 CPU 的开销非常大。你在 GUI 里跑 500 个线程测出来的响应时间很大一部分是界面刷新造成的。GUI 的唯一用途是搭元件树、点一次运行、看单次请求返回对不对。真正施压必须走命令行也就是所谓的非 GUI 模式jmeter -n -t plan.jmx -l result.jtl -j run.log这四个参数的含义是-n表示非 GUI-t指定测试计划文件-l指定结果数据文件-j指定运行日志文件。非 GUI 模式下没有任何界面渲染开销同样的机器能带起更多线程测出来的数据也更接近真实。2.4 搭出第一个能跑的脚本一个最小的可运行结构长这样右键 Test Plan 逐层添加测试计划Test Plan线程组Thread GroupHTTP 请求默认值HTTP Request DefaultsHTTP 信息头管理器HTTP Header ManagerHTTP Cookie 管理器HTTP Cookie Manager事务控制器Transaction ControllerHTTP 请求HTTP Request查看结果树View Results Tree这几层的摆放顺序是有讲究的。配置元件默认值、信息头、Cookie 管理器的生效范围是它的兄弟节点和子节点所以放在线程组下的第一层整个线程组内的所有请求都能继承。把服务地址、端口、公共 Header 这类东西写在默认值里以后换环境只改一处这是可维护性的基础。搭好之后先在线程组里填 1 个线程、1 次循环点运行在查看结果树里看到 200第一个脚本就算通了。这时候别急着加线程先把断言、参数化、事务这些都补齐脚本逻辑稳定之后再加压力。3. 核心元件拆解线程组、控制器、取样器怎么摆3.1 线程组三个参数的计算方法线程组是压力的源头它有三个字段需要理解透线程数、Ramp-up 时间、循环次数。线程数就是并发用户数。Ramp-up 表示用多少秒把这些线程全部启动完。循环次数表示每个线程执行多少轮。很多人忽略的是 Ramp-up 的含义如果你填 100 个线程、Ramp-up 填 1 秒那不是1 秒后开始压而是 JMeter 在 1 秒内尽量把 100 个线程拉起来瞬时冲击很强测出来的错误率会虚高。反过来 Ramp-up 填 100 秒配 100 个线程就是每秒启动 1 个线程爬坡很平缓。并发数怎么估用利特尔法则并发数 目标 TPS × 平均响应时间秒举个具体例子。你希望某个接口跑到 500 TPS预期平均响应时间是 100 毫秒也就是 0.1 秒那么需要的并发数是 500 × 0.1 50。也就是说 50 个线程理论上就能顶出 500 TPS前提是每个线程发完一个请求立刻发下一个中间不加等待。那 Ramp-up 填多少看你想多快爬到目标压力。50 个线程我一般给 25 到 30 秒相当于每秒爬 1.7 到 2 个线程爬坡过程中能顺便观察 TPS 曲线是否平稳上升。如果你想找系统的拐点就做阶梯加压50、100、200、400 各跑 5 分钟看哪个点开始响应时间抬头。循环次数有两种用法。一是固定次数比如 10 次跑完自动停适合功能验证。二是勾选永远并配合调度器设置持续时间比如跑 30 分钟适合稳定性测试。我强烈建议在正式压测时用第二种因为固定次数会让后面的线程早早结束实际并发数在后期是衰减的你算出来的平均值是失真的。还有一个选项叫延迟创建线程直到需要在内存吃紧的场景下勾上它能降低启动瞬间的堆占用代价是线程创建会稍微延后对结果影响不大。3.2 HTTP 请求里必须设置的几项打开一个 HTTP 请求取样器字段看着多真正影响结果的就那几个。协议、服务器名、端口、路径这些如果已经在 HTTP 请求默认值里配好了这里留空即可继承。方法按接口选需要注意的是 POST 请求体的两种填法一种是参数表格JMeter 会按表单格式编码另一种是消息体数据你自己贴 JSON 或 XML 原文。用错格式是导致 400 错误的头号原因贴 JSON 一定要选消息体数据并且记得在信息头管理器里加上Content-Type: application/json。超时设置是必填项我把它当成红线。连接超时和响应超时都不填的话一旦服务端卡住不返回线程会一直挂着压测机上的线程池越积越多最后整个测试计划形同瘫痪你还找不到原因。我的习惯是连接超时给 5 秒响应超时按业务预期给 10 到 30 秒超过就判失败让它进错误率统计。重定向这块跟随重定向和自动重定向效果不一样。跟随重定向会把重定向过程算作子样本你能看到每一跳的耗时自动重定向只保留最终结果耗时会合并。做登录链路压测时我会用跟随重定向方便定位是哪一跳慢。最后是对嵌入资源使用并发池这个选项。如果你压的是页面而不是接口勾上它会模拟浏览器并发加载图片、CSS、JS此时样本数的统计口径和纯接口压测完全不同做对比时别混着来。3.3 逻辑控制器把零散请求变成业务链路单个请求压测只能告诉你这个接口的极限真正有价值的是链路压测。逻辑控制器就是干这个的。事务控制器最常用。把一组请求拖进事务控制器下面它会把这组请求合并成一个父样本统计时你看到的是整条链路的耗时和成功率。这里有个开关叫生成父样本勾上才会有父样本如果你还需要看子请求的明细就把子样本的保存也打开但注意这会让结果文件变大很多。另一个选项是包含定时器和前后置处理器的耗时链路压测里我一般勾上因为真实用户等待的就是包含思考时间的总时长。只执行一次的控制器用来放登录、获取 token 这类动作。把它套在登录请求外面无论线程循环多少次登录只做一次之后所有迭代复用同一个会话。这个设计能避免你压登录接口的时候把认证服务压垮测出来的也不是业务接口的能力。循环控制器用于模拟用户在页面上反复操作比如浏览 5 个商品再下单。条件控制器配合表达式可以实现分支比如只在某个变量为真时才执行下单。表达式建议用__jexl3或__groovy函数老版本里的 JavaScript 支持已经不推荐用了。3.4 定时器与集合点让压力更像真实流量没有定时器的压测线程会以最快的速度连续发请求这在实际业务里几乎不存在。加上定时器有两个作用一是让请求节奏接近真人二是控制整体 TPS 上限。固定定时器最简单给一个毫秒值每个请求前都等这么久。均匀随机定时器给一个范围和偏差等待时间在这个区间内随机能避免所有线程同步造成的脉冲。高斯随机定时器和泊松随机定时器适合更贴近真实分布的模拟用的人少但做长稳测试时确实更平滑。恒定吞吐量定时器是控制 TPS 的利器注意它的单位是每分钟样本数不是每秒。想跑 300 TPS 就得填 18000。它的原理是动态调整请求间隔把吞吐量往目标值上压但前提是并发数足够不然它压不到目标值只能证明你的并发不够。更精确的是精确吞吐量定时器它在高并发下抖动更小。集合点用同步定时器实现。它的作用是让指定数量的线程先攒着攒够了同一瞬间一起发出去用来模拟秒杀这类瞬时并发。这里有个配置容易踩坑如果填了分组线程数却不填超时时间攒不满的线程会一直等下去整个测试就卡死了。超时时间建议给 1000 到 3000 毫秒攒不满就放行。定时器的作用域也要注意放在线程组下面它对组内所有取样器生效放在某个请求下面只对这个请求生效。压测时最常见的错误就是把定时器放错层级导致整条链路每个请求都等了一遍TPS 直接掉一半。3.5 断言没有断言的压测等于没测我见过太多人压测只看 HTTP 状态码是不是 200结果接口返回的是{code: 500, msg: 系统繁忙}状态码依然是 200。这种情况下错误率显示为 0但业务其实全挂了。响应断言是基础检查响应文本里是否包含某个关键词或者用正则匹配。JSON 断言可以直接用 JSONPath 判断某个字段的值比如$.code等于 200。持续时间断言用来标记超过 2 秒就算失败这个在 SLA 有明确要求的场景下特别有用能让慢请求直接进错误统计不会被平均值稀释掉。断言的作用域同样是继承的。放在线程组下会被所有请求执行如果不同接口的返回结构不一样就会大面积误报。我的做法是每个请求下面单独挂断言或者用事务控制器包一层在父节点上做统一断言。4. 关联与参数化让脚本能一口气跑一小时4.1 正则表达式提取器怎么用对关联的本质是把上一个请求的响应内容传给下一个请求当参数。最经典的场景就是登录拿到 token后续请求都要带上。正则表达式提取器有四个关键字段。引用名称是变量名后面用${变量名}引用。正则表达式本体要写好比如响应是token:a1b2c3d4你可以写token:(.?)这里的问号表示非贪婪匹配避免把后面所有内容都吃掉。模板填$1$表示取第一个捕获组。匹配数字填 0 表示随机取一个匹配填具体数字表示取第几个。缺省值这一项千万不要留空。默认情况下如果没匹配到变量会保持字面量${token}传下去请求发出去必然失败但错误信息很难看懂。填一个NOT_FOUND之类的内容报错时一眼就能看出是提取失败。4.2 JSON 提取器比正则更省心的场景如果响应是规整的 JSON我优先用 JSON 提取器不写正则直接写 JSONPath。取顶层字段用$.token取嵌套用$.data.user.id取数组里的所有 id 用$.data.list[*].id递归查找用$..id。匹配数字这一项的含义和正则提取器一致填 -1 表示取所有匹配并存成数组形式填 0 表示随机取一个。做多用户并发时随机取一个这个能力很有用能让不同线程拿到不同的数据。选择哪一种我的判断标准是响应结构稳定、是标准 JSON就用 JSON 提取器可读性好、不容易写错响应是 HTML 片段或者结构不规整才用正则。还有一种情况是响应格式是 JSON 但字段名带特殊字符正则反而更稳这时候别跟工具较劲。4.3 CSV 数据集的几个隐藏开关参数化最常用的手段是 CSV 数据集配置让每个线程从文件里读一行数据。看着简单坑不少。文件路径我建议用绝对路径。用相对路径时基准目录是 JMeter 的启动目录而不是脚本所在目录从命令行跑和从 GUI 跑基准目录可能不一样结果就是本地能跑、服务器上找不到文件。编码统一填 UTF-8文件本身也存成 UTF-8否则中文参数会变成乱码。各字段的含义我整理成了表格重点是后面三项。字段含义我的常用值文件名数据文件路径绝对路径文件编码字符集UTF-8变量名称列名逗号分隔按列定义分隔符列分隔符英文逗号遇到文件结束符再次循环读完后是否回到开头依场景遇到文件结束符停止线程读完后是否终止线程依场景共享模式变量在哪些线程间共享所有线程共享模式是三个选项所有线程共享一份数据、每个线程组一份、每个线程一份。默认是所有线程共享这意味着一群线程抢同一个游标读每个线程读到的行不一样。这个行为在绝大多数场景下就是你想要的。但如果你想让每个线程固定用一组账号跑完整轮就要选当前线程模式让它自己从头读到尾。遇到文件结束符的处理是另一个分水岭。做并发压测时如果数据行数远小于线程数同时又勾了停止线程你会看到线程一个个退出实际并发数不断下降TPS 曲线一路走低。所以要么数据准备足够多要么允许循环复用。4.4 函数与变量几个用了就离不开的JMeter 自带函数足够应付九成场景。生成随机数用__Random构造唯一标识用__UUID取当前时间戳用__time拿当前线程号用__threadNum做自增计数用__counter读取命令行传进来的属性用__P。这里有个概念必须分清变量是线程私有的属性是全局共享的。你在一个线程里设置了变量另一个线程看不到但设置成属性后就能互通。做跨线程组传参时全靠这个机制用__setProperty把值写进属性在另一个线程组里用__P或__property读出来。还有一个技巧是用__V做嵌套变量。比如你想根据线程号拼接出不同的变量名__V可以把变量名的字符串解析成真正的变量值。这个在需要多个用户池的场景下很好用。4.5 跨线程组传参的完整做法假设你的测试计划是一个线程组负责登录并拿到 token另一个线程组负责用这个 token 压业务接口。做法是新建一个 setUp 线程组放登录请求数量设为 1 个线程 1 次循环。登录响应里用提取器拿到 token。紧接着加一个 BeanShell 或 JSR223 取样器用__setProperty把 token 写入全局属性。在业务线程组里用${__P(token)}引用。这里有个执行顺序的细节setUp 线程组一定在其他线程组之前执行tearDown 线程组一定在之后执行这是官方约定的顺序不用靠定时器去凑。另外要注意属性只在同一个 JVM 内共享分布式压测时从节点各自跑各自的不会互相同步跨节点的数据同步得靠外部手段。5. 分布式压测与命令行实战5.1 主从架构的原理单机施压到一定量级会遇到天花板这时候需要多台机器一起发压。JMeter 的分布式模式叫主从也有人叫控制机与执行机主节点负责调度和汇总结果从节点负责真正发请求结果通过 RMI 通道回传给主节点。有个误区要澄清主节点默认不产生压力它只是个指挥。如果你希望主节点也参与施压需要把它自己的地址也写进远程主机列表里。还有一点从节点之间不会共享变量和计数器如果你的脚本依赖全局唯一序号分布式下会重复需要用线程号加节点标识自己拼。5.2 配置步骤和必须统一的几件事配置本身不复杂麻烦的是环境一致性。下面这几条我每次都要逐项检查所有节点的 JMeter 版本必须完全一致主从之间小版本不同都可能出现协议不兼容。所有节点的 JDK 大版本保持一致避免同一脚本在不同 JVM 上行为不同。所有节点的测试计划文件、CSV 数据文件、第三方 jar 保持完全一致路径也要一致。所有节点的时间同步否则结果文件的时间戳对不齐报告里会出现莫名其妙的空档。从节点上的 CSV 文件要单独准备且各节点数据不要重复否则同一批账号会被重复使用。启动从节点就是执行bin/jmeter-server。然后主节点的配置文件里把远程主机列出来格式是地址:端口多个用逗号分隔。默认端口是 1099走的是 RMI 协议。如果从节点所在环境对连接有验签要求通常会在配置里关掉 RMI 的加密开关以简化联调具体做法是在用户属性文件里配置对应的关闭项。端口如果被占用改配置里的服务端口和本地端口即可。5.3 命令行参数速查命令行用熟了会比 GUI 快很多尤其是配合脚本和定时任务。参数作用示例-n非 GUI 模式运行jmeter -n-t指定测试计划文件-t order.jmx-l指定结果数据文件-l result.jtl-j指定运行日志文件-j run.log-e压测结束后生成 HTML 报告-e-o指定报告输出目录-o report/-g从已有结果文件生成报告-g result.jtl-q加载额外的属性文件-q extra.properties-J设置 JMeter 属性-Jthreads200-G设置属性并传给所有从节点-Gthreads200-R指定本次使用的远程主机-R 10.0.0.1,10.0.0.2-X压测结束后退出从节点进程-X一个完整的分布式压测命令大概长这样jmeter -n -t order.jmx -R 10.0.0.1,10.0.0.2,10.0.0.3 \ -Gthreads200 -Gduration1800 \ -l result.jtl -j run.log -e -o report/注意-J和-G的区别前者只影响主节点后者会同步到从节点。分布式场景下要控制线程数必须用-G否则从节点拿不到这个值压力还是按脚本里写死的来。5.4 HTML 报告的生成方式报告有两种生成时机。一是压测时直接加-e -o 目录跑完自动出报告。二是先跑出 jtl 文件之后再用-g离线生成方式如下jmeter -g result.jtl -o report/这里有个高频报错报告输出目录必须不存在或者为空目录。如果目录里已经有上次的报告文件JMeter 会直接拒绝生成并报错提示目录非空。所以自动化脚本里一般会先删目录再生成。还有一点离线生成报告对结果文件的字段有要求。如果结果文件里缺少必要的时间、延迟、线程数等字段报告里的某些图表就是空的。建议在做正式压测前先用小规模跑一遍确认报告能正常出图别等跑了一小时才发现报告生成失败。6. 结果解读与问题排查别让数据骗了你6.1 关键指标怎么看才有意义聚合报告里字段很多我按重要性排个序。指标含义我的看法Samples样本总数用来核对请求是否真的发出去了Error %错误率高于 0.1% 就要查原因别只看 200Average平均响应时间容易被长尾拉偏只作参考Median中位数一半请求比它快比平均值稳90% Line90% 请求不超过该值我最常看的指标99% Line99% 请求不超过该值反映长尾做体验评估必看Throughput吞吐量每秒完成样本数核心指标看拐点Min / Max最快与最慢Max 异常大通常是 GC 或超时Received KB/sec接收速率判断是不是被带宽卡住我自己的判断顺序是先看错误率错误率不达标其他指标都没讨论价值再看 TPS 是否随并发上升如果在某个点之后不升反降、同时响应时间抬头那就是拐点最后看 99% 线它决定了最差的那批用户体验。找拐点的正确做法是阶梯加压。50 并发跑 5 分钟100 并发跑 5 分钟200、400 依次来把每个阶段稳定后的 TPS 和 90% 响应时间画成曲线。曲线开始变平的那个点就是这套系统在单机配置下的容量水位。6.2 常见问题速查表下面这些都