前言
在使用jmeter进行性能测试实践时,必须要注意jmeter的一些局限性,充分使用jmeter优势功能,这样才能更好的发挥出jmeter的能力。
- 要注意限制线程数
- 使用代理服务器
- 使用变量
- 减少不必要的资源需求
- 检查jmeter日志
- 清除CSV Data Set Config中的本地路径(用相对路径)
- 遵循统一的命名规范
jmeter是有其局限性的,特别是其分布式运行环境时,所以需要注意其局限性,以便更灵活的应用jmeter进行性能测试。
限制线程数
一般情况下,建议限制jmeter的的线程数在300及以内。
当然,如果你的机器硬件足够好,可以将该值往上提升。不过从笔者的实践经验来看,线程数低于300能更好的发挥出jmeter的性能。
使用代理服务器
如果你的条件运行,建议你使用代理服务器,这样可以记录你的请求,方便你进一步分析请求。
当然,笔者在实践过程中从来不用,主要是笔者在实践过程,一般都是直接抓包分析请求。
笔者也建议各位少用,多手工抓包分析,一则提升能力,二则能进一步熟悉系统技术业务。更有利于深刻理解系统业务。
这里提出这个注意点,是因为不少jmeter用户还是喜欢使用代理服务器来进行录制分析。
使用变量
为什么要多使用变量?简而言之,
- 能让你更好的控制测试过程中的数据
- 同时能更加灵活的适应不同环境
- 增强可维护性。
减少不必要的资源需求
怎么减少必须要的资源需求呢?
在使用jmeter进行性能测试时,你应该:
- 使用non-GUI模式,即使用命令行模式
- 在压测时,要禁用诸如View Result Tree这类的监听器,因为这类监听器非常耗内存
- 在压测时,同样要禁用所有的图形结果监听器
- 使用CSV格式的监听器来采集结果
- 如果压测时间很长,请只采集必需的结果,对于其他非必须的信息尽量不要采集
当然了,在调试jmeter脚本时,各种监听器还是需要的,但进入压测模式时,请务必将各种监听器禁用
检查jmeter日志
在使用jmeter时,任何错误都会记录至日志文件中,所以不管什么时候请仔细查看日志信息。认真去分析日志,这是解决调试和压测过程中出现错误或异常时必须掌握的能力
清除CSV Data Set Config中的本地路径
这个是什么意思呢? 例如,你在本机调试jmeter脚本时,使用了C:/data.csv文件,子啊CSV Data Set Config中使用了完整的C:/data.csv路径,当你在分布式压测或是别人使用你的jmeter脚本时,可能在C盘下并没有该文件,这是会导致你的jmeter脚本运行失败。 为了避免这里的情况,请使用相对的路径方式,或是其他能避免因路径问题而导致运行失败的情况。
为什么特意提出这点,笔者在实践过程中,经常碰到这类小仔细问题,导致运行失败。
遵循统一的命名规范
统一的命令规范,能让你的jmeter项目更好维护,也能让其他人更加理解你的项目。
总结
上述都是些基本要注意的事项,都是要注意的一些细节经验,从本篇开始,jmeter系列将进入综合实践篇了。
笔者在综合实践篇中不会介绍各种基本概念,将会侧重jmeter实践和其他各种性能测试过程诊断分析的一些经验。所有涉及的专题概念和工具也好都不会进行详细的介绍,只结合具体jmeter性能测试过程应用。
原创文章,未经允许,请勿转载。
网友评论