在 VDI 中执行负载/性能测试，它是否提供了正确的结果答案

【问题标题】：Performing load/performance testing in VDI, does it provides proper results在 VDI 中执行负载/性能测试，它是否提供了正确的结果
【发布时间】：2017-08-15 11:57:50
【问题描述】：

到目前为止，我一直在本地实例上进行负载/性能测试（负载运行器和 jMeter）（连接到 LAN 而不是通过 wifi），我对结果很确定。但现在我必须这样做Virtual desktop infrastructure (VDI)。它是否提供与本地实例相同的结果？或者通过VDI 执行测试是一种好习惯？

【问题讨论】：

标签： jmeter performance-testing loadrunner stress-testing

【解决方案1】：

LoadRunner 或 JMeter 不关心底层硬件，因为您至少有 2 个抽象层：操作系统和 C 和/或 Java 运行时。

因此，鉴于您的 VDI 具有相同的硬件规格 - 在交付负载方面，您应该在相同的测试中获得相同的结果。不过，我建议监控您的 VDI 主要运行状况指标，例如 CPU 负载、RAM 和页面文件使用情况、网络和磁盘 IO 等。

在大多数情况下，VDI 没有完全专用的资源，即如果您看到 64GB 的 RAM，则不能保证您可以全部分配它们，因为 RAM 可能在 hypervisor 级别的其他 VDI 之间共享。

因此，请监控您的负载生成器系统资源使用情况，并确保您有足够的空间来运行负载测试。有关详细信息，请参阅How to Monitor Your Server Health & Performance During a JMeter Load Test 指南。

【讨论】：

@Dmiti T，感谢您的回答。当我在本地托管应用程序时，在屏幕/页面之间导航时速度很快。但是，当我在某个服务器（客户端环境）上托管相同的应用程序并通过 VDI 访问它时，响应时间非常短（这里没有执行任何负载测试，只是我自己使用）。我担心的是，在那种环境中进行测试是否好？

【解决方案2】：

使用物理负载生成器作为控制元素。在物理机上运行每种类型的单个虚拟用户。如果您发现您的控制组开始呈现不同的性能特征（更慢、更高程度的方差（以标准差衡量）、更高的平均值、第 90 个百分位数和最大值），那么您就有理由维护一些物理基础设施以进行测试。

直接攻击虚拟负载生成器内部时序记录完整性的最大问题是时钟跳跃。虚拟主机中的系统时钟相对于硬件上的物理时钟浮动得更慢。有时这需要重新同步，导致时间跳跃。这不可避免地会在计时记录打开时发生，并导致看起来很长的计时记录。有人建议，在您开始看到 CPU 队列长度中的备份之前不会发生这种情况，该长度在 75-80% CPU 范围内。我已经看到它甚至低至 CPU 的 10%，因为在这些轻负载下，管理程序可以决定将资源解析为更高需求的虚拟化实例，然后当你取回 CPU 令牌时，是时候跳下时钟了。

控制负载生成器提供针对此行为的检查。如有必要，您甚至可以按照制造质量控制线在统计抽样模型中使用控制负载生成器。您还可以客观地向任何要求您迁移到虚拟化模型的人展示此更改将对收集的响应时间样本的完整性产生何种影响。

【讨论】：

【解决方案3】：

这取决于 VDI。它与您的本地主机在同一网络上吗？如果是，结果将几乎相同（也取决于 VDI 的配置，我们可能甚至没有注意到的非常小的开销）

如果不是，结果将取决于该网络有多好。

【讨论】：