官方文档（Best Practices-最佳实践部分摘选）：https://jmeter.apache.org/usermanual/best-practices.html

一、线程组

Use the correct Number of Threads（使用正确的线程数）

硬件能力以及测试计划设计都将影响使用JMeter有效运行的线程数量，这个数字还取决于服务器的速度（更快的服务器使JMeter工作更努力，因为它返回响应更快），与任何负载测试工具一样，如果不正确地调整线程的数量，您将面临“Coordinated Omission”问题，这会导致错误或不准确的结果。如果需要大规模负载测试，请考虑使用分布式模式（或不使用分布式模式）在多台机器上运行多个非GUI JMeter实例。当使用分布式模式时，结果文件将在Controller节点上组合，如果使用多个自治实例，则示例结果文件可以组合用于后续分析。为了测试jmeter在给定的平台表现如何，可以使用JavaTest取取器，它不需要任何网络访问，因此可以给出关于可达到的最大吞吐量的一些想法。

JMeter有一个选项可以延迟线程创建，直到线程开始采样，即在任何线程组延迟和线程本身的ramp-up time之后。这允许一个非常大的线程总数，前提是没有太多同时活动的线程。

------来自官方文档：https://jmeter.apache.org/usermanual/best-practices.html

每个线程均独立运行测试计划。因此， 线程组常用来模拟并发用户访问。假如客户机没有足够的能力来模拟较重的负载，可以使用Jmeter的分布式测试功能来通过一个Jmeter控制台来远程控制多个Jmeter引擎完成测试。

在“测试计划”上右键 【添加】-->【Threads(Users)】-->【线程组】

二、避免人为的压测服务器资源浪费

Reducing resource requirements（减少资源需求）

关于减少资源使用的一些建议：

• 使用非GUI模式：jmeter -n -t test.jmx -l test.jtl
• 使用尽可能少的Listeners; 如果使用上面的-l选项，可以删除或禁用它们。
• 在加载测试期间，请勿使用"View Results Tree" 或者"View Results in Table" 侦听器，仅在脚本编写阶段使用它们来调试脚本。
• 在循环中使用相同的采样器，而不是使用大量类似的采样器，并使用变量（CSV数据集）来改变样本。[Include Controller在这里没有帮助，因为它将文件中的所有测试元素添加到测试计划中。]
• 不要使用functional模式
• 使用CSV输出而不是XML
• 仅保存您需要的数据
• 使用尽可能少的断言
• 使用性能最佳的脚本语言（参见JSR223部分）

如果您的测试需要大量数据 - 特别是如果需要随机化 - 请在可以使用CSV数据集读取的文件中创建测试数据。这可以避免在运行时浪费资源

三、开发脚本函数（TODO）

等实践后更新

原文地址：https://www.cnblogs.com/yy-cola/p/9669603.html