XenApp and XenDesktop 7.11 through current: Latency and SQL Blocking Query Improvements 编辑

Performance information for brokering with latency was provided in the article XenApp and XenDesktop 7.7: Zones, Latency, and Brokering Performance
. This article describes improvements for brokering with latency from XenApp and XenDesktop 7.11. It also describes improvements to prevent deadlocking at VDA registration.

Brokering with latency improvements

At XenApp and XenDesktop 7.11, we revisited the core brokering SQL code that determines which VDA is the least loaded and then sends a launch request to that VDA. We decided to switch from a “perfect” load balance algorithm to a “good enough” load balance algorithm.

Before XenApp and XenDesktop 7.11, the code looked for the least-loaded VDA, and would lock/block other launch requests until that VDA become available. This blocked all other brokering requests.

From XenApp and XenDesktop 7.11 the code looks for the least loaded worker that is not currently locked. This means that, although we might not get the least-loaded worker—perhaps we get only the second or third least loaded—we can do so without locking all other launch requests. If we cannot find an unlocked worker, we sit and wait for locks. With enough VDAs, it is rare to find all of them locked at the same time, but when it happens the behavior is the same as with the previous algorithm.

In some scenarios administrators might notice a slight difference in load balancing, but it needs very close attention to notice that we do not use the least loaded VDA.

There are other locations in the core brokering code where SQL blocking issues have been improved. Citrix recommends that large sites use a 7.13 or 7.6 CU3 broker to have all the currently known improvements.

Performance results

The following table adds two data points to the data in the previous article
to show the resultant brokering with latency improvements:

As you can see with 250 ms latency, XenApp and XenDesktop 7.11 now outperforms the 7.7 code at 90 ms. So, rather than spend time testing lots of data points, we tested one that failed previously. You can see that, with 7.11 or later, users experience quicker brokering of resources, even with latency between a broker and the SQL server.

Customers on LTSR 7.6 CU3 controllers also benefit from the same improvements. Although we do not expect LTSR 7.6 CU3 to be deployed with latency, these changes still improve performance even without latency—and we know that some customers do have LTSR 7.6 CU3 with some latency.

Registration storm serializations

Unfortunately, one area that we know there is a lock is VDA registration. The reason for the lock is to avoid deadlocks when registering workers. We now have a much better understanding of the cause of the deadlocks, which was due to not locking sessions for a worker in a consistent order over multiple registration threads. We now do the session locking by session id, which stops the VDA registrations deadlocking.

We have tested this change of behavior internally and found that it helped resolve some issues in our re-registration scale tests. However, because some customers have very complex environments, we have not removed this lock completely, to allow time for more testing. Instead we have provided a tuneable on the usage of this lock for customers with XenApp and XenDesktop 7.12 or later. This tunable is in the chb_Config.Site table of the XenApp and XenDesktop 7.12 database:

select SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations from chb_config.SiteSerializeMultiSessionAudits SerializeMultiSessionDeregistrations--------------------------- ------------------------------------1 1

You can set these flags to 0 to remove the usage of the lock:

update chb_config.Site set SerializeMultiSessionAudits=0, SerializeMultiSessionDeregistrations=0select SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations from chb_config.Site(1 row(s) affected)SerializeMultiSessionAudits SerializeMultiSessionDeregistrations--------------------------- ------------------------------------0 0

Since XenApp and XenDesktop 7.15 the default is for this locking to be disabled. Also upgrading to XenApp and XenDesktop 7.15 or later also disables the locking. The tuneable is provided for customers who need to re-enable locking.

This article has been modified from a blog post written by Chris Gilbert. To read the original blog and to see the comments, go to https://www.citrix.com/blogs/2017/03/06/latency-and-sql-blocking-query-improvements/
.