Citrix Virtual Apps and Desktops:区域、延迟和代理性能

区域

跨越通过 WAN 连接的广泛分散位置的部署可能会面临网络延迟和可靠性问题。
您可以在单个站点内配置区域,而不是创建多个站点(每个站点需要单独管理其各自的 SQL Server 站点数据库)。

延迟对中转性能的影响

最终用户每天都会推出资源。随着区域的增加,只要有本地 Broker,用户现在就可以使用更高延迟的链接。
额外的延迟会影响最终用户体验。对于用户所做的大多数工作,他们会看到预期的缓慢程度,这与卫星代理和 SQL 数据库之间的往返有关。

实际代理会话存在一个痛点——这是因为需要选择负载最低的 VDA 来启动应用程序。
它发生在数据库事务中,需要提供交付组中 VDA 上所有当前负载的快照。
交付组中的所有工作人员都被解除锁定,这会阻止其他用户(导致序列化)使用相同的锁定。它还会等待并阻止工作线程状态更改(例如会话事件)。

由于延迟低,从拿到解锁之间的延迟很小。但是,随着延迟的增加,锁定持有时间会增加,因此代理会话的时间也会增加。

我们研究了不同类型的延迟和发射率。
延迟是往返时间 (RTT),基于 Verizon IP 延迟统计数据
大多数 RTT 都低于列出的最大值,但我们想确保使用一些有用的 RTT 进行测试。

10 毫秒 (ms) 的往返时间涵盖大多数国家间延迟,45 毫秒涵盖北美、欧洲和日本,90 毫秒涵盖跨大西洋,160 毫秒涵盖跨太平洋、拉丁美洲和亚太地区,250 毫秒涵盖欧洲、中东和非洲至亚太地区。

我们测试了不同类型的并发请求,涵盖了从 12 到 60 的值,以 12 为增量。

注意: VDA 会话是模拟的,因为测试的重点是延迟对代理的影响。对于此测试,一个交付组中有 57 个 VDA。每项测试都试图启动 10,000 名用户。

10 毫秒 RTT 结果          
并发请求 12 24 36 48 60
平均响应时间(秒) 0.9 1.4 1.6 2.1 2.6
每秒代理请求 14 17.8 22.9 23.2 22.9
错误 (%age) 0 0 0 0 0
启动 1 万用户的时间 11m 57s 9m 24s 7m 16s 7m 11s 7m 17s

不出所料,10 ms 的速度足以处理系统上的负载,并且没有错误。这是启动用户的最快方法。在 60 个并发用户的最大启动速率下,平均响应时间为 2.6 秒,启动所有 10,000 个用户需要 7 分 17 秒。

45 毫秒 RTT 结果          
并发请求 12 24 36 48 60
平均响应时间(秒) 1.7 3.1 4.3 6.4 7.3
每秒代理请求 7.1 7.8 8.4 7.5 8.2
错误 (%age) 0 0 0 0.01 0.01
启动 1 万用户的时间 23m 28s 21m 19s 19m 51s 22m 15s 20m 19s

45 毫秒时,结果仍然不错。在非常高的启动速率下,一两个用户看到了错误。

注意: 序列化对响应时间的影响可以看出,代理会话的时间从 1.7 秒增加到 7.3 秒。 代理 10000 名用户的总时间为20-23分钟。

90 毫秒 RTT 结果          
并发请求 12 24 36 48 60
平均响应时间(秒) 2.9 6.4 9.5 12.9 16.2
每秒代理请求 4.1 3.7 3.8 3.7 3.7
错误 (%age) 0 0 0 0.01 0.01
启动 1 万用户的时间 40m 30s 44m 29s 44m 11s 44m 55s 45m 04s

90 毫秒的结果几乎没有出现错误。
通过延迟进行交易的影响变得更加明显,用户看到代理一个包含12个并发请求的会话的平均时间为2.9秒,而代理一个包含60个并发请求的会话的平均时间增加到不可接受的16.2秒。
在这种情况下,以较低的费率对 Broker 用户来说更有优势。启动所有 10,000 名用户花了 40—45 分钟。

160 毫秒 RTT 结果          
并发请求 12 24 36 48 60
平均响应时间(秒) 5.7 11.4 17.3 23.2 28.0
每秒代理请求 2.1 2.1 2.1 2.1 2.1
错误 (%age) 0 0 0.12 4.0 17.7
启动 1 万用户的时间 1 h 19m 0s 1 h 19m 27s 1 h 19m 55s 1 h 20m 26s 不适用

在 160 毫秒内,我们开始看到启动率较高时会出现重大错误,48 个请求时有 4% 的错误,60 个请求时有 17.7% 的错误,响应时间接近 30 秒。
但是,多达36个请求,错误率为0.1%,平均代理时间为17秒。

注意: 很难判断 60 个请求的启动时间,因为 17% 的失败率很难考虑在内。

考虑到这种延迟,我们建议不要传递 24 个并发请求。此外,网站的规模可能是一个因素——启动1,000名用户大约需要8分钟。对于10,000名用户,这将扩展到1小时20分钟。因此,我们不会向数据库推荐具有这种延迟级别的大型站点。

250 ms RTT 结果          
并发请求 12 24 36 48 60
平均响应时间(秒) 9.3 15.4 26.7 - -
每秒代理请求 1.3 1.6 1.3 - -
错误 (%age) 0 0 4.6 42.8 99.0
启动 1 万用户的时间 2h 8m 33s 1h 46m 52s 2h 3m 46s 不适用 不适用

由于延迟如此之高,多次超时发生在较高的并发启动速率下。在 48 个请求中,有 42.8% 的请求失败。在 60 个请求中,超时非常普遍,以至于站点无法使用,因为 99% 的请求失败。唯一可接受的启动率是12个和24个请求。很难推荐部署具有这种延迟水平的大型站点:启动 1,000 个用户需要 13 分钟(12 个并发请求),启动 24 个并发请求需要 11 分钟。10,000 名用户最多需要 2 小时 8 分钟。

限制请求

如果您需要处理高延迟并发现超时时间过多,则在 XenApp 和 XenDesktop 7.7 中添加了注册表项,使其只能处理固定数量的并发代理请求。StoreFront 将在几秒钟后重试超过限制的请求。这有助于撤回请求,从而减少锁定队列。但是,有些用户最终可能会看到更长的启动时间,因为他们总是很不走运,他们的请求总是被拒绝。

密钥是 DWORD,应存储在:HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions

如果密钥不存在,则对代理请求没有限制。

注意: 密钥是每个 Delivery Controller 的,因此 SQL Server 上的总请求需要在远程控制器之间进行分配。

总结

代理确实可以超越延迟,但在调整远程区域的大小时需要考虑延迟。如果一个区域很大,可能仍需要在该区域内保留一个本地数据库。如果区域很小,则使用远程区域可能效果良好,还可以在不影响最终用户体验的情况下降低管理成本。

我们建议您的区域的 RTT 小于 250 毫秒;除此之外,您还应考虑设置不同的站点。

这篇文章是从 Chris Gilbert 撰写的博客文章修改而来的。要阅读原始博客并查看评论,请转到 https://www.citrix.com/blogs/2016/02/09/zones-latency-and-brokering-performance-2/

Citrix Virtual Apps and Desktops:区域、延迟和代理性能