使用Jmeter加载测试与HP Load转换器时为什么不同？

Question

这是方案

我们正在加载测试Web应用程序。该应用程序部署在两台VM服务器上，其中一台硬件负载平衡器分配负载。

这里使用了两种工具 1. HP Load Runner（一种昂贵的工具）。 2. JMeter - 免费

开发团队使用JMeter来测试大量用户。它也没有像Load Runner这样的许可限制。

如何运行测试？ 使用一些参数调用URL，Web应用程序读取参数，处理结果并生成pdf文件。

运行测试时，我们发现，对于在60秒内传播的1000个用户的负载，我们的应用程序花了4分钟生成1000个文件。 现在，当我们通过JMeter传递相同的URL时，1000个用户的加速时间为60秒， 应用程序需要1分15秒才能生成1000个文件。

我在这里感到困惑，为什么这种巨大的性能差异。

加载运行器在两台服务器上都安装了rstat守护程序。

任何线索？

Answer 1

最有可能的罪魁祸首是脚本是如何构建的。

需要考虑的事项：

• 思考/等待时间：录制时 Jmeter不会自动输入 等待的时间。
• 要求的物品：是 Jmeter仅请求/下载 Load runner获取所有HTML页面 嵌入文件？
• 无效回复： 所有1000 Jmeter响应都有效吗？ 如果你有1000个线程来自a 单个桌面，我会怀疑你 杀了Jmeter而不是你所有的 回复有效。

Answer 2

你真的有四种可能性：

1. 你正在测量两种不同的东西。检查你的时间记录结构。
2. 您的请求和响应信息在两个工具之间有所不同。查看Fiddler或Wireshark。
3. 您的测试环境初始条件不同会产生不同的结果。测试101的东西，但在追踪这样的问题时经常被忽视。
4. 您的loadrunner环境中的负载生成器过载会导致所有虚拟用户变慢。例如，您可能正在记录导致文件系统成为测试瓶颈的所有内容。故意使发电机负荷不足，降低日志记录水平，并观察如何使用内存进行关联，这样就不会产生物理内存超额订购条件，从而导致高交换活动。

至于上面关于JMETER更快的评论，我已经对两者进行了基准测试，对于非常复杂的代码，基于C的Loadrunner解决方案在迭代到迭代执行时比JMETER中基于Java的解决方案更快。 （方法：用于动态创建数据文件的复杂算法，用于批量抵押处理上传.p3：800Mhz.2GB RAM.LoadRunner每小时180万次迭代，单个用户无法使用.JMETER，120万）一旦你添加了它的节奏是服务器的响应时间，两者都是确定的。

应该注意的是，LoadRunner会跟踪其内部API时间，以直接解决影响测试结果的工具的指责。如果您打开结果集数据库集（适当的.mdb或Microsoft SQL服务器实例）并查看[事件计量表]表，您将找到“浪费时间”的参考。浪费时间的定义可以在LoadRunner文档中找到。

Answer 3

不要忘记测试应用程序本身会自行测量，因为响应的到达是基于测试机器的时间。所以从这个角度来看，它可能就是答案，JMeter只是更快。

第二件事是BlackGaff提到的等待时间。

始终使用jmeter中的结果树检查结果。

并且始终将测试应用程序放在单独的硬件上以查看实际结果，因为测试应用程序本身会加载服务器。