众所周知，LoadRunner在开箱即用的情况下可以进行大量测试，因此可以很好地运行。

在以下情况下，JMeter通常会遇到高吞吐量，高线程测试的问题：

1. 使用一台具有大量侦听器的计算机以GUI模式运行-这会占用内存。
2. 在默认配置中使用分布式模式（版本低于2.9），在负载生成器上运行测试没有问题，但是将结果发送到主计算机存在瓶颈。据报道，此问题已在2.9中解决，吞吐量据称在2.10中更高。

问题是，解决JMeter的问题并不难。这只是最佳实践的问题。

1. 从命令行运行，不要使用大量的侦听器。精益和均值模式。
2. 在分布式执行中，使用批处理模式可以减少版本<2.9中写入一个文件的样本量，或使用默认值> = 2.9。
3. 确保在足够的硬件上分发测试。顺便说一下，LoadRunner也是如此。

您应该阅读这两个文档以获得其他最佳实践：

• http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
• http://jmeter.apache.org/usermanual/best-practices.html

LoadRunner在高负载下也有问题-
分析和数据整理阶段可能要花几个小时（从字面上看），您无法解决这个问题。如果您要分析的数据太多，也可能会遇到内存问题。Jmeter在结果分析方面不那么全面，但速度更快。

如果您真的需要进行大量测试，那么我编写了一个脚本，该脚本有效地为您提供了使用JMeter进行无限扩展的能力-
我已经测试了多达2万名用户，并在50台服务器上每秒运行8000次。这是“无限的”，因为它通过运行许多相互隔离的测试来工作，这些测试直到测试结束才互相交谈，这样就不会出现编译结果的瓶颈。但是总有另一个瓶颈…