能不能让我知道JMeter机器最多可以处理多少个虚拟用户负载？
如果我们考虑一台具有无限处理器RAM的机器。
答案 0 :(得分：0)
单个实例的内容类似于2,147,483,647（32-bit signed integer的最大值）。
如果您选择Distributed Testing-每个JMeter从属引擎都可以拥有那么多。
答案 1 :(得分：0)
没有“无限的处理器，RAM”，但是即使有，也将至少有3个其他因素：
理论上，由于线程数是Integer，所以可能的最大值是Integer.MAX_VALUE，但这是荒谬的。
由于线程数取决于许多因素，因此无法回答您的问题，请参见以下答案：
您应该始终在1台计算机上进行校准，以通过观察CPU，交换...来查看您的计划可以处理多少线程。
然后，您可以使用云解决方案或分布式测试来增加计算机数量。
如果您想了解有关负载测试的更多信息，此book可以为您提供帮助。
答案 2 :(得分：0)
同意，这里确实有太多变量无法提供答案。由于每个虚拟用户都从有限的CPU，DISK，MEMORY和NETWORK资源池中占用一定数量的资源，因此虚拟用户的构建方式将产生重大影响。
您的基础硬件也会产生影响。例如，对于以太网，如果您在冲突域中而不是在交换域中，则可能会发现，一旦超出网络资源池的35％，错误和繁忙率就会增加，从而降低吞吐量，而您可能会有其他资源可用。
其他示例，当您达到85％的CPU时，您通常会在CPU上遇到某种程度的排队。会引起注意吗？如果主机繁忙，则可能导致虚拟用户变慢。哎呀，我什至观察到在8通道盒上，用于光纤通道引脚的所有中断服务到处理器零的磁盘接口构造不良。一旦零饱和，其他所有可伸缩性就完成了。
在通常情况下，最大化存储空间是一个坏主意，因为随着资源池的缩小，虚拟用户会出现延迟问题，而操作系统则必须代理更高的访问权限来访问有限的剩余池。对于所有有限项都是如此。通常，我绝不会在少于三台主机的情况下运行测试：两台用于主负载，一台用于每种类型的单个虚拟用户的控制集。这有助于我在测试执行周期内了解主机是否导致虚拟用户延迟，因为控制组和非控制主机的降级速度均应相同。如果没有，则需要解决主机问题。
我尝试遵循的另一条经验法则是，在执行测试期间，不超过负载生成器主机上正在使用的可用资源池的50％。在这种情况下，我比同龄人更为保守，后者通常会提高到75-80％。当我发现问题时，我希望测试是一致的，可重复的和高度可辩护的。开发人员就像父母一样-当您发现他们的代码有问题时，他们自然会责怪测试。他们可以整天挑选我的测试，他们会发现记录在案的控制因素，可重复性，记录的初始条件，检查预期的数据结果（不仅仅是HTTP 200）。该测试不需要眼镜，您的代码（子代码）很难看。
答案 3 :(得分：0)
让我们在实践中进行检查：
将Number of Threads设置为2147483648（Integer.MAX + 1）并运行测试。 JMeter显示日志：
INFO o.a.j.e.StandardJMeterEngine: Starting 0 threads for group Thread Group.
将Number of Threads设置为2147483647（Integer maximum value）。测试运行成功
INFO o.a.j.e.StandardJMeterEngine: Starting 2147483647 threads for group Thread Group.
因此， 2147483647 -JMeter可以在一台计算机上启动 的线程数。
但是如果考虑到您可能在云服务中Remote testing运行scale your JMeter test，该怎么办：
注意：所有服务器都运行相同的测试计划。 JMeter不会在服务器之间分配负载，每个服务器都运行完整的测试计划。因此，如果您设置1000个线程并拥有6个JMeter服务器，最终将注入6000个线程。