1. 项目概述：为什么你需要JMeter？

如果你是一名后端开发、测试工程师，或者正在负责一个即将上线的Web应用，那么“性能”这个词一定让你既熟悉又头疼。上线前信心满满，上线后用户一多就卡顿、超时甚至崩溃，这种场景太常见了。问题出在哪？是数据库扛不住，还是代码逻辑有瓶颈？靠猜是没用的，你需要一把精准的“压力标尺”来量化系统的承载能力。这就是我今天要跟你聊的Apache JMeter，一个开源的、纯Java开发的性能测试工具。

简单来说，JMeter能帮你模拟成千上万的虚拟用户，同时向你的服务器发起请求（比如访问网页、调用API接口），然后收集和分析服务器的响应时间、吞吐量、错误率等关键指标。它最初是为Web应用测试设计的，但现在早已扩展到数据库、FTP、JMS、SOAP等各种协议，几乎成了一个全能的性能测试瑞士军刀。对于接口压测这个核心场景，JMeter通过简单的图形化界面就能快速构造HTTP/HTTPS请求，添加各种断言和监听器来分析结果，门槛远比很多同学想象的要低。

我见过太多团队在项目后期才仓促进行性能测试，结果发现致命瓶颈，导致工期延误。其实，性能测试应该像单元测试一样，贯穿开发的整个周期。通过这篇指南，我希望你能在半小时内，完成从零环境搭建到第一个接口压测脚本的创建与执行，快速获得你系统的第一份性能“体检报告”。

2. 核心概念与工作原理拆解

在动手之前，花几分钟理解JMeter的核心逻辑，能让你后续的操作事半功倍，而不是机械地点击按钮。

2.1 JMeter的测试元件模型：像组装乐高一样构建测试

JMeter的测试计划（Test Plan）是一个容器，所有测试内容都基于“元件”来组装。你可以把它理解为一个乐高底座，线程组是骨架，其他各种元件是功能各异的积木。主要元件类型包括：

1. 线程组（Thread Group）：这是所有测试的起点，定义了模拟用户的核心行为。你可以在这里设置“线程数”（即虚拟用户数）、“Ramp-Up时间”（所有用户在多长时间内启动完毕）和“循环次数”（每个用户执行测试计划的次数）。例如，设置线程数100，Ramp-Up时间10秒，循环次数5，意味着JMeter会在10秒内逐步启动100个虚拟用户，每个用户会连续执行5遍测试计划中的所有操作。
2. 取样器（Sampler）：负责向服务器发送请求。对于接口压测，最常用的就是“HTTP请求”取样器。它告诉JMeter：“向这个URL，用这种HTTP方法（GET/POST等），发送这些数据。”
3. 逻辑控制器（Logic Controller）：控制取样器的执行逻辑。比如“循环控制器”可以让其中的请求重复执行；“仅一次控制器”确保其中的操作在每个线程中只执行一次，常用于登录。
4. 监听器（Listener）：负责收集、展示和保存测试结果。比如“查看结果树”可以看到每个请求和响应的详情，用于调试；“聚合报告”和“汇总报告”则提供吞吐量、响应时间、错误率等统计信息，用于分析性能。
5. 配置元件（Config Element）：为取样器提供配置信息。例如“HTTP请求默认值”可以统一设置协议、服务器地址和端口，避免在每个HTTP请求中重复填写；“HTTP信息头管理器”可以添加固定的请求头，如Content-Type: application/json。
6. 断言（Assertion）：用于验证服务器响应是否符合预期。比如“响应断言”可以检查响应文本中是否包含某个关键字，或响应代码是否为200。
7. 前置/后置处理器（Pre/Post-Processors）：在请求发送前或收到响应后对数据进行处理。例如“正则表达式提取器”可以从上一个请求的响应中提取数据（如token、订单ID），并将其作为变量供后续请求使用。

这些元件通过“父子关系”组织。一个线程组下可以添加多个取样器，而一个取样器下又可以添加断言、监听器等。这种层次结构决定了元件的生效范围和作用顺序。

2.2 压测的本质：并发、吞吐量与响应时间

当我们谈论“压测”时，到底在测什么？核心是三个黄金指标：

• 并发用户数：同一时刻向服务器发起请求的虚拟用户数量。这由线程组的“线程数”和调度策略决定。但要注意，JMeter的线程是尽可能快地执行循环，因此“同一时刻”的精确并发度会受到Ramp-Up时间、响应时间以及测试机自身性能的影响。
• 吞吐量：通常指每秒完成的请求数（Requests Per Second, RPS）或每秒事务数（Transactions Per Second, TPS）。这是衡量系统处理能力的核心指标。吞吐量越高，说明系统单位时间内处理请求的能力越强。
• 响应时间：从发送请求到完整接收到响应所花费的时间。通常我们关注平均响应时间、90%或95%分位响应时间（例如，90%的请求响应时间都在200毫秒以内）。响应时间直接关系到用户体验。

这三者相互关联又相互制约。通常，随着并发用户数的增加，吞吐量会先上升后趋于平缓甚至下降，而平均响应时间则会逐渐增加。压测的目的就是找到这个拐点：在可接受的响应时间范围内，系统能支撑的最大吞吐量是多少？这个点就是系统的性能瓶颈所在。

注意：GUI模式警告。当你启动JMeter的图形界面时，命令行窗口会有一行醒目的警告：“Don‘t use GUI mode for load testing !, only for Test creation and Test debugging.” 这是因为图形界面本身会消耗大量的系统资源（CPU和内存），用于渲染图表和界面。如果你用GUI模式去运行一个高并发的压测，测试机资源很可能先被JMeter自己吃光，导致无法产生足够的压力到被测系统，测试结果也就完全失真了。所以，GUI仅用于脚本编写和调试，真正的压测执行必须在非GUI（命令行）模式下进行。

3. 从零开始：环境搭建与第一个脚本

理论说再多不如动手一试。我们一步步来，从安装到跑通第一个接口请求。

3.1 JDK安装与验证

由于JMeter是Java应用，所以第一步是确保你的电脑上安装了Java开发工具包（JDK），并且是1.8或以上版本。

1. 下载JDK：前往Oracle官网或选择OpenJDK发行版（如Adoptium）下载适合你操作系统的JDK安装包。
2. 安装与配置环境变量：
   • Windows：安装后，需要配置系统环境变量。新建JAVA_HOME，变量值为你的JDK安装路径（例如C:\Program Files\Java\jdk-17）。然后在Path变量中添加%JAVA_HOME%\bin。
   • macOS/Linux：通常安装包会自动处理。也可以通过终端命令检查，如使用Homebrew安装：brew install openjdk，然后根据提示配置环境变量。
3. 验证安装：打开终端（或命令提示符），输入java -version。如果正确显示版本信息，说明安装成功。

3.2 JMeter下载与启动

1. 下载：访问Apache JMeter官网（https://jmeter.apache.org/），进入“Download”页面。建议下载最新的稳定版Binaries压缩包（如apache-jmeter-5.6.3.zip），而不是源代码包。
2. 解压：将下载的zip包解压到你喜欢的任意目录，比如D:\Tools\apache-jmeter-5.6.3。这个目录就是JMeter的家目录。
3. 启动GUI（用于脚本开发）：
   • Windows：进入解压后的bin目录，双击jmeter.bat。
   • macOS/Linux：在终端中，进入bin目录，执行./jmeter.sh。 启动后，你会先看到一个命令行窗口，然后JMeter的图形界面主窗口会弹出。第一次启动可能会稍慢。

3.3 创建你的第一个HTTP接口测试脚本

我们的目标是测试一个简单的公开API：https://httpbin.org/get，它会返回我们发送的请求信息，非常适合练手。

1. 创建线程组：

   • 在左侧测试计划树状图中，右键点击“测试计划” -> “添加” -> “线程（用户）” -> “线程组”。
   • 在右侧面板中，保持“线程组”名称不变。我们做功能调试，所以参数先简单设置：
     • 线程数（用户）：1 （先模拟1个用户）
     • Ramp-Up时间（秒）：1 （1秒内启动这1个用户）
     • 循环次数：1 （只执行1次）

2. 添加HTTP请求取样器：

   • 右键点击刚创建的“线程组” -> “添加” -> “取样器” -> “HTTP请求”。
   • 在右侧面板中配置：
     • 名称：改为“获取请求示例”。
     • 协议：https
     • 服务器名称或IP：httpbin.org
     • HTTP请求：选择GET
     • 路径：/get其他参数暂时留空。

3. 添加监听器查看结果：

   • 右键点击“线程组” -> “添加” -> “监听器” -> “察看结果树”。
   • 这个监听器会以树状结构展示每一个请求的详细内容，包括请求头和响应数据，是调试脚本的利器。

4. 运行与查看：

   • 点击工具栏上的绿色“启动”按钮（或按Ctrl+R）。
   • 然后切换到“察看结果树”面板。你应该能看到一个名为“获取请求示例”的条目，点击它。在右侧的“响应数据”标签页中，你会看到一段JSON格式的返回数据，其中包含了你的请求头等信息，说明请求成功了！

至此，你已经完成了最基础的单次接口请求测试。但这离“压测”还差得远。接下来，我们要把它变成一个真正的压力测试脚本。

4. 构建专业的接口压测脚本

一个可用于真实压测的脚本，需要考虑参数化、断言、事务、数据提取等多个方面。

4.1 配置元件：让脚本更灵活高效

直接在每一个HTTP请求中填写完整的URL和端口非常低效，一旦被测服务地址变更，修改起来就是灾难。这时就需要“HTTP请求默认值”。

1. 添加HTTP请求默认值：

   • 右键点击“线程组” -> “添加” -> “配置元件” -> “HTTP请求默认值”。
   • 将其拖拽到“线程组”下方（配置元件的生效范围是其父元件及所有子元件，放在线程组下，则该线程组内所有HTTP请求都会继承这些默认值）。
   • 在右侧面板中设置：
     • 协议：https
     • 服务器名称或IP：httpbin.org
     • 端口号：443(HTTPS默认端口，也可留空)
   • 现在，你可以回到之前的“HTTP请求”取样器，将“协议”、“服务器名称或IP”清空，它依然能正确访问https://httpbin.org/get。

2. 添加HTTP信息头管理器：

   • 对于现代API，尤其是返回JSON的RESTful API，在请求头中指定Content-Type是标准做法。
   • 右键点击“线程组” -> “添加” -> “配置元件” -> “HTTP信息头管理器”。
   • 在右侧面板中，点击“添加”按钮，新建一个头信息：
     • 名称：Content-Type
     • 值：application/json
   • 同样，这个管理器对其作用域内的所有HTTP请求生效。

4.2 构造复杂的请求：POST与JSON数据

GET请求很简单，但压测中更多是创建、更新数据的POST请求。

1. 添加一个新的HTTP请求：

   • 右键点击“线程组” -> “添加” -> “取样器” -> “HTTP请求”。放在第一个请求下面即可。
   • 配置这个新请求：
     • 名称：POST创建数据
     • HTTP请求：选择POST
     • 路径：/post
     • Body Data：在选项卡中找到“消息体数据”或“Body Data”的输入框，输入一段JSON，例如：

       { "name": "Test User", "email": "test@example.com" }

2. 使用变量参数化请求：

   • 硬编码数据在压测中意义不大，我们需要模拟不同用户提交不同数据。JMeter提供多种参数化方式，最简单的是“用户定义的变量”和“CSV数据文件设置”。
   • 方法一：用户定义的变量（适用于少量固定值）：
     • 右键点击“线程组” -> “添加” -> “配置元件” -> “用户定义的变量”。
     • 添加几个变量，如username=user_${__threadNum}（__threadNum是JMeter内置函数，表示当前线程编号）。
   • 方法二：CSV数据文件设置（适用于大量测试数据）：
     • 创建一个testdata.csv文件，内容如下：

       name,email Alice,alice@example.com Bob,bob@example.com Charlie,charlie@example.com

     • 右键点击“线程组” -> “添加” -> “配置元件” -> “CSV数据文件设置”。
     • 配置：
       • 文件名：你的testdata.csv文件完整路径。
       • 文件编码：UTF-8
       • 变量名称：name,email(与CSV表头对应，用逗号分隔)
       • 忽略首行：True(因为第一行是表头)
       • 遇到文件结束符再次循环：True(数据用完是否从头开始)
       • 遇到文件结束符停止线程：False
   • 修改POST创建数据请求的Body Data，使用变量引用：

     { "name": "${name}", "email": "${email}" }

     这样，每个虚拟用户（或每次循环）都会从CSV文件中读取一行数据来发送请求。

4.3 添加断言：验证接口响应是否正确

压测不仅要看系统会不会挂，还要看返回结果对不对。断言就是我们的“质检员”。

1. 添加响应断言：

   • 右键点击“POST创建数据”这个HTTP请求取样器（注意，是点击取样器本身，不是线程组） -> “添加” -> “断言” -> “响应断言”。
   • 在右侧面板中配置：
     • 要测试的响应字段：选择“响应代码”。
     • 模式匹配规则：选择“等于”。
     • 要测试的模式：点击“添加”，输入200。
   • 这个断言会检查该请求的HTTP响应状态码是否为200。如果不是，JMeter会将该请求标记为失败。

2. 添加JSON断言（更精确的检查）：

   • 如果返回的是JSON，我们可能想检查某个具体字段的值。JMeter默认没有JSON断言，但可以通过安装插件或使用“JSR223断言”配合Groovy脚本实现。这里介绍一个常用插件方法：
     • 首先，你需要安装“JMeter Plugins Manager”。从https://jmeter-plugins.org/下载plugins-manager.jar，放入JMeter的lib/ext目录，重启JMeter。
     • 重启后，在“选项”菜单下会出现“Plugins Manager”。在其中搜索并安装“JSON/YAML Plugins”。
   • 安装后，你就可以添加“JSON Assertion”了。配置它来检查响应JSON中json.name字段是否等于我们发送的${name}变量。

4.4 添加事务控制器与定时器

为了更真实地模拟用户操作和计算TPS，我们需要组织请求并加入思考时间。

1. 添加事务控制器：

   • 右键点击“线程组” -> “添加” -> “逻辑控制器” -> “事务控制器”。
   • 将“获取请求示例”和“POST创建数据”两个HTTP请求拖拽到“事务控制器”下面。
   • 勾选事务控制器上的“Generate parent sample”。这样，在监听器报告中，这两个请求会被合并为一个“事务”，我们关注的是这个事务的TPS和响应时间，而不是单个请求的。

2. 添加定时器：

   • 用户操作不是机器，请求之间会有间隔。右键点击“事务控制器” -> “添加” -> “定时器” -> “固定定时器”。
   • 设置“线程延迟”为1000（毫秒），表示每个用户执行完这个事务后，会等待1秒再开始下一次循环（如果循环次数大于1）。你也可以添加“高斯随机定时器”来模拟更真实的随机等待时间。

4.5 配置专业的监听器

“察看结果树”在调试时很好用，但在正式压测中会产生海量数据，严重影响性能。我们需要用更轻量、更聚合的监听器。

1. 添加聚合报告：

   • 右键点击“线程组” -> “添加” -> “监听器” -> “聚合报告”。
   • 这个监听器会提供一份清晰的表格，包含所有取样器的关键统计数据：样本数、平均响应时间、最小/最大响应时间、错误率、吞吐量（Requests/sec）等。这是分析性能的核心报告。

2. 添加汇总报告：与聚合报告类似，格式稍有不同，可按需添加。

3. 添加后端监听器（推荐用于长时间压测）：

   • 这是将结果实时输出到外部系统（如InfluxDB + Grafana）的插件，可以避免GUI监听器的内存开销。需要安装“Backend Listener”插件。
   • 添加后，可以选择将数据发送到InfluxDB，实现漂亮的实时监控图表。

现在，你的线程组结构应该看起来层次分明，类似这样：

测试计划 └── 线程组 (线程数：10, Ramp-Up: 5, 循环次数：永远) ├── 事务控制器 │ ├── HTTP请求 - 获取请求示例 │ └── HTTP请求 - POST创建数据 │ └── 响应断言 ├── CSV数据文件设置 ├── HTTP请求默认值 ├── HTTP信息头管理器 ├── 固定定时器 (1000 ms) └── 聚合报告

别忘了点击菜单栏的“文件”->“保存”，将测试计划保存为一个.jmx文件。这个文件就是你的压测脚本，可以在命令行中执行。

5. 执行压测与结果分析

脚本调试无误后，就要进入正题：执行真正的压力测试并解读结果。

5.1 非GUI模式执行压测

这是唯一正确的压测执行方式。关闭JMeter GUI（或者不关，但不要用GUI运行测试），打开命令行终端。

1. 基本命令：

   jmeter -n -t <测试计划文件路径.jmx> -l <结果文件路径.jtl> -e -o <HTML报告输出目录>

   • -n: 指定以非GUI模式运行。
   • -t: 指定要运行的JMeter测试脚本（.jmx文件）。
   • -l: 指定保存原始结果数据的文件（.jtl或.csv格式）。
   • -e: 测试结束后生成HTML报告。
   • -o: 指定存放生成的HTML报告的目录（目录必须为空或不存在）。

2. 示例： 假设你的脚本保存在D:\perf_test\my_test.jmx，你想把结果输出到D:\perf_test\result.jtl，并生成报告到D:\perf_test\web_report。

   # Windows (在JMeter的bin目录下打开cmd) jmeter -n -t D:\perf_test\my_test.jmx -l D:\perf_test\result.jtl -e -o D:\perf_test\web_report # macOS/Linux ./jmeter -n -t /Users/you/perf_test/my_test.jmx -l /Users/you/perf_test/result.jtl -e -o /Users/you/perf_test/web_report

3. 调整JVM堆内存： 如果模拟的用户数很多，JMeter本身可能会内存不足。你需要编辑JMeter启动脚本（bin/jmeter或bin/jmeter.bat）来调整JVM参数。找到HEAP环境变量设置的地方，根据你的测试机内存情况调整，例如：

   HEAP="-Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m"

   这设置了初始堆内存和最大堆内存为4GB。请勿超过你机器物理内存的70%。

5.2 解读聚合报告

命令执行完毕后，打开生成的HTML报告（web_report目录下的index.html），或者直接在JMeter GUI中打开“聚合报告”监听器（如果你在GUI中加载了结果文件）。我们重点关注以下几列：

• 样本：总共发出的请求数量。
• 平均值：请求的平均响应时间（毫秒）。这是整体性能的直观感受。
• 中位数：50%的请求响应时间低于这个值。它比平均值更能抵抗极端值的影响。
• 90%分位：90%的请求响应时间低于这个值。这是评估用户体验更关键的指标，比如“90%的用户请求在200ms内完成”。
• 最小值/最大值：响应时间的波动范围。最大值异常高可能意味着有某些请求遇到了严重问题。
• 异常%：请求的错误率。理想情况下应为0%。任何非零的错误率都需要重点排查。
• 吞吐量：每秒完成的请求数（Requests/sec）。这是系统处理能力的核心体现。注意：这个吞吐量是服务端实际处理的吞吐量，在单台测试机施压时，可能受限于测试机网络或CPU，无法达到服务端真实上限。此时需要考虑分布式压测。
• 接收/发送KB/sec：网络带宽使用情况。

5.3 性能瓶颈分析与调优思路

拿到报告后，如何分析？

1. 看错误率：如果错误率（异常%）很高，一切免谈。先解决错误问题。查看result.jtl文件或使用“查看结果树”加载结果，定位是哪些请求失败了，失败原因是什么（超时？5xx错误？4xx错误？）。
2. 看响应时间曲线：随着并发用户数（线程数）增加，观察平均响应时间和90%分位响应时间的变化。如果它们几乎呈线性增长，说明系统可能没有瓶颈，或者瓶颈在测试机本身。如果增长到某个点后突然急剧上升，说明系统达到了瓶颈。
3. 看吞吐量曲线：随着并发用户数增加，吞吐量会先线性上升，然后趋于平缓。当吞吐量不再增长甚至下降，而响应时间急剧上升时，那个拐点就是系统在当前场景下的最大处理能力。
4. 定位瓶颈：确定了存在瓶颈后，需要结合系统监控（如服务器的CPU、内存、磁盘I/O、网络I/O、数据库连接数、慢查询日志、应用GC日志等）来定位。常见的瓶颈点：
   • 应用服务器：CPU满载、内存泄漏、GC频繁、线程池耗尽、代码同步锁。
   • 数据库：慢查询、连接池耗尽、锁竞争、磁盘IOPS瓶颈。
   • 缓存：缓存命中率低、缓存服务超时。
   • 网络与中间件：带宽不足、负载均衡策略不当、MQ堆积。

实操心得：压测是一个“假设-验证-调整”的循环过程。不要指望一次压测就能找到所有问题。通常的步骤是：先用较小的并发（如50用户）进行“冒烟测试”，确保脚本和系统基本正常；然后逐步增加并发（如100， 200， 500...），观察指标变化，记录下性能拐点；最后在拐点附近进行持续一段时间的“稳定性测试”（如30分钟），观察系统在极限压力下是否有内存泄漏等问题。

6. 高级技巧与常见问题排查

掌握了基础流程后，一些高级技巧和避坑经验能让你事半功倍。

6.1 分布式压测

单台测试机由于网络、端口、CPU的限制，可能无法产生足够大的压力。JMeter支持分布式压测，由一台控制机（Controller）指挥多台压力机（Agent/Slave）共同施压。

1. 压力机配置：

   • 在所有压力机上安装相同版本的JMeter和JDK。
   • 编辑压力机JMeterbin目录下的jmeter-server（Unix）或jmeter-server.bat（Windows）文件，取消注释并设置RMI_HOST为压力机自身的IP地址。
   • 运行jmeter-server启动服务。

2. 控制机配置：

   • 编辑控制机JMeterbin目录下的jmeter.properties文件。
   • 找到remote_hosts参数，将其值设置为所有压力机的IP地址和端口（默认1099），用逗号分隔，例如：remote_hosts=192.168.1.101:1099,192.168.1.102:1099。
   • 如果需要传输测试数据文件（如CSV），需要手动将其拷贝到所有压力机的相同路径下。

3. 执行分布式测试：

   • 在控制机的GUI中，运行菜单选择“远程启动”-> 选择指定的压力机，或者选择“远程启动所有”。
   • 在非GUI模式下，使用-R参数指定压力机列表：jmeter -n -t test.jmx -R 192.168.1.101,192.168.1.102 -l result.jtl

注意：分布式压测时，监听器（特别是“察看结果树”）最好只保留聚合报告类的，并且确保所有压力机的时钟同步（NTP），否则时间戳会对不上。

6.2 正则表达式与JSON提取器

在接口串联测试中（如先登录获取token，再用token访问其他接口），从响应中提取数据是必备技能。

1. 正则表达式提取器：

   • 在需要提取数据的请求下，右键添加“后置处理器” -> “正则表达式提取器”。
   • 引用名称：定义一个变量名，如token。
   • 正则表达式：编写匹配规则。例如，如果响应是{"access_token": "abc123", "expires_in": 3600}，想提取abc123，表达式可以是："access_token": "(.+?)"。(.+?)是捕获组，匹配非贪婪的一个或多个任意字符。
   • 模板：$1$表示使用第一个捕获组。
   • 匹配数字：1表示取第一个匹配项。
   • 在后续请求中，使用${token}来引用这个值。

2. JSON提取器（需安装插件）：

   • 对于JSON响应，使用JSON提取器更简单直观。
   • 添加“后置处理器” -> “JSON Extractor”。
   • 变量名称：如userId。
   • JSON路径表达式：使用JSONPath语法，如$.data.id。
   • 同样，后续使用${userId}引用。

6.3 常见错误与解决方案实录

以下是我在实战中踩过的一些坑和解决办法：

• 报错：java.net.BindException: Address already in use: connect

  • 原因：Windows系统下，客户端端口耗尽。JMeter每发一个请求会占用一个本地临时端口，高并发下很快用完。
  • 解决：
    1. 增加Windows的临时端口范围（需管理员权限）：

       netsh int ipv4 set dynamicport tcp start=10000 num=55000

    2. 减少JMeter的连接保持时间。在“HTTP请求”的“高级”选项卡中，勾选“Use KeepAlive”并设置一个较短的值，或者直接不勾选。
    3. 在jmeter.properties中设置httpclient4.time_to_live为一个较小的值（如60秒）。

• 报错：Out of Memory或测试运行时JMeter卡死

  • 原因：JMeter的JVM堆内存不足，或者监听器（如“察看结果树”）记录了太多数据。
  • 解决：
    1. 如前所述，调整jmeter.bat中的HEAP参数，增加-Xmx值。
    2. 务必在正式压测时，禁用或删除“察看结果树”、“用表格查看结果”这类保存详细数据的监听器。只保留“聚合报告”、“汇总报告”等聚合型监听器。
    3. 在非GUI模式下运行。

• 测试结果中吞吐量（Throughput）异常低

  • 原因：
    1. 定时器设置不当：在线程组级别添加了固定定时器，导致每个线程每次循环都等待，严重拉低TPS。定时器应加在具体的事务控制器或请求下。
    2. 断言或后置处理器过于复杂：特别是使用了耗时的JSR223脚本。
    3. 测试机资源瓶颈：单台测试机的网络、CPU已满，无法产生更大压力。监控测试机资源使用情况，考虑分布式压测。
    4. 响应时间过长：被测系统本身处理慢，导致单线程循环速度慢。需要优化被测系统。

• 如何模拟不同的思考时间和业务比例？

  • 思考时间：使用“高斯随机定时器”，设置合理的偏差和固定延迟，模拟真实用户操作间隔。
  • 业务比例：使用“吞吐量控制器”。例如，在一个线程组内，你可以放置两个“吞吐量控制器”，一个设置为“百分比”70%，里面放“浏览商品”的请求；另一个设置为30%，里面放“下单支付”的请求。这样就能模拟7:3的业务比例。

最后，性能测试是一个需要严谨态度和不断实践的过程。JMeter只是一个工具，更重要的是你设计的测试场景是否贴近真实，你对结果的分析是否深入，以及你与开发、运维团队协作定位问题的能力。从今天开始，试着为你负责的下一个接口或应用，设计并执行一次小规模的压测吧，那份直观的数据报告，会比任何猜测都更有说服力。