【JMeter详解】

JMeter详解

Apache JMeter 是一个开源的、100%纯Java应用程序，设计用于负载测试和性能测量。它最初是为测试Web应用程序而设计的，但后来扩展到其他测试功能。JMeter可以用来对静态和动态资源（如静态文件、Servlets、Perl脚本、Java对象、数据库和查询、FTP服务器等）进行性能测试。

主要特点：

• 多样的采样器：支持HTTP, HTTPS, FTP, JDBC, LDAP, WebService, JMS, SMTP, POP3, IMAP等多种协议。
• 灵活的监听器：提供多种结果查看方式，例如图形化显示、表格形式、树形结构等。
• 丰富的配置元件：如CSV Data Set Config, User Parameters, HTTP Cookie Manager等，可以帮助设置测试计划。
• 逻辑控制器：允许你定义执行流程，比如循环、条件判断、事务控制器等。
• 分布式测试：支持多个JMeter服务器协同工作，以生成更大的负载。
• 可扩展性：通过插件机制，用户可以编写自己的插件来扩展JMeter的功能。
• 参数化和数据驱动测试：可以通过外部文件或内置函数实现变量替换，从而支持数据驱动测试。

JMeter与其他工具的对比

与LoadRunner对比

• 成本：JMeter是免费且开源的，而LoadRunner是商业软件，需要购买许可证。
• 易用性：LoadRunner拥有更直观的图形用户界面，对于新手来说可能更容易上手；JMeter虽然也有GUI，但对于复杂任务，它的学习曲线可能会更陡一些。
• 协议支持：LoadRunner支持更多的协议和应用类型，特别是对于企业级的应用程序和非HTTP/HTTPS协议的支持更为广泛。
• 社区和支持：LoadRunner由Micro Focus官方提供技术支持，而JMeter依赖于活跃的开源社区。
• 性能：在某些情况下，LoadRunner可能比JMeter表现得更好，尤其是在处理大规模并发用户时。

与Gatling对比

• 编程语言：Gatling是基于Scala编写的，并且其测试脚本也是使用Scala DSL（领域特定语言），这使得它更适合熟悉Scala或愿意学习Scala的开发者；JMeter则是完全图形化的，不需要编程知识。
• 报告和分析：Gatling提供了非常漂亮的实时HTML报告，易于理解和分享；JMeter的结果呈现则更加多样化，但需要额外的配置才能达到类似的效果。
• 性能和效率：Gatling以其高效的性能著称，特别是在高并发场景下；JMeter也可以做同样的事情，但在相同条件下，Gatling通常能处理更多的虚拟用户。

与Locust对比

• 编程语言：Locust是Python编写的，使用Python脚本来定义用户行为，适合程序员使用；JMeter则不依赖任何编程语言，所有操作都可以通过GUI完成。
• 灵活性：由于Locust是代码驱动的，因此它可以非常灵活地模拟用户行为，容易实现复杂的业务逻辑；JMeter虽然也有一定的灵活性，但在实现同样复杂的逻辑时可能需要更多的配置。
• 社区和文档：两者都有活跃的社区，但是JMeter作为一个成熟的项目，拥有更广泛的文档和支持资源。

安装使用：

1. 安装与配置

下载JMeter

• 访问Apache JMeter官方网站下载最新版本的JMeter。

• 

• 解压下载的文件到你选择的目录。

配置环境变量（可选）

• 如果你想在命令行中直接运行JMeter，可以将JMETER_HOME/bin添加到系统的PATH环境变量中。

• 

• 

• 

2. 创建测试计划

启动JMeter

• 在解压后的JMeter目录下的bin文件夹中，双击jmeter.bat（Windows）或运行./jmeter（Linux/Mac）启动JMeter GUI。

新建测试计划

• 打开JMeter后，点击“File”->“New”来创建一个新的测试计划。
• 你可以给测试计划命名，并根据需要设置一些全局参数，如是否独立运行每个线程组、函数测试模式等。
• 

3. 配置线程组

• 在测试计划中右键点击，选择“Add”->“Threads (Users)”->“Thread Group”来添加一个线程组。

• 设置线程数（即模拟的用户数量）、Ramp-Up Period（增加用户的速率）和循环次数等参数。例如，如果你想模拟100个用户，每秒启动10个新用户，持续时间15分钟，则可以这样配置：

  • 线程数: 100

  • Ramp-Up Period: 10秒

  • 循环次数: 无限 或者基于你的测试需求设定具体的循环次数

    

4. 添加采样器（Sampler）

• 在线程组下添加HTTP请求采样器或其他类型的采样器，这取决于你要测试的服务类型。

• 对于Web应用，通常是添加“HTTP Request”采样器。你需要填写目标URL、请求方法（GET/POST等）、参数等信息。

  

5. 配置监听器

• 监听器用于收集和展示测试结果。常见的监听器包括“View Results Tree”、“Summary Report”、“Aggregate Report”等。

• 你可以通过右键点击测试计划或线程组，然后选择“Add”->“Listener”来添加监听器。

  

6. 添加配置元件（可选）

• 根据需要添加其他配置元件，比如HTTP Header Manager来管理HTTP头部信息，CSV Data Set Config来读取外部数据文件作为测试输入等。

7. 添加逻辑控制器（可选）

• 逻辑控制器允许你控制采样器的执行顺序，实现更复杂的测试场景。例如，你可以使用Loop Controller来重复执行某些操作，或者使用If Controller根据条件执行特定的操作。

8. 运行测试

• 保存你的测试计划为.jmx文件。

• 为了获得最佳性能，建议使用非GUI模式运行测试，尤其是在高负载情况下。你可以使用如下命令行指令：

  jmeter -n -t <test_plan>.jmx -l <results_file>.jtl
  

• -n表示以非GUI模式运行；-t后面跟的是测试计划文件路径；-l指定结果日志文件的位置。

  

9. 分析测试结果

• 测试完成后分析JMeter的测试结果是性能测试过程中至关重要的一步，以下是详细的步骤和建议。

1. 使用监听器查看初步结果

Summary Report 和 Aggregate Report

• Summary Report 提供了每个采样器（请求）的基本统计数据，包括样本数、平均响应时间、最小/最大响应时间、吞吐量（每秒事务数）、错误率等。
• Aggregate Report 类似于Summary Report，但它还提供了90%线、中位数等更详细的统计信息，有助于评估大多数用户的体验。

View Results Tree

• View Results Tree 允许你查看单个HTTP请求的详细信息，包括请求头、响应数据、响应码等。这对于调试特定问题非常有用。

Response Time Graph

• Response Time Graph 显示了响应时间随时间变化的趋势，可以帮助识别响应时间突然增加的时间点，这可能是由于服务器资源耗尽或其他原因引起的。

Transactions per Second (TPS)

• Transactions per Second (TPS) 图表展示了每秒钟完成的事务数量，对于了解系统的吞吐能力非常重要。

Hits Per Second

• Hits Per Second 图表展示了每秒钟的请求数量，反映了系统处理请求数量的能力。

Response Codes per Second

• Response Codes per Second 图表显示了每秒钟返回的不同HTTP状态码的数量，帮助识别失败的请求。

Active Threads Over Time

• Active Threads Over Time 图表展示了活动线程数随时间的变化，反映了并发用户数的变化。

Bytes Throughput Over Time

• Bytes Throughput Over Time 图表显示了数据传输速率随时间的变化。

2. 生成HTML报告

JMeter可以生成一个全面的HTML报告，包含多个图表和表格，提供对测试结果的深入分析。要生成HTML报告，请使用以下命令：

jmeter -g <results_file>.jtl -o <output_folder>

HTML报告通常包含以下几个部分：

• Overview：概述了整个测试期间的关键指标，如总样本数、错误率、平均响应时间等。
• Response Times Over Time：显示了响应时间随时间的变化趋势。
• Latencies Over Time：展示了延迟时间随时间的变化趋势。
• Throughput Over Time：显示了吞吐量随时间的变化。
• Hits Per Second：展示了每秒点击次数，反映了系统处理请求数量的能力。
• Response Codes per Second：显示了每秒钟返回的不同HTTP状态码的数量，帮助识别失败的请求。
• Active Threads Over Time：展示了活动线程数随时间的变化，反映了并发用户数的变化。
• Bytes Throughput Over Time：显示了数据传输速率随时间的变化。
• Connect Time vs. Latency：比较了连接时间和延迟时间，有助于分析网络性能。
• Response Time Percentiles：提供了不同百分位数的响应时间分布，如50%, 75%, 90%, 95%, 99%等，这对于理解大部分用户的实际体验非常有帮助。

3. 分析关键指标

• 响应时间：

  • 平均响应时间 是一个重要的指标，但要注意不要只看平均值。90%或95%的响应时间更能反映大多数用户的实际体验。如果这些高百分位数的响应时间显著高于平均值，可能表明存在长尾效应，即少数请求导致了较慢的响应时间。

• 吞吐量：

  • 吞吐量衡量系统在单位时间内能处理的请求数量。较高的吞吐量意味着系统能够处理更多的流量。

• 错误率：

  • 任何非2xx或3xx的HTTP状态码都被视为错误。高错误率可能表示应用程序存在问题，需要进一步调查。

• 并发用户数：

  • 观察并发用户数与响应时间和吞吐量之间的关系，可以帮助确定系统的最大承载能力。

• 资源利用率：

  • 虽然JMeter本身不直接监控服务器资源，但你可以结合其他工具（如Prometheus, Grafana, 或者服务器自带的监控工具）来监控CPU、内存、磁盘I/O、网络带宽等资源的使用情况。这有助于判断性能瓶颈是否由资源限制引起。

4. 识别性能瓶颈

• 服务器端：

  • 检查服务器的日志文件，寻找异常或错误信息。使用监控工具查看服务器资源的使用情况，确定是否有资源耗尽的情况。

• 客户端：

  • 分析JMeter的测试结果，特别是响应时间和错误率，查找是否存在某些请求特别慢或频繁失败。

• 网络：

  • 考虑网络延迟和丢包的可能性，特别是在跨区域或跨国界的测试环境中。使用ping、traceroute等工具检查网络状况。

• 代码优化：

  • 根据分析结果，可能需要对应用程序代码进行优化，比如改进数据库查询、减少不必要的HTTP请求、优化前端渲染等。

10. 持续改进

• 根据测试结果调整应用程序代码或服务器配置，优化性能瓶颈。
• 重新运行测试，对比前后差异，确保改进措施有效。

意事项

• 不要在GUI模式下进行大规模负载测试，因为GUI会消耗大量资源，影响测试的准确性和效率。
• 合理规划线程数和Ramp-Up Period，避免一次性启动过多线程导致服务器过载。
• 考虑分布式测试，如果你的测试需要模拟大量的并发用户，可以考虑使用多台机器组成的JMeter集群来进行分布式测试。

原文地址===》JMeter详解