我想使用尽可能多的线程(以使用更少的计算机),但又不会使瓶颈出现在客户端中。
9 回答
JMeter 可以模拟非常高的负载,只要您正确使用它。
不要听Urban Legends说 JMeter 无法处理高负载。
现在至于答案,这取决于:
你的机器功率
你的 jvm 32 位或 64 位
你的jvm分配的内存-Xmx
您的测试计划(大量 beanshell、后处理器、xpath ......意味着大量 cpu)
您的操作系统配置(可调)
Gui/非gui模式
所以没有理论上的答案,但遵循最佳实践将确保 JMeter 表现良好。
请注意,使用 jmeter,您可以通过远程测试分配负载,请阅读:
如果还不够,最后使用基于云的测试。
阅读此调整提示:
阅读本书以进行负载测试和正确使用 JMeter。
JMeter Wiki报告了将 JMeter 用于多达 1000 个线程的案例。我最多使用了 100 个线程,但 Wiki 中的链接建议我从未尝试过减少资源。
我已经使用过 JMeter,发现它在产生非常高的负载方面并不是很好。在具有 2Gb 内存的 2Ghz Core2 Duo 上,您可以合理地预期大约 100 个线程。
话虽如此,最好在您的硬件上运行它,这样 PC 的 CPU 不会达到 100% 的峰值 - 最好是稳定的 80%-90%,否则结果会受到影响。
我也尝试过WAPT 5 - 它成功地从同一台 PC 运行了 1000 多个线程。它不是免费的,但它比 JMeter 更有用,但不具备所有功能。
至少从 2.6 版开始的过时答案,请参阅https://stackoverflow.com/a/11922239/460802以获取更新的答案。
我们在 Windows XP 上运行 JMeter 时遇到的问题之一是 Windows XP TCP 连接限制。应该删除限制以便运行使用 JMeter 来充分发挥工作站的潜力 更多信息在这里。AFAIK,不适用于其他操作系统。
我从 2004 年开始使用 JMeter,并启动了很多负载测试。
使用 PC Windows 7 64 位 4Go RAM iCore5。
我认为 JMeter 可以支持 300 到400 个并发线程用于 Http (Sampler) 协议,只有一个“聚合报告侦听器”在日志文件结果中写入调用页面之间的计时器和计时器。
对于大型负载测试,您可以像这样 http://jmeter-plugins.org/wiki/HttpSimpleTableServer/使用从属设备(负载生成器)配置 JMeter
我已经用 11 个 PC 从机进行了测试,以模拟 5000 个线程。
我没有使用过 JMeter,但答案可能取决于您的硬件。最好的办法可能是建立性能指标,猜测线程数,然后运行二进制搜索,如下所示。
来源是维基百科。
猜数字游戏...
这个相当简单的游戏的开头类似于“我正在考虑一个介于 40 和 60 之间的整数,根据你的猜测,我会回答‘高’、‘低’或‘是的!’ 可能是这样。” 假设 N 是可能值的数量(这里,21 表示“包括”),那么最多需要问题来确定数量,因为每个问题都会使搜索空间减半。请注意,与一般算法相比,需要少一个问题(迭代),因为该数字已被限制在特定范围内。
即使我们猜测的数字可以任意大,在这种情况下没有上限 N,我们仍然可以通过首先找到一个上限,在最多步骤中找到该数字(其中 k 是(未知)选定的数字)通过反复加倍。例如,如果数字是 11,我们可以使用以下猜测序列来找到它:1、2、4、8、16、12、10、11
还可以扩展该技术以包括负数;例如,可以使用以下猜测来找到 -13:0、-1、-2、-4、-8、-16、-12、-14、-13
它更依赖于您在特定服务器上进行的性能测试(负载、峰值、耐久性等)(有点依赖于硬件)
请牢记这些参数 - 您针对运行 jmeter 的客户端计算机,将分配一定数量的堆内存,确保分配健康,以便脚本不会出错。我在 jmeter 上运行的最高值是本地环境(客户端 - 服务器架构)上的 1500,在 Web 架构上,我运行的最高值是基于非功能性要求限制为 250 个线程,
所以理想情况下,它取决于性能测试的种类和部署风格等等。
对此没有标准编号。您可以从一台计算机生成的最大线程数完全取决于计算机的硬件和操作系统。默认情况下,操作系统会占用一定数量的 CPU 和 RAM。
要找出您的计算机可以处理的最大线程数,您可以准备一个示例测试并仅使用几个线程运行它。然后随着每个测试运行周期逐渐增加线程数。在此期间,您还需要监控计算机的 CPU、RAM、磁盘 I/O 和网络 I/O。当其中任何一个达到接近或超过 80% 时(再次由您决定接近是否适合您或更高),这就是您的计算机可以处理的最大线程数。为了更安全,我会在资源利用率达到 70% 时停止。
这取决于您运行的硬件以及底层脚本。我一直觉得这种模糊性是传统负载测试工具最大的问题。如果您的预算很少(200 美元左右可以让您进行大量测试),请查看我公司的负载测试服务BrowserMob。
除了我们的真实浏览器用户 (RBU) 控制数千个实际浏览器以进行性能和负载测试之外,我们还有传统的虚拟用户 (VU)。脚本是用 JavaScript 编写的,可以进行各种 HTTP 调用。
我提出这个问题的原因是,我一直觉得试图找出负载生成硬件上可以安装多少 VU 的游戏是危险的。在没有意识到的情况下很容易得到不好的结果。
为了解决 BrowserMob 的问题,我们对每个 CPU 核心的 VU 和 RBU 数量采取了一种极其保守的方法:每个 CPU 核心不超过 1 个浏览器或 50 个线程,有时甚至更少。在云计算的世界里,CPU 周期是如此的便宜,以至于试图让机器过载是没有意义的。