我发现了相互矛盾的信息,一个说 JMeter 可以产生比 LR 更多的负载,另一个说相反。据我所知(如果我们不考虑许可),每个 LoadGenerator 仅受硬件限制。但JMeter也是如此。文档对我帮助不大。有没有人有这两个方面的经验,所以他可以比较?我说的是大约 2 000-4000 个用户。谢谢
3 回答
众所周知,LoadRunner 可以很好地运行非常大容量的测试,开箱即用。
JMeter 通常会在以下场景中遇到高吞吐量、高线程测试的问题:
- 使用一台机器,有很多侦听器,在 GUI 模式下运行 - 这会占用内存。
- 在版本 < 2.9 的默认配置中使用分布式模式,在 Load Generator 上运行测试没有问题,但向主计算机发送结果存在瓶颈。据报道,此问题已在 2.9 中解决,并且据称在 2.10 中吞吐量更高。
问题是,解决 JMeter 的问题并不难。这只是最佳实践的问题。
- 从命令行运行,不要使用大量的侦听器。精益和平均模式。
- 在分布式执行中,使用批处理模式来减少在版本 < 2.9 中写入一个文件的样本量,或使用 >= 2.9 的默认配置。
- 确保将测试分布在足够多的硬件上。顺便说一下,LoadRunner 也是如此。
您应该阅读这 2 个文档以了解其他最佳实践:
- http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
- http://jmeter.apache.org/usermanual/best-practices.html
LoadRunner 在高负载时也存在问题 - 分析和数据整理阶段可能需要数小时(字面意思),而您无法解决这个问题。如果您有太多数据需要分析,您也可能会遇到内存问题。Jmeter 在结果分析方面并不全面,但速度更快。
如果您真的需要大量测试,那么我编写了一个脚本,该脚本有效地为您提供了 JMeter 的无限可扩展性——我已经测试了多达 20000 个用户,在 50 台服务器上运行时每秒点击 8000 次。它是“无限的”,因为它通过运行大量孤立的测试来工作,这些测试在测试结束之前不会相互通信,这样编译结果就不会出现瓶颈。但总有另一个瓶颈在某个地方......
这两种工具都有你注意到的级别的跟踪记录,2-4K 用户。橡胶与道路相遇的地方在于以质量 Y 交付测试 X 所需的劳动力,包括详细分析。如果您正在研究这两种工具,那么您应该考虑在您的应用程序上使用 POC。
独立于任一工具记录您的脚本和所需的分析级别,然后聘请这两个方面的专家根据您的要求运行 POC。为所有任务计时,甚至要求人们在文档中输入任务开始时间和任务结束时间。比较 POC 结束时的时间和输出。
您应该意识到,当您去市场寻找任一工具的专家时,性能测试市场中的技能完全欺诈水平约为 97%(或更高)。您想雇用具有最强和最长记录的人,并且正在考虑使用具有许多参考的工具,否则您可能会对一个或两个工具的功能和效率有一个可怕的扭曲看法,这可能会导致一个糟糕的决定工具选择。
期望为这两种工具雇用您内部可能没有的技能。许多人认为,性能测试工具代表了性能测试工作所需技能的 85-90%。反之亦然,工具技能运行在成功所需技能(关键技能)的 10-15% 之间。
Jmeter 是为穷人准备的。Jmeter 只能测试特定种类的 Java 应用程序。它不支持 ERP 应用程序或 web 2.0。您可以将 Jmeter 连接到 ERP 应用程序并尝试记录它。6 周后 Jmeter 仍然无法工作。