0

这是场景

我们正在对 Web 应用程序进行负载测试。该应用程序部署在两个 VM 服务器上，并带有一个硬件负载平衡器来分配负载。

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

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

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

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

我对此感到困惑，为什么会有这种巨大的性能差异。

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

有什么线索吗？

4

3 回答 3

1

罪魁祸首很可能在于脚本的结构。

需要考虑的事项：

  • 思考/等待时间：录制时，Jmeter 不会自动进入等待。
  • 正在请求的项目：Jmeter 是否仅在 Load runner 获取所有嵌入文件时请求/下载 HTML 页面？
  • 无效响应：所有 1000 个 Jmeter 响应都有效吗？如果您有 1000 个来自单个桌面的线程，我会怀疑您杀死了 Jmeter，并且并非所有响应都是有效的。
于 2010-10-29T17:37:07.620 回答
1

你真的有四种可能性：

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

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

需要注意的是，LoadRunner 会跟踪其内部 API 时间，以直接解决对工具影响测试结果的指责。如果您打开结果集数据库集（.mdb 或 Microsoft SQL 服务器实例，视情况而定）并查看 [event Meter] 表，您将找到“Wasted Time”的参考。浪费时间的定义可以在 LoadRunner 文档中找到。

于 2011-06-22T12:56:56.403 回答
0

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

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

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

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

于 2010-11-05T12:02:29.003 回答