logo标签列表

在Jmeter中同时运行的最合理线程数是多少？

httpweb-applicationsload-testingjmeter
40

我想使用尽可能多的线程（以使用较少的计算机），但不要让瓶颈出现在客户端。

2
我认为这取决于你的硬件... - Pascal Thivent
1
它取决于你没有告诉我们的一切：操作系统、硬件、服务器测试、客户端同样，... 这不是一个真正的问题。 - user207421
10个回答
30

JMeter能够模拟非常高的负载，但要使用得当。

不要听信说JMeter处理不了高负载的都市传说。

现在来回答这个问题，它取决于：

  • 你的机器性能

  • 你的jvm是32位还是64位

  • 你的jvm分配的内存-Xmx

  • 你的测试计划（很多beanshell、后置处理器、xpath...意味着需要大量的CPU）

  • 你的操作系统配置（可调整）

  • GUI /非GUI模式

因此，没有理论上的答案，但遵循最佳实践可以确保JMeter表现良好。

请注意，使用JMeter可以通过远程测试进行负载分布，参阅：

最后如果不够，使用基于云的测试。

阅读以下内容以获取调整提示：

阅读这本书以进行负载测试并正确使用JMeter。

11

我使用过JMeter，发现它在生成高负载时表现并不好。在一个2Ghz的Core2 Duo处理器和2Gb内存的电脑上，你可以合理地期望有大约100个线程。

话虽如此，最好在您的硬件上运行它，这样PC的CPU不会达到100% - 稳定在80％-90％最佳，否则结果会受到影响。

我也尝试过WAPT 5 - 它成功地从同一台PC上运行了1000多个线程。它不是免费的，但比JMeter更易用，但并不具备所有功能。

自至少2.6版本以来已过时，请参见 https://dev59.com/PXRA5IYBdhLWcg3w9y10#11922239 获取更多更新的答案。

9
答案已经过时，适用于 JMeter 2.8 版本之前。 - UBIK LOAD PACK
11

JMeter维基报告了JMeter被使用1000个线程的情况。我最多使用100个线程，但维基中的链接建议的资源减少我从未尝试过。

5

我们在Windows XP上运行JMeter时遇到的问题之一是Windows XP TCP连接限制。为了充分发挥工作站的潜力，应该移除此限制。

更多信息请点击这里。据我所知，此限制不适用于其他操作系统。

4

自2004年以来，我一直在使用JMeter并进行了大量的负载测试。

我的电脑配置是Windows 7 64位，4GB内存，iCore5处理器。

我认为JMeter可以支持300至400个并发线程来执行Http协议，并且只需要一个“聚合报告监听器”即可将结果和页面调用之间的时间写入日志文件。

对于大型的负载测试，您可以像这样使用从节点（负载生成器）配置JMeter： http://jmeter-plugins.org/wiki/HttpSimpleTableServer/

我已经使用了11台从节点来模拟5000个线程的测试。

主要的限制是GUI聚合报告（2015），现在通过优化聚合报告，您可以在一台计算机上模拟超过400个线程，甚至可能达到1000个线程。 - Vincent Daburon
0
0

这个没有标准数字。你可以从一台计算机生成的最大线程数完全取决于计算机的硬件和操作系统。操作系统默认占用一定量的CPU和RAM。

要找出计算机可以处理的最大线程数，您可以准备一个样本测试，并仅使用少量线程运行它。然后，在每个测试运行周期中逐渐增加线程数。在此过程中，您还需要监视计算机的CPU、RAM、磁盘I/O和网络I/O。当其中任何一个接近或超过80%（再次由您决定是否接近足够），那就是计算机可以处理的最大线程数。为了更安全，我建议在资源利用率达到70%时停止。

0

这更多地取决于您在特定服务器上执行的性能测试类型（负载、峰值、耐久等），以及一些硬件依赖性。

请记住以下参数： - 您针对jmeter运行的客户端机器将分配一定量的堆内存，请确保有足够的内存分配，以避免脚本出错。我在本地环境（客户端-服务器架构）上运行的最高值为1500，在Web架构上，我运行的最高值基于非功能需求限制为250个线程。

因此，这实际上取决于性能测试和部署方式等因素。

0

我没有使用过JMeter，但答案可能取决于您的硬件。最好的方法可能是建立性能指标，猜测线程数，然后按如下方式运行二进制搜索。

来源是维基百科。

猜数字游戏...

这个相当简单的游戏开始时有点像“我在四十到六十之间想了一个整数，对于你的猜测，我会回答'高'、'低'或'是!'，视情况而定。”假设N是可能的值的数量（这里是二十一，因为“包括”已经说明），那么最多需要问题来确定数字，因为每个问题都将搜索空间减半。请注意，比通用算法少一个问题（迭代）是必需的，因为数字已经被限制在特定范围内。

即使我们猜测的数字可以是任意大的，也就是说，没有上限N，我们仍然可以通过重复加倍来首先找到上限，从而在最多步骤中找到数字（其中k是（未知的）选定数字）。例如，如果数字是11，我们可以使用以下猜测序列来找到它：1、2、4、8、16、12、10、11

我们也可以将这种技术扩展到负数；例如，以下猜测可以用来找到-13：0、-1、-2、-4、-8、-16、-12、-14、-13。

-1

这将取决于您运行的硬件以及底层脚本。我一直觉得这种模糊性是传统负载测试工具最大的问题。如果您的预算较小（约200美元可以进行大量测试），请查看我们公司的负载测试服务，BrowserMob。

除了我们的真实浏览器用户（RBUs）控制数千个实际浏览器进行性能和负载测试之外，我们还拥有传统的虚拟用户（VUs）。脚本使用JavaScript编写，并可以进行各种HTTP调用。

我提出这个问题的原因是，我一直觉得试图弄清楚您可以在负载生成硬件上放置多少VU是很危险的。很容易得到不好的结果而不自知。

为了解决这个问题，对于BrowserMob，我们采取了极其保守的方法来确定每个CPU核心的VUs和RBUs数量：每个CPU核心不超过1个浏览器或50个线程，有时更少。在云计算世界中，CPU周期非常便宜，因此尝试超载机器是没有意义的。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接