JMeter最多可以模拟多少测试用户数?

本文我们将讨论一个确切说没有准确答案的问题 - 即我们使用Apache JMeter™最多可以模拟多少用户来做测试? 像JMeter本身的限制一样，这样的限制因素有很多. 它取决于你机器的性能和网络、性能脚本的复杂度、目标模拟用户的数量等.

在接下去的几节中，我们会遇到不同的JMeter限制并找到变通的方法来克服它们.

我们将会使用一个很普通的本地机器:

• CPU: 1.4 Ghz Intel Core i5
• 内存: 4GB 1600 MHz

创建一个使用50个用户的性能脚本

首先我们需要创建一个可以发现不同JMeter限制的性能脚本. 这个简单的脚本会模拟将负载压到 http://blazedemo.com/ 这个web应用上. 我们所需要做的就是创建:

1. 线程组 - 由50个用户开始, 爬坡期间为2分钟，测试持续5分钟.

2. HTTP 请求取样器 - 命名为 “Find flights request,” 发送一个Post请求到 blazedemo.com/reserve.php ，Post参数及数据为fromPort=Paris 和toPort=Buenos Aires.

3. 查看结果树监听器 - 用于调试目的.

4. 图结果监听器 - 用于验证负载度量.

5. 通过Loop Controller将Http请求取样器置为无限循环. 这样就会hold住每个线程的负载直到整个测试完成.

6. 添加一个断言元素来验证响应. 根据我们的请求，我们应该会得到一个来自“Virgin America” 航空公司的航班. 我们可以使用它作为一个文本响应断言.

现在我们的脚本已经创建完成了并可以开始运行. 点击"start" 按钮开始执行.

5 分钟之后, 你应该能看到测试已成功并且所有的线程也被创建和销毁了, 是不是很容易?

使用500个用户来运行你的负载测试

现在让我们用500个用户来执行同样的测试. 将线程组里的用户数改成 500个线程, 并确保脚本能成功运行.

使用1000个用户来运行你的负载测试

在上个测试中, 我们使用了一个不太强劲的手提电脑模拟了500个用户. 这样的负载对一个用户量很少的应用来讲通常是足够的. 但如果我们要模拟更多的用户会怎样? 这次让我们用1,000个用户来执行同样的测试.

这次不幸的事发生了. 当我们将用户增加到743个时, 我的JMeter应用界面就动弹不得并失去了响应. 在JMeter 日志里出现了这样的错误日志:

java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid1824.hprof ... Heap dump file created [147668693 bytes in 39.846 secs] Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread Group 1-743"

这个错误是指我们已经用完了JMeter应用分配给Java堆的可用空间.

提示 #1: JMeter监听器只应该做调试目的使用

我们已经遇到了第一个限制，从这个限制里我们得到的建议是: “JMeter监听器只应该做调试目的使用!”

JMeter的监听器自身给本地机器带来了很多与测试无关的负载, 它在堆里创建了很多的对象并很可能占据了大多数的堆空间. 有许多其它的方式可以做到无需产生大量的负载到本地机器来监控你的脚本. 在这篇文章中(https://www.blazemeter.com/blog/3-easy-ways-to-monitor-jmeter-non-gui-test-results?utm_source=blog&utm_medium=BM_blog&utm_campaign=whats-the-max-number-of-users-you-can-test-on-jmeter),你可以找到三个正确的方法.

但我们的目标是找出JMeter可以模拟多少用户. 所以我们要做的是去掉监听器并验证脚本是否能成功执行并满足1000用户的目标负载.

我们运行后发现脚本还是动弹不得. 我们发现这次失败发生在当用户数增加到921个时:

java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid2083.hprof ... Heap dump file created [150444856 bytes in 12.757 secs] Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread Group 1-921"

提示 #2: 将JMeter测试运行于非GUI模式

我们看到这次已经很接近目标了，但还是不能模拟1000用户的负载. 从这个案例中我们得到了下一个建议: 即当你需要模拟一个更大的负载测试时，应该“将JMeter性能测试运行在非GUI模式” . 使用JMeter GUI可以很好的创建、编辑和调试你的测试，但对于运行一个已创建的脚本测试却不是非常好. 前面提到的那篇文章也解释了你应该怎样将你的测试运行于非GUI模式并节省大量的资源来模拟更大的负载.

为了将测试运行于非GUI模式，你需要将脚本保存为一个JMX文件 (我们把它命名为 ‘JMeterLimitationsTest.jmx’) 并执行下面这个命令:

jmeter -n -t JMeterLimitationsTest.jmx

让我们来运行脚本… 我们看到这次运行无误:

这就是为什么强烈推荐将你的负载脚本运行在非GUI模式. 通过一个简单的优化动作，我们就节省了很多的机器资源并避免了无谓的内存浪费.

使用2,000个用户来运行你的测试

现在让我们进一步将用户量加大2倍以达到2000用户的负载. 我们使用JMeter GUI来打开之前那个JMX文件并修改线程组里的用户数，然后保存为同一个文件.

我们再次运行测试然后得到这样的….

提示 #3: 增加JMeter堆空间来产生一个更大的负载

内存又被用光了. 这次发生在模拟1,191个用户后. 我们是否能更进一步? 答案是肯定的! 我们有许多有用的建议，这次是: “增加JMeter堆空间来产生更大的负载”.

JMeter的默认堆有限制，但很容易增加其大小. 打开你的JMeter运行器脚本 (在JMeter的 bin目录下) 并替换最大堆的大小(在-Xmx 标志后面) ，下面是默认值:

HEAP="-Xms512m -Xmx512m"

分配 2 GB (2048 MB) 的内存:

HEAP="-Xms512m -Xmx2048m"

现在我们可以用2000用户重新运行测试. 结果如下…

提示 #4: 运行测试时使用本地网络而不是Wi-Fi连接

这次我们不再有内存不够用问题，但你可以看到当我们运行了差不多2000个用户后，测试中开始出现了许多失败的请求.

我不会再写一些无聊的描述来究问题的根本原因, 但我会给你这个建议: “使用本地网络而不是Wi-Fi连接来模拟更多的用户”, 虽然你会认为Wi-Fi的信号也足够强. 前面所有的测试都是在Wi-Fi连接下运行的. 到目前为止，连接都工作的很好, 但我们需要使用本地网络连接来进一步做测试.

现在已经切换到了本地网络, 现在我们再执行下测试.

这次测试无任何问题，顺利通过. 现在我们可以确定的是一个普通的手提电脑可以使用JMeter模拟2000个用户做测试,我们需要继续寻找它的限制.

使用10000个用户运行你的负载测试

我们已经使用了越来越多的线程来模拟JMeter的用户了. 因此，我们发现我们可以模拟的最大用户数大概在 8000-9000 之间. 如果我们增加更多的用户, 我们会在测试执行后立即得到内存不够用的错误.这次不再是堆内存引起的，而是本地机器内存的限制.

这个时刻也可能有许多其它与测试无关的随机错误.

结论是，我们可以将JMeter运行在一台普通的手提电脑上来模拟高达10000用户. 这取决于下面4个简单的规则:

• 只将JMeter监听器用于调试目的.
• 将JMeter性能测试运行于非GUI模式.
• 提高JMeter堆空间来产生更高的负载.
• 使用本地网络而不是Wi-Fi连接来运行你的负载测试.

你可以看到，关于问题 “JMeter最多可以模拟多少用户?”的答案是不同的. 它取决于许多因素: 测试的复杂度, 脚本运行的方式, 网络和机器的性能等.

我发现我的手提电脑JMeter用户数的极限在8,000-9,000左右的. 但如果你需要模拟更多的用户数时该怎么办? 下面是可以做的:

1. 开启JMeter的分布式脚本测试模式并在多个机器上运行，然后合并测试结果.通过这种方式你可以无限水平扩展你的脚本，除了可分配给你做测试运行的机器数外。

2. 你也可以使用云解决方案. BlazeMeter 提供了一个简单易用的测试平台, 可以让你运行随心所意的用户数.