XenApp和XenDesktop 7.11到当前:延迟和SQL阻塞查询改进

本文提供了具有延迟的代理的性能信息XenApp和XenDesktop 7.7:分区、时延和代理性能．本文描述了XenApp和XenDesktop 7.11对延迟代理的改进。它还描述了在VDA注册时防止死锁的改进。

代理与延迟改进

在XenApp和XenDesktop 7.11中，我们重新访问了核心代理SQL代码，它决定了哪个VDA是加载最少的，然后向那个VDA发送一个启动请求。我们决定从“完美”的负载平衡算法切换到“足够好”的负载平衡算法。

在XenApp和XenDesktop 7.11之前，代码寻找负载最小的VDA，并将锁定/阻塞其他启动请求，直到VDA可用。这阻止了所有其他代理请求。

在XenApp和XenDesktop 7.11中，代码寻找当前未锁定的负载最少的worker。这意味着，尽管我们可能不会得到加载最少的工作器——可能只得到加载第二或第三次最少的工作器——但我们可以这样做，而不需要锁定所有其他的启动请求。如果我们找不到一个未上锁的工人，我们就坐着等待上锁。有了足够多的vda，很难同时发现所有的vda都被锁定了，但当它发生时，行为与之前的算法相同。

在某些场景中，管理员可能会注意到负载平衡方面的细微差别，但是需要非常密切地注意到我们没有使用负载最小的VDA。

在核心代理代码中，SQL阻塞问题也得到了改进。Citrix建议大型网站使用7.13或7.6 CU3代理来实现当前已知的所有改进。

性能结果

的数据中添加了两个数据点前一篇文章为了显示延迟改进的结果代理:

正如你所看到的250毫秒延迟，XenApp和XenDesktop 7.11现在在90毫秒时的性能优于7.7代码。所以，我们没有花时间测试大量的数据点，而是测试了一个之前失败的数据点。您可以看到，使用7.11或更高版本，用户可以更快地代理资源，即使代理和SQL服务器之间存在延迟。

LTSR 7.6 CU3控制器上的客户也从同样的改进中受益。尽管我们不期望LTSR 7.6 CU3的部署会有延迟，但即使没有延迟，这些更改仍然可以提高性能——我们知道有些客户的LTSR 7.6 CU3确实有一些延迟。

登记风暴序列化

不幸的是，我们知道有一个锁的区域是VDA注册。使用锁的原因是为了在注册工人时避免死锁。我们现在对死锁的原因有了更好的理解，这是由于在多个注册线程上没有以一致的顺序锁定工作线程的会话。现在我们通过会话id执行会话锁定，这将停止VDA注册死锁。

我们在内部测试了这种行为变化，发现它有助于解决重新注册规模测试中的一些问题。然而，由于一些客户的环境非常复杂，我们没有完全移除这个锁，以留出时间进行更多的测试。相反，我们为使用XenApp和XenDesktop 7.12或更高版本的客户提供了一个使用该锁的可调参数。这个可调参数在chb_Config中。XenApp和XenDesktop 7.12数据库的站点表:

从chb_config中选择serializemultisessionauditing, serializemultisessionde注册。网站SerializeMultiSessionAudits SerializeMultiSessionDeregistrations  --------------------------- ------------------------------------ 1

你可以设置这些标志为0来移除锁的使用:

更新chb_config。从chb_config中选择serializemultisession审计，serializemultisessionderegitions =0。网站(1行(s)影响)SerializeMultiSessionAudits SerializeMultiSessionDeregistrations  --------------------------- ------------------------------------ 0 0

由于XenApp和XenDesktop 7.15的默认锁定是禁用的。同样升级到XenApp和XenDesktop 7.15或更高版本也禁用锁定。为需要重新启用锁定的客户提供了可调参数。

这篇文章是由Chris Gilbert的一篇博客文章修改而来的。要阅读原始博客和查看评论，请访问//m.giftsix.com/blogs/2017/03/06/latency-and-sql-blocking-query-improvements/．