简介：这是一份Apache JMeter 2.11版本的zip压缩包，适合性能测试工程师、后端开发与运维人员用来搭建轻量级负载测试环境，评估Web应用在高并发下的响应时间与稳定性。JMeter本身完全开源、跨平台，支持HTTP、FTP、SMTP、JDBC等多种协议，可通过GUI或命令行运行，也支持多机分布式施压，在2.11版本中已具备较为成熟稳定的测试能力。压缩包整体约30.49MB，内部目录主要包括bin启动与配置文件、lib依赖库、docs参考文档、extras附加组件、licenses许可说明、src源码以及test测试用例，既可直接解压使用，也便于开发者研究内部实现或进行二次扩展。目前已有152人学习下载，适合需要了解早期JMeter目录结构、复制典型测试计划思路或离线搭建压测工具的读者。

1. 为什么还要用 jmeter-2.11.zip：老版本压测工具在轻量场景下的现实意义

手头要临时压一个老项目的登录接口，公司机器只装了 JDK 8，折腾新版 JMeter 4/5 反而被各种依赖和证书问题卡住。jmeter-2.11.zip 就是为这种场景准备的：它是个免安装的绿色压缩包，解压就能用，内存占用小，核心功能齐全，拿来做接口测试、小并发压测和性能验证完全够。新版能做的事它大部分能做，只是界面和报告没有新版本漂亮。这篇文章按从零安装、脚本搭建、命令行压测、常见翻车现场、自己分析结果这个顺序来写，适合刚入门的测试和开发，也适合需要在老环境里快速落地一套压测工具的人。

2. 安装与启动：JDK 版本匹配是关键，zip 包怎么落到本地

2.1 先确认 JDK 版本：2.11 只吃 JDK 7/8，别拿新版硬怼

JMeter 2.11 是一个 Java 应用，它的默认运行级别是 Java 7 和 Java 8。启动脚本会在 JAVA_HOME 下找 java 可执行文件，如果系统里装的是 JDK 11 或更高版本，启动时就会报出 Unsupported major.minor version 52.0 这样的 class 版本错误，原因不是 JMeter 坏了，而是编译版本和运行版本不匹配。所以第一步不是解压，而是先确认机器里的 Java 环境。

java -version echo $JAVA_HOME

如果 java -version 显示的是 1.8.0_xxx，说明没问题；如果显示 11.0.x 或 17.0.x，就要准备一个 JDK 8。常见做法是下载 JDK 8 的安装包，安装后手动设置 JAVA_HOME 指向 JDK 8 的目录。Windows 环境变量界面里设置：

JAVA_HOME=C:\Program Files\Java\jdk1.8.0_202 PATH=%JAVA_HOME%\bin;%PATH%

设置完成后重新打开终端，再执行 java -version 确认。这里有一个容易踩的细节：如果原本 PATH 里已经有多个 JDK，即使你改了 JAVA_HOME，终端可能仍在使用靠前的旧路径。所以查看 which java 或 where java 的输出，确认实际可执行文件的位置。JMeter 2.11 的 bin 目录下 jmeter.bat 会优先读 JAVA_HOME，其次是 PATH，所以改完要彻底关掉旧终端再开新的。

提示：如果同一台机器上有多个 JDK，不要动系统全局 PATH，建议单独写一个 JMeter 启动脚本，在脚本里临时 export JAVA_HOME。

2.2 解压与目录结构：bin、lib、extras 里有什么

拿到 jmeter-2.11.zip 后，我习惯先看目录结构再决定放哪。这个包解压后是一个几十 MB 的目录，里面最核心的三个子目录是 bin、lib 和 extras。bin 是启动入口，lib 是所有依赖库，extras 里是一些辅助模板和示例脚本。bin 下面有 jmeter.bat（Windows 启动脚本）、jmeter.sh（Linux/macOS 启动脚本），还有 jmeter 本身的可执行脚本和一些工具脚本。lib 里存放的是 JMeter 运行所需的 jar 包，如果你要驱动数据库，需要额外把 MySQL 或 PostgreSQL 的 jar 包也丢进这个目录，这个会在第 5 章讲。

解压路径有一个长期被忽略的坑：不要放在带空格的路径里，比如 Program Files 和中文目录。JMeter 2.11 的脚本没有对路径做转义处理，路径空格可能导致找不到文件。常见做法是放在一个纯英文、无空格的路径下，比如 C:\tools\jmeter-2.11 或 /opt/jmeter-2.11。我通常还会把 bin 目录加到 PATH 里，这样后面命令行压测时不需要每次写完整路径。

2.3 首次启动：jmeter.bat 和 jmeter.sh 的参数不要乱加

Windows 上双击 jmeter.bat 即可启动 GUI；Linux 上先给脚本加执行权限再运行：

cd /opt/jmeter-2.11/bin chmod +x jmeter.sh ./jmeter.sh

启动成功后会看到一个 Swing 风格的图形界面，左侧是测试计划树，右侧是组件编辑区。在 2.11 里，GUI 模式主要用于编辑脚本和调试单个请求，不建议拿它跑正式压测。启动脚本支持几个有用的参数，最常用的是 -n 表示 non-GUI 模式，-t 指定测试脚本，-l 指定结果文件，-h 帮助，-v 打印版本。第一次使用可以在终端跑一下 ./jmeter.sh -v，确认版本输出是 2.11，避免后续脚本加载错误。

这里有一个很多人翻车的地方：在 GUI 模式下点击“启动”后，界面会卡住，鼠标一直在转，但那不一定是 JMeter 卡死。如果线程组里配置了较大的线程数，GUI 模式启动时要把所有线程都加载起来，图形控件重绘会拖慢整个响应。所以调试时用小的线程数（比如 1），正式压测切到命令行。

2.4 验证安装：跑一个最小的 HTTP 请求

启动 GUI 后，右键“测试计划”添加“线程组”，在线程组里添加“HTTP 请求”，配置里填一个可用的地址。为了验证 JMeter 本身的工作流程，我一般先访问 http://example.com/ 或内网一个简单接口，不用 HTTPS，避免证书干扰。然后右键线程组添加“察看结果树”监听器，点击绿色播放按钮运行，观察响应数据。

这里可以把测试计划保存下来，后端其实是一个 XML 文件。JMeter 2.11 的 jmx 文件是 XML 结构，核心节点是 TestPlan、ThreadGroup、HTTPSamplerProxy 和 ResultCollector。看一个最小示例：

<?xml version="1.0" encoding="UTF-8"?> <jmeterTestPlan version="1.2" properties="5.0" jmeter="2.11"> <hashTree> <TestPlan guiclass="TestPlanGui" testname="验证计划" enabled="true"> </TestPlan> <hashTree> <ThreadGroup guiclass="ThreadGroupGui" testname="线程组" enabled="true"> <stringProp name="ThreadGroup.num_threads">1</stringProp> <stringProp name="ThreadGroup.ramp_time">1</stringProp> <stringProp name="ThreadGroup.loop_count">1</stringProp> </ThreadGroup> <hashTree> <HTTPSamplerProxy guiclass="HttpTestSampleGui" testname="HTTP请求" enabled="true"> <stringProp name="HTTPSampler.domain">example.com</stringProp> <stringProp name="HTTPSampler.path">/</stringProp> <stringProp name="HTTPSampler.method">GET</stringProp> </HTTPSamplerProxy> <hashTree> <ResultCollector guiclass="ViewResultsFullVisualizer" testname="察看结果树" enabled="true"/> </hashTree> </hashTree> </hashTree> </hashTree> </jmeterTestPlan>

这段 XML 对应 GUI 里的一个测试计划，属性说明：ThreadGroup.num_threads 是线程数，ramp_time 是启动线程所用秒数，loop_count 是每个线程的循环次数；HTTPSampler.domain 是域名，path 是路径，method 是 GET。对新手来说，不需要手写这个文件，GUI 保存自然会生成。但我建议至少知道 num_threads 和 ramp_time 存在，因为后面命令行压测时你会反复调这两个值。如果能成功跑出结果树里的绿色响应，说明 jmeter-2.11.zip 的解压目录、JDK 环境和启动脚本都没有问题，下一步就可以开始写这次压测真正要用的脚本了。

3. 用 GUI 搭一个真实接口测试：线程组、采样器和监听器的三角关系

3.1 线程组参数：线程数、Ramp-Up、循环次数到底怎么配

线程组是被测请求的“用户工厂”。一个线程代表一个虚拟用户，线程数就是最大并发数，Ramp-Up 时间控制从 0 到最大并发需要多长时间，循环次数控制每个线程执行多少轮。三者共同决定最终请求量。很多人在做接口测试时把线程数直接当成 QPS，这是不对的。QPS 是请求完成率，等于总请求数除以总时间。所以配置不当，可能出现线程数很高但实际 QPS 上不去的情况。

我一般这样配：先确认接口的预期峰值并发，线程数设为它的 110%，Ramp-Up 设为 5 到 10 秒，循环次数选中“永远”，再用“调度器配置”里的持续时间控制压测时长。2.11 的线程组里，在“Scheduler Configuration”勾选“Specify Thread lifetime”并填持续时间，就能让压力按时间推进，而不是依赖循环次数。固定线程数加固定循环次数没法精确控制压力时长，尤其是有慢请求的场景。

下面是一个线程组常用的配置参考：

Ramp-Up 设成 0 时，JMeter 会在启动瞬间创建所有线程。很多新手以为这样能快速得到高并发，但实际上线程同时起步会让负载机和被测应用都出现尖峰，结果反而不代表真实情况。一般建议 ramp-up 时间至少覆盖线程数除以 5 的秒数，让压力缓慢爬升。

3.2 HTTP 采样器：请求头、超时和参数面板

在线程组下添加 HTTP 请求后，右侧需要填域名、端口、路径、请求方法和内容编码。如果是 POST 接口，切换到“Parameters”或“Body Data”选项卡。这里推荐在“HTTP Header Manager”里显式设置 Content-Type，特别是 POST JSON 接口，否则服务端可能返回 415 或解析不出来。

Content-Type: application/json Accept: application/json

在 JMeter 里，接口测试的最小配置是：方法、路径、请求头、超时。超时非常容易漏填，因为 JMeter 默认没有统一的超时时间。如果被测接口突然变慢，线程会一直等待，结果文件里出现大量长时间停滞的样本。在“HTTP 请求”的高级选项卡里把“连接超时”和“响应超时”都填成 3000-5000 毫秒。如果是压测，建议设置 1000-3000 毫秒，超过这个时间就认为失败，不然积压线程会把资源耗光。

3.3 监听器的角色：查看结果树用来调试，聚合报告用来估算吞吐

第一次跑脚本时，一个监听器是必要的：察看结果树。它能直接展示每个请求的请求体、响应体、状态码和耗时。等到调通接口后，结果树就可以删掉或禁用，因为它会把每个响应都存到内存里，压测时会产生极大的内存开销。2.11 里有一个“聚合报告”，能直接显示平均响应时间、中间值、90% 响应时间、吞吐量等指标，但它仍然是 GUI 监听器，跑非 GUI 模式时不会自动输出这些指标，你需要用命令行结果文件再做聚合，这个在第 4 章会讲。

一个小技巧：在结果树里看到 200 不一定代表业务成功。很多接口会在响应体里返回 code 字段，比如 code=0 才代表成功。这时可以加一个“响应断言”，匹配返回的 JSON 片段，断言失败的请求会在结果树里以红色显示。这也是后面判断压测失败率的关键。断言本身不增加多少开销，但别把响应体完整的 JSON 都放进去，只匹配关键字段，比如"success":true。

3.4 保存 jmx：中文路径、空格路径和版本兼容

脚本调通后，保存为 test.jmx。JMeter 的 jmx 文件本质上是一个 XML 文件，保存时默认带测试计划名字。这里有三个经验：第一，测试计划名称和文件路径不要用中文，因为 JMeter 2.11 解析中文路径在部分 Linux 环境下会出问题；第二，脚本里如果有引用的外部 CSV 文件，保存 jmx 时它写的是相对路径，所以最好把 jmx 和数据文件放在同一目录；第三，jmx 文件要用标准文本编辑器打开过一遍，确认没有因为界面操作产生的重复节点。

如果之后你要在命令行跑，保存路径直接决定你执行命令的长度。我会统一把脚本放在 jmeter-2.11/bin 下一个 testplan 子目录里，避免路径过长。最终命令结构固定为：

./jmeter.sh -n -t /opt/jmeter-2.11/bin/testplan/login.jmx -l /opt/jmeter-2.11/bin/testplan/result.jtl

解释一下：-n 是非 GUI 模式，-t 指定脚本，-l 指定结果文件路径。如果路径里有空格，整个路径要加引号，所以干脆不要有空格。这段时间里，jmx 文件本身也要进版本管理，方便你回滚参数改动。每次调整并发配置时，先用 git diff 看一下改动，避免误改到监听器配置。

4. 命令行压测：从“能跑”到“有结果”，non-GUI 模式的参数拆解

4.1 为什么压测必须用 -n：GUI 会吃掉你的负载机资源

很多人第一次跑压测都习惯在 GUI 里点绿色按钮，然后发现吞吐量不高，并发一上来 GUI 就卡死。原因很简单：GUI 模式不仅要管理所有线程，还要把每个样本画到结果树和图表里，这些事非常耗 CPU 和内存。JMeter 压测的最佳实践是在命令行使用 non-GUI 模式，让 JMeter 只做采集，不做展示，负载机才能把资源留给压力本身。

执行命令：

cd /opt/jmeter-2.11/bin ./jmeter.sh -n -t testplan/login.jmx -l testplan/result.jtl

参数含义：-n 表示 non-GUI 模式，-t 后跟脚本文件，-l 后跟结果文件。结果文件是 jtl 格式，本质上是 CSV，可以用文本编辑器打开。运行过程中屏幕会滚动显示进度，结束后在终端末尾可以看到 Generate Summary Results，里面有样本数、平均值、吞吐量。如果你要找 TP90，这个 summary 不提供，需要自己处理结果文件，这个是最后一章的内容。

还有一点：-l 指定的结果文件如果已经存在，JMeter 会提示已有文件，不会覆盖。你换一个新文件名，或者先删掉旧文件。所以我在压测前会做一遍目录检查，确认结果文件不存在，避免跑到一半才发现写不进去，白白浪费了一次压测。

4.2 脚本参数化：用 JMeter 属性把一个脚本跑出多组压力

压测时经常要改变线程数和循环次数，但不想每次打开 GUI 改脚本。常见做法是用 JMeter 内置属性函数 ${__P(threads,10)}，把线程数、循环次数、持续时间变成外部可传入的变量。修改脚本里的线程组配置：

将 num_threads 改为：

<stringProp name="ThreadGroup.num_threads">${__P(threads,10)}</stringProp> <stringProp name="ThreadGroup.ramp_time">${__P(ramp,5)}</stringProp> <stringProp name="ThreadGroup.loop_count">${__P(loops,100)}</stringProp>

命令行传入：

./jmeter.sh -n -t testplan/login.jmx -l testplan/result.jtl -Jthreads=50 -Jramp=10 -Jloops=200

-J 参数会在启动时设置 JMeter 属性，脚本里的 ${__P(threads,10)} 优先读取外部参数，如果没传就使用默认值 10。这样同一份 jmx 可以跑 10 并发、50 并发、200 并发，不用分别建三份脚本。在做这种参数化时，我要提醒你注意数字后面的默认值：如果脚本里写的是 ${__P(threads,)}，默认值没有，JMeter 会把它当成字符串，线程数读取失败。所以默认值一定要写。另外，如果你的脚本里有 CSV 数据文件路径，也要用同样的属性函数处理，并且命令行用 -Jcsvfile=/path/to/data.csv 指定。路径中如果含空格，在命令里要加引号。

4.3 动态调整 QPS：BeanShell 和 BshClient 的组合用法

很多业务场景不是恒定压力，而是期望压测过程中修改吞吐量。在 2.11 里没有像新版本那种随时可调的图形界面，但可以通过 BeanShell Server 实现。原理是：在 jmeter.properties 中开启 BeanShell 服务，然后在脚本中用一个 BeanShell 定时器每间隔一段时间读取属性 qps 的值，计算等待时间；运行中通过 BshClient 或 telnet 连接服务端口，修改 qps 属性，JMeter 脚本会在下一个循环读取到新值，从而动态改变压力。

先确认 jmeter.properties 中这几行没有注释：

beanshell.server.port=9000 beanshell.server.file=../extras/remote.bsh

然后在测试计划中添加一个“BeanShell Timer”，脚本如下：

// 读取外部属性 qps，默认 20 int qps = Integer.parseInt(props.getProperty("qps", "20")); // 计算每次吞吐间隔，单位毫秒 long interval = (long)(1000.0 / qps); // 设置当前采样器的延迟 vars.put("interval", String.valueOf(interval)); return interval;

运行中要调整 QPS 时，用客户端连接 BeanShell 端口：

telnet localhost 9000 props.put("qps","50");

或者使用 JMeter 自带 BshClient，类名可能因包版本变化，所以更保险的方式是 telnet 或 nc 发送命令。这里要说明：BeanShell Timer 返回的是等待毫秒数，每个线程在执行下一次请求前都会等这个时间。它控制的是单个线程的间隔，多个线程叠加后总体吞吐并不严格等于设置的 QPS，但足以做动态调整实验。如果要精确控制整体 QPS，JMeter 的 Constant Throughput Timer 更合适，但它也是近似值。对于严格的常量压测，建议用持续时间和线程数组合，把 QPS 调整当作辅助手段。

4.4 报告生成：2.11 没有 HTML Dashboard，结果文件怎么转成报告

如果你搜“jmeter 5.6.3 生成测试报告”，新版确实提供了 -e -o 参数生成漂亮的 HTML 报告。但 jmeter-2.11.zip 太老，没有这个能力，这也是老版本最明显的短板。如果一定需要 HTML 报告，有两条路：一是把 jtl 转成 CSV 后用 Python 脚本生成图表；二是升级到新版 JMeter，但那就不是这个包了。

在 2.11 里，我建议先保留原始 jtl 文件，它是压测的第一手数据。命令行跑完后，可以用 GUI 里的“聚合报告”加载 jtl 快速看统计，但 GUI 加载大文件会非常慢。更完整的统计需要自己处理 JTL。最后一章我会写一个实际可用的 Python 脚本，算平均、TP90、TP99。如果你只想快速看一眼，也可以在 GUI 中新建一个“聚合报告”，点击“浏览”选择刚刚生成的 result.jtl，它会加载整个文件并显示统计表，但这只适合文件不大的情况，生产上建议用脚本处理。

5. 避坑指南：jmeter-2.11.zip 最常踩的六个翻车现场

5.1 启动报错 Unsupported major.minor version 52.0：Java 版本太新

现象：双击 jmeter.bat 或执行 ./jmeter.sh 后，终端弹出这个 error，JMeter 窗口没出来。 原因：JMeter 2.11 用 JDK 7/8 编译，当前默认 Java 版本太高，class 文件版本不兼容。 解决：安装 JDK 8，设置 JAVA_HOME 指向它，并确认 which java 出来的路径是 JDK 8。如果机器上必须保留新 JDK，不要改全局 PATH，而是单独写一个启动脚本：

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export PATH=$JAVA_HOME/bin:$PATH cd /opt/jmeter-2.11/bin ./jmeter.sh

注意这样只在当前终端窗口生效，不影响系统其他应用。如果脚本还是报错，要检查 jmeter.sh 里的 JVM 参数是不是硬编码了高版本路径。

5.2 HTTPS 录制和访问失败：先处理证书，再做脚本

现象：录制 HTTPS 脚本时，JMeter 代理能代理到请求，但响应报握手失败；或者是访问 HTTPS 接口时出现 ssl_error_no_certificate。 原因：HTTPS 要校验证书，JMeter 有自己的 CA 证书；浏览器需要信任这个 CA，否则代理拦截时无法建立 TLS。如果用 Java 客户端，还会遇到根证书缺失。 解决：在 JMeter 的 bin 目录下找 ApacheJMeterTemporaryRootCA.crt 证书，安装到浏览器的信任列表。在 mac/Windows 上选择安装到“受信任的根证书颁发机构”，安装完重启浏览器，再录制脚本。另外，HTTP 请求里可以设置“Use HTTP Client”为 Java，但在老版本里 Java 客户端对 HTTPS 支持不够好，遇到握手问题还是优先检查证书。

5.3 线程数设很高但吞吐没涨：Ramp-Up 和并发误区

现象：线程组里写了 500 个线程，结果吞吐量只有几十，甚至比 100 线程还低。 原因：一是线程一下子全部起来，系统开销高；二是请求之间有思考时间或等待时间；三是大部分线程在等待超时，真正在传输的很少。 解决：把 Ramp-Up 从 0 改为 20-30 秒，同时把超时时间调短，观察聚合报告里的 Active Threads。如果实际并发达不到线程数，先检查脚本里是否有 Constant Throughput Timer 或人为 sleep，它们会限制吞吐。在 JMeter 2.11 中，可以通过结果树里的线程名称观察活跃线程数，但更可靠的是看后端服务器的连接数。记住一点：线程数只是你发出的请求数量上限，真正压到服务端的才是有效并发。

5.4 动态验证码：正则提取和后置处理器怎么配合

现象：登录接口有验证码，脚本每次执行都返回验证码错误，压测无法继续。 原因：验证码本身是动态返回的，或者由前端生成，你需要把它从上一个接口的响应中提取出来，并写入后续请求。 解决：先看验证码接口的响应格式，如果是 JSON，添加“正则表达式提取器”提取 data.captchaId，再在线程组里加一个 BeanShell 后置处理器，把验证码变量拼进登录请求参数。示例：

// 从响应中提取 code，这里是一个示意 String captcha = vars.get("captchaId"); vars.put("loginCaptcha", captcha);

然后在登录 HTTP 请求的参数值中使用 ${loginCaptcha}。注意验证码有有效期，如果压测持续时间太长，需要每次循环都重新获取，并把验证码接口放到登录接口前一个采样器。这个方法不万能，但能解决大多数动态 token/验证码场景。

5.5 中文乱码：请求和响应两边都要指定编码

现象：压测脚本里 POST 参数是中文，服务端收到乱码；响应返回的中文也乱码。 原因：JMeter 默认按 ISO-8859-1 解码响应，或没有在 HTTP 请求中指定 content encoding。 解决：在 HTTP 请求的“Content encoding”填 utf-8，并在 HTTP Header Manager 里加 Content-Type 的 charset。响应乱码可以在“察看结果树”里看到乱码，但真正压测时建议在监听器里通过修改 bin/jmeter.properties 设置 sampleresult.default.encoding=UTF-8。这行配置只影响结果文件的读取，不影响请求发送。修改后必须重启 JMeter 才生效。如果还是乱码，检查服务端返回头里是不是写了其它字符集，以服务端为准。

5.6 JDBC 压测连不上数据库：驱动包放错位置

现象：添加 JDBC Connection Configuration 后，跑测试提示 No suitable driver found。 原因：数据库驱动 jar 没有放到 JMeter 的 lib 目录，或驱动类名和 URL 不匹配。 解决：把 mysql-connector-java-5.x.jar 放到 jmeter-2.11/lib 目录，重启 JMeter。JDBC URL 写法要匹配版本，例如 jdbc:mysql://localhost:3306/testdb?useUnicode=true&characterEncoding=utf-8。在“JDBC Connection Configuration”里填写 Driver class 为 com.mysql.jdbc.Driver。如果是 PostgreSQL 则放 postgresql jar，驱动类名是 org.postgresql.Driver。这一步没做对，数据库接口测试根本跑不起来。还有一个细节：老版本驱动不要用 com.mysql.cj.jdbc.Driver，它只匹配新版 MySQL Connector/J 8.x。

6. 验证与进阶：用 JTL 文件自己算 TP90，不依赖新版本报告

当命令行压测结束后，你会得到一个 result.jtl。它的每一行是一条请求记录，字段包括时间戳、响应时间、标签、状态码等。首先打开看一个结构：

head -20 result.jtl

你会看到 CSV 格式，通常第一行是字段名：timeStamp,elapsed,label,success,...。其中 elapsed 字段就是单个请求的响应时间（毫秒）。我们要计算 TP90/TP99，也就是把响应时间排序后，取第 90/99 百分位的值。下面这个 Python 脚本可以直接用：

import csv import sys def main(path): times = [] with open(path, newline='', encoding='utf-8', errors='ignore') as f: reader = csv.DictReader(f) for row in reader: if row.get('label', '').startswith('HTTP'): try: times.append(float(row['elapsed'])) except ValueError: pass times.sort() total = len(times) if total == 0: print("no samples") return tp90 = times[int(total * 0.9)] tp99 = times[int(total * 0.99)] avg = sum(times) / total print(f"total={total}") print(f"avg={avg:.2f} ms") print(f"tp90={tp90:.2f} ms") print(f"tp99={tp99:.2f} ms") if __name__ == "__main__": main(sys.argv[1])

运行方式：

python3 parse_jtl.py result.jtl

这个脚本除了算百分位，还可以加一个统计失败率的逻辑：检查 row['success'] 字段，等于 false 的数量除以总数就是失败率。压测报告的核心其实就是这几个值：平均响应时间、TP90、TP99、失败率。新版本 HTML 报告无非是把这些值画成图，自己会用 Python 处理 JTL 后，你再也不依赖新版的报告功能。再往前一步，你可以在命令行压测时通过 -Jthreads、-Jduration 等参数快速跑多组压力，然后写一个简单的 Shell 循环调用同一个 jmx，收集多份 jtl，最后汇总成一张趋势表。我常用的做法是：

for t in 10 50 100 200; do ./jmeter.sh -n -t testplan/login.jmx -l testplan/result_$t.jtl -Jthreads=$t python3 parse_jtl.py testplan/result_$t.jtl >> summary.txt done

这样一次能看出口服从 10 到 200 的变化，比只跑一次更有说服力。从那以后我每次做压测，都强制先跑一个基线脚本，再跑调优后的脚本，把两份 JTL 都用同一套脚本处理，对比 TP90 的变化。压测工具会升级，但这份从 JTL 到百分位数的处理习惯不会过时。希望帮到你。

本文还有配套的精品资源，点击获取