前言
在使用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性能测试过程应用。
