杰米特 |最大虚拟用户容量

Question

能否让我知道 JMeter 机器最多可以处理多少虚拟用户负载？

如果我们考虑一台具有无限 PROCESSOR、RAM 的机器。

Answer 1

对于单个实例，它类似于2,147,483,647（32-bit signed integer 的最大值）。

如果您选择Distributed Testing - 您将能够为每个 JMeter Slave 引擎拥有那么多。

Answer 2

没有“无限的 PROCESSOR ，RAM”，但即使有，至少还有 3 个附加因素：

• 磁盘
• 网络
• 这种规模的潜在问题

理论上，由于线程数是Integer，因此可能的最大值是Integer.MAX_VALUE，但这是荒谬的。

由于线程数取决于许多因素，因此无法回答您的问题，请参阅此答案：

• What is the highest number of threads that is reasonable to simultaneously run in Jmeter?

您应该始终在 1 台机器上进行校准，以通过观察 CPU、交换来查看您的计划可以处理多少线程...

然后您可以通过使用云解决方案或分布式测试来增加机器数量。

如果您想了解有关负载测试的更多信息，book 可以为您提供帮助。

Answer 3

同意，这里确实有太多变数无法提供答案。由于每个正在运行的虚拟用户都会从 CPU、磁盘、内存和网络的有限资源池中占用一定数量的资源，因此您的虚拟用户的构建方式会产生重大影响。

您的底层硬件也会产生影响。例如，对于以太网，如果您处于冲突域与交换域中，您可能会发现一旦超过 35% 的网络资源池，您的错误和繁忙率就会增加，从而在您可能有其他可用资源的情况下降低吞吐量。

其他示例，一旦达到 85% 的 CPU，您通常会遇到某种程度的 CPU 排队。会引人注目吗？也许如果是一个繁忙的主机，那么会导致您的虚拟用户变慢。哎呀，我什至观察到光纤通道引脚的磁盘接口构造不佳，所有中断服务都到 8 路盒上的处理器零。一旦零饱和，所有其他可扩展性就完成了。

在一般实践中，最大化盒子是一个坏主意，因为随着资源池的缩小，虚拟用户会出现延迟问题，然后操作系统必须代理对有限的剩余池的更高访问权限。这适用于所有有限项。作为一般经验法则，我从不使用少于三台主机运行测试：两台用于主要负载，一台用于每种类型的单个虚拟用户的控制集。这有助于我在测试执行周期内了解我的主机是否导致我的虚拟用户延迟，因为控制组和非控制主机应该以相同的速率降级。如果没有，则需要解决主机问题。

我尝试遵守的另一条经验法则是，在执行测试期间，负载生成器主机上使用的可用资源池不超过 50%。在这种情况下，我比同龄人更保守，他们通常会推动到 75-80%。当我发现问题时，我希望测试是一致的、可重复的和高度防御性的。开发人员就像父母一样——当你发现他们的代码有问题时，他们自然会责怪测试。他们可以整天挑选我的测试，他们会找到记录良好的控制因素、可重复性、记录的初始条件、检查预期的数据结果（不仅仅是 HTTP 200）。测试不需要眼镜，你的代码（孩子）很丑。

Answer 4

让我们在实践中检查一下：

1. 对于最简单的空测试计划添加Debug Sampler。

2. 将Number of Threads 设置为2147483648 (Integer.MAX + 1) 并运行测试。 JMeter 显示日志：

   INFO o.a.j.e.StandardJMeterEngine: Starting 0 threads for group Thread Group.

3. 将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 个线程。