来看看Jmeter官网给我们的提示之如何减少资源使用

本文分享了JMeter官网提供的性能测试最佳实践,包括使用CLI模式而非GUI模式进行压测、减少监听器的使用、避免在负载测试中使用查看结果树等功能、采用CSV数据文件进行参数化等九项建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


前言

Jmeter大家都有所了解,官网中都给我了哪些建议呢,一起来看看吧


一、官网地址

地址:https://jmeter.apache.org/usermanual/best-practices.html

在这里插入图片描述

二、最佳实践

推荐这个下面的内容最好都去了解下,这里我们看下如何减少资源需求,先看下原文
在这里插入图片描述
嗯。。。我英语不太溜,就直接翻译了
在这里插入图片描述

1.使用CLI模式

使用命令模式去运行。
我们每次启动Jmeter的时候,黑窗口就会有一些英文,不知道你们注意过没,大概翻译下,
不要使用GUI模式(图形化界面)去进行压测,仅仅用它作为创建测试和调试,如果进行压测的话,最好使用CLI模式,下面是命令
在这里插入图片描述

jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]
-n:非GUI模式执行
-t:测试计划保存路径
jmx file:测试计划文件名
-l:log,生成测试结果文件
results file:结果的文件名,有jtl和csv格式,到时候打开jmeter导入文件,选择jtl就能看到结果
-e:生成测试报告
-o:测试报告生成文件夹,文件夹必须为空,参数为文件夹路径
path to web report folder:生成HTML报告的路径

例子:

jmeter -n -t D:\yace\kjyace\script\08_test.jmx -l D:\yace\report\08_test.jtl -e -o D:\yace\report\08

这是生成的HTML报告
在这里插入图片描述
这是导入jtl文件的聚合报告
在这里插入图片描述

2.尽可能少地使用监听器

尽可能少地使用监听器;如果使用上面的-l标志,它们都可以被删除或禁用。
没有查看查看结果树的话,可能不便于我们排查问题,当请求比较多的时候,可以选择只查看错误日志,也可以减少一些资源。
在这里插入图片描述

3.不要在负载测试期间使用“查看结果树”

不要在负载测试期间使用“查看结果树”或“在表中查看结果”侦听器,仅在脚本编写阶段使用它们来调试您的脚本,这个问题同上面。

4.使用CSV data

与其使用大量相似的采样器,不如在循环中使用相同的采样器,并使用变量(CSV 数据集)来改变样本。[Include Controller 在这里没有帮助,因为它将文件中的所有测试元素添加到测试计划中。]
额。。。这里我也没太看懂,个人见解,需要参数化的时候,可以使用csv来处理,如果多个线程或请求使用同一个文件,可以把它放在测试计划下面,避免每次都去循环读取。
例如:
在这里插入图片描述

5.不要使用功能模式

之前还不知道这个模式在哪里,就在测试计划下面,因为我的已经是中文了,翻译之后叫函数测试模式,下面也给出了提示:只有当你需要记录每个请求从服务器取得的数据到文件时才需要选择函数测试模式。选择这个选项很影响性能。

在这里插入图片描述

6.使用 CSV 输出而不是 XML

使用 CSV 输出而不是 XML。平时一般保存结果文件的时候用的都是csv格式,xml几乎没用过,有了解的小伙伴可以留言探讨一下。

7.只保存您需要的数据

只保存您需要的数据。

8.尽可能少地使用断言

尽可能少地使用断言。额。。。这点对我来说有点难,因为不去做断言的话,我也不太清楚接口返回是对是错。

9.使用性能最好的脚本语言

使用性能最好的脚本语言(参见 JSR223 部分)。JSR223 有这几种语言,平时beanshell用的比较多,网上看了别人的对比,与Beanshell和Javascript相比,Groovy表现更好,有余力的小伙伴可以去对比下,是我们的性能测试指标更加准确。

JSR223 PostProcessor - Beanshell
JSR223 PostProcessor - Javascript
JSR223 PostProcessor - Groovy

有些也是第一次见到,翻译着对比看看,受到的启发也不少呢!给的建议很不错,我们在使用过程中可以往这方面去思考,写出不错的脚本!

### 如何解读和分析 JMeter 的聚合报告 #### 报告概述 JMeter 是一款功能强大的开源性能测试工具,其 **聚合报告** 提供了关于系统性能的关键指标。这些指标能够帮助我们评估系统的响应时间、吞吐量以及错误率等方面的表现。 --- #### 关键参数解释 1. **Label** 表示请求的名称。如果多个请求具有相同的名称,则它们会被视为同一组并合并统计数据[^2]。 2. **# Samples** 显示执行此请求的总次数。它反映了负载测试期间发送给目标服务的具体请求数量[^1]。 3. **Average (平均响应时间)** 记录所有样本的平均响应时间(单位通常为毫秒)。较低的数值意味着更好的性能表现[^4]。 4. **Median (中位数响应时间)** 所有采样数据按升序排列后的中间值。当分布不对称时,这一项可能比平均值更能反映真实情况。 5. **90% Line / 95th Percentile** 百分位线表示一定比例下的最大响应时间。例如,“90% line”指90%的请求完成所需的时间不超过该值[^2]。 6. **Min & Max (最小/最大响应时间)** 分别记录最快一次成功请求所花费时间和最长的一次请求耗时。这两个极端值有助于识别异常状况或瓶颈所在位置。 7. **Error % (错误百分比)** 统计失败请求占总数的比例。高误差率提示可能存在严重问题需进一步排查解决[^4]。 8. **Throughput (吞吐量)** 度量每秒钟处理多少事务或者传输的数据量大小(KB/sec 或者 Requests/sec),用于衡量服务器的工作效率[^1]。 9. **Received/Sent KBs** 展示客户端接收及向服务器端发出的数据总量(千字节数)。这对于带宽消耗研究很有意义[^3]。 --- #### 数据生成机制 无论是实时生成还是基于`.jtl`日志文件创建的聚合报表,底层逻辑都依赖于 `StatGraphVisualizer.add(sampleResult)` 方法来填充表格行内容。每次接收到新的请求结果对象 (`SampleResult`) 后都会更新对应条目的统计信息。 此外,在某些场景下为了更直观地观察资源占用变化趋势,还可以借助 PerfMon 插件采集 CPU 使用率等相关硬件状态图谱作为补充材料辅助决策过程[^3]。 --- #### 实际应用建议 通过上述各项核心字段组合起来进行全面考量可以帮助工程师们快速定位潜在风险点;同时也可以设置合理的阈值范围以便及时发现偏离正常水平的情况从而采取相应措施加以改进优化整个 IT 架构体系结构设计思路方向等等[^4]。 ```python import jmeter_analysis as ja report_data = ja.load_aggregate_report('path/to/report.csv') summary_stats = { 'avg_response_time': report_data['average'].mean(), 'error_rate': (report_data['errors'] / report_data['samples']).sum() * 100, } print(f"Summary Statistics:\n{summary_stats}") ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值