就vuser而言,Jmeter vs LoadRunner

Question

我发现了矛盾的信息,其中一个说JMeter可以产生更多的负载然后LR可以,另一个说相反.据我所知(如果我们不考虑许可),每个LoadGenerator仅受硬件限制.但JMeter也是如此.文档对我没什么帮助.有没有人有这两种体验,所以他可以比较？我说的是2 000到4000个用户.谢谢

Answer 1

众所周知,LoadRunner可以在非常高的容量测试中运行良好,开箱即用.

在以下情况下,JMeter通常可以解决高吞吐量,高线程测试的问题:

1. 使用一台具有大量监听器的计算机,以GUI模式运行 - 这会占用内存.
2. 在版本<2.9的默认配置中使用分布式模式,在Load Generator上运行测试没有问题,但是有一个瓶颈将结果发送到主机.据报道,该问题已在2.9中解决,据称吞吐量在2.10中更高.

问题是,解决JMeter的问题并不难.这只是最佳实践的问题.

1. 从命令行运行,不要使用大量的侦听器.精益和平均模式.
2. 在分布式执行中,使用批处理模式来减少在<2.9版本中写入一个文件的样本量或使用> = 2.9的默认配置.
3. 确保通过足够的硬件分发测试.顺便说一句,这对于LoadRunner来说是一样的.

您应该阅读这两个文档以了解其他最佳实践:

• http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
• http://jmeter.apache.org/usermanual/best-practices.html

LoadRunner在高负载时也存在问题 - 分析和数据整理阶段可能需要数小时(字面意思),您无法解决这个问题.如果您有太多数据要分析,您也可能遇到内存问题.Jmeter在结果分析方面不够全面,但速度要快得多.

如果你真的需要高容量测试,那么我写了一个脚本,有效地为你提供了JMeter的无限可扩展性 - 我已经测试了多达20000个用户,每秒运行超过50台服务器的8000次点击.它是"无限的",因为它通过运行大量孤立的测试来工作,这些测试在测试结束之前不会相互通信,这样就没有编译结果的瓶颈.但是某处总是存在另一个瓶颈......