LoadRunner 12.5：控制器和分析工具返回不一致的统计信息。为什么？答案

【问题标题】：LoadRunner 12.5: Controller and Analysis tools returning inconsistent stats. Why?LoadRunner 12.5：控制器和分析工具返回不一致的统计信息。为什么？
【发布时间】：2016-08-02 15:36:14
【问题描述】：

我正在使用 LoadRunner 12.5 进行负载测试。它安装在 Windows Server 2012(R2) VM (8Gb RAM) 上。特定的测试套件仅使用 HTTP 和 Oracle 2 层协议。

完整版详情：

LR 控制器：12.50.0.0 build 249
LR 分析器：12.50.0.0 build 1096
没有安装补丁
一个负载生成器在同一主机上运行

问题：

在运行了 5 天后，我注意到 Controller 和 Analysis 事务统计数据不同 - 而且相当大。

LR 控制器运行完成后，它会将我的运行统计报告为：

passed transactions = 937,946
failed transactions = 62

在 LR 分析中生成统计信息时，我的运行统计信息报告为：

passed transactions = 1,019,158  (!)
failed transactions = 9,919  (!!)

此外，应用程序之间的吞吐量图（和每秒点击次数）有些不一致，即使考虑到不同的图比例。

然后，虽然这显然也是上面已经提到的整体交易计数的一个促成因素，但查看单个交易（例如 transX 等），我看到：

Controller:  transX passed=249586, fail=11
Analysis:    transX passed=274063, fail=684

Controller:  transY passed=5224, fail=1
Analysis:    transY passed=5727, fail=665

Controller:  transZ passed=5227, fail=0
Analysis:    transZ passed=5756, fail=0

任何、任何、任何想法，为什么我看到 Controller 和 Analysis 之间的事务统计数据不一致？
控制器是否在完成时没有更新自己的统计信息？它始终低于分析。

我将深入研究 .mdb 以尝试进一步理解这一点，但非常欢迎提示/保证我不会发疯。

【问题讨论】：

标签： loadrunner

【解决方案1】：

我发现了使 Analysis 中的结果与 Controller 中的最终值几乎相同的修复：

在分析屏幕的最左下方，是带有向下三角形的“摘要数据”字样。单击三角形并选择“生成完整数据”。运行它需要您保留在运行期间创建的 Result 目录，因此如果您清除了这些目录，它将无法工作。我不确定它是什么时候引入的，但要么它是相当新的，要么 11.0x 天的摘要数据与控制器报告的更接近。

【讨论】：

嗨 Rick，感谢您回复我。奇怪的是，仍然没有解决这个问题。一直在与 HP 聊天，但它似乎与失败如何包含在摘要计数中有关。它们显然应该被打折，但是当我在分析中的数字（远）大于控制器中的数字时，这似乎并没有叠加。我认为 Complete Data 已经存在了一段时间（至少 9.5），但我以前从来没有真正需要使用过它，而且 Summary stats 似乎总是同步的。我正在玩过滤器来纠正这个问题。我会及时通知你。
你好。这确实是问题所在。我使用过 LR 9.5 - LR 11.5，但从未见过需要生成完整数据。 LR 分析统计数据始终与控制器统计数据匹配。就我而言，差异非常大（64 失败到 990000）。生成完整的数据确实可以解决问题。
除此之外还要注意几点： 1) 生成完整的数据需要硬件上有足够的内存。也就是说，我们在 lrr 位置有一个 6Gb .eve 罚款，这需要完全加载到内存中（没有流式传输）。 2) Controller 和 Analysis 之间的事务时间也略有不同，但这是因为 Analysis 忽略了“浪费时间”——其中包括您在事务时间中碰巧（错误地拥有）的任何思考时间。它还包括其他时间。您可以通过将 Analysis 配置为不“忽略思考时间”来纠正此问题。

【解决方案2】：

从您的虚拟机开始。除非您正在运行 VMWARE 并且设置了将负载生成器时钟固定到虚拟机管理程序操作系统时钟的设置，否则由于 VM 中的时钟浮动和同步问题，您将获得不一致的时序记录。

此外，由于您在虚拟机上运行，因此您会遇到初始条件和测试条件一致的问题，因为您无法控制其他虚拟机的行为以及管理程序如何代理与您的负载共享的资源生成器虚拟机和相关主机上的其他虚拟机。

有多少负载生成器？你没有提到任何。我是否应该假设您在与控制器相同的主机上运行所有虚拟用户？如果是这样，坏魔法！

虚拟机问题是众所周知的，并且在过去十年中已在在线论坛中多次讨论过。这些与工具无关的问题会影响所有供应商性能测试工具。

您有控制负载生成器吗？您在其上运行每种类型的单个虚拟用户的物理主机？这个控制数据集从一个测试到下一个测试是否一致？

【讨论】：

感谢詹姆斯的回复。我不知道从 VM 运行它的问题，所以这有点令人担忧。我们过去这样做没有问题 - 我相信这是我们在最近的测试中第一次注意到它。您提到负载生成器的时间会不一致，但我们看到的主要问题是事务数量的不一致（显着差异）。在 VM 中运行时也会出现这种情况吗？
回答您的问题： 1) 负载生成器：我们只使用一个负载生成器——这个特定的测试只运行 8 个用户。 2) loadrunner 主机：这是与Controller 相同的主机。 3) 控制负载：我们没有单独的物理设置。我们在 VM 上进行的较短性能测试产生了合理一致的结果，并且（据我所知）没有显示事务一致性。再次感谢...
我将记录时间记录的数量与从一次运行到下一次运行之间的差异，即您从 VM 主机上的管理程序中获得的资源周期数。在共享环境中，您实际上对此几乎没有控制权。被另一台虚拟机大量使用仲裁资源，你们中的一个人不得不输掉仲裁战。那些要求你使用虚拟机负载生成器的人会抱怨你的测试资源的一致性。他们需要向镜子里的人抱怨。