Erweiterte Konzepte

XenApp und XenDesktop 7.11 bis aktuelle Version: Verbesserungen bei der Wartezeit und SQL-Blockierungen

Leistungsinformationen für Brokering mit Latenz wurden in dem Artikel bereitgestellt XenApp und XenDesktop 7.7: Zonen, Latenz und Brokering-Performance. Dieser Artikel beschreibt Verbesserungen beim Brokering mit Latenz von XenApp und XenDesktop 7.11. Außerdem werden Verbesserungen beschrieben, um Deadlocking bei der VDA-Registrierung zu verhindern.

Brokering mit Latenzverbesserungen

Bei XenApp und XenDesktop 7.11 haben wir den Core Brokering SQL-Code überprüft, der bestimmt, welcher VDA am wenigsten geladen ist, und dann eine Startanforderung an diesen VDA sendet. Wir haben uns entschieden, von einem “perfekten” Lastausgleichsalgorithmus zu einem “gut genug” Lastausgleichsalgorithmus zu wechseln.

Vor XenApp und XenDesktop 7.11 suchte der Code nach dem am wenigsten geladenen VDA und sperrte andere Startanforderungen, bis dieser VDA verfügbar ist. Dadurch wurden alle anderen Brokering-Anfragen blockiert.

In XenApp und XenDesktop 7.11 sucht der Code nach dem am wenigsten geladenen Worker, der derzeit nicht gesperrt ist. Das bedeutet, dass, obwohl wir vielleicht nicht den am wenigsten geladenen Arbeiter bekommen - vielleicht bekommen wir nur den zweiten oder dritten am wenigsten geladenen - wir dies tun können, ohne alle anderen Startanfragen zu sperren. Wenn wir keinen entsperrten Arbeiter finden, sitzen wir und warten auf Schlösser. Bei genügend VDAs ist es selten, alle gleichzeitig gesperrt zu finden, aber wenn es passiert, ist das Verhalten das gleiche wie beim vorherigen Algorithmus.

In einigen Szenarien bemerken Administratoren möglicherweise einen leichten Unterschied beim Lastenausgleich, aber es muss sehr genau beachtet werden, dass wir nicht den am wenigsten geladenen VDA verwenden.

Es gibt andere Speicherorte im Kern-Brokering-Code, an denen SQL-Blockierungsprobleme verbessert wurden. Citrix empfiehlt, dass große Standorte einen 7.13- oder 7.6-CU3-Broker verwenden, um alle derzeit bekannten Verbesserungen zu erhalten.

Leistungsergebnisse

In der folgenden Tabelle werden zwei Datenpunkte zu den Daten in hinzugefügtvorheriger Artikel, um die resultierende Brokering mit Latenzverbesserungen anzuzeigen:

Produktversion 7.7 7.11+ 7.7 7.7 7.11+
Latenz (ms) 90 90 250 250 250
Hintergrundprozesse 48 48 36 48 48
Durchschnittliche Antwortzeit (en) 12.9 3.7 26.7 Nicht zutreffend 7.6
Brokeringanfragen pro Sekunde 3.7 12.6 1.3 Nicht zutreffend 6.3
Fehler (%) 0 0 4.6 42.8 0
Zeit, 10.000 Benutzer zu starten 44 Minuten 55 s 13 Minuten 10 s 2 Std. 03 Min. Nicht zutreffend 26 Minuten 27 s

Wie Sie mit 250 ms Latenz sehen können, übertrifft XenApp und XenDesktop 7.11 jetzt den 7.7-Code mit 90 ms. Anstatt Zeit damit zu verbringen, viele Datenpunkte zu testen, testeten wir einen, der zuvor fehlgeschlagen war. Sie können sehen, dass Benutzer ab 7.11 eine schnellere Vermittlung von Ressourcen erfahren, selbst bei Latenz zwischen einem Broker und dem SQL-Server.

Auch Kunden mit LTSR 7.6 CU3 Steuerungen profitieren von den gleichen Verbesserungen. Obwohl wir nicht erwarten, dass LTSR 7.6 CU3 mit Latenz bereitgestellt wird, verbessern diese Änderungen die Leistung auch ohne Latenz. Wir wissen, dass einige Kunden LTSR 7.6 CU3 mit einer gewissen Latenz haben.

Registrierungssturm-Serialisierungen

Leider ist ein Bereich, von dem wir wissen, dass es eine Sperre gibt, die VDA-Registrierung. Der Grund für die Sperre besteht darin, Deadlocks bei der Registrierung von Arbeitskräften zu vermeiden. Wir haben jetzt ein viel besseres Verständnis der Ursache der Deadlocks, was darauf zurückzuführen ist, dass Sitzungen für einen Worker nicht in einer konsistenten Reihenfolge über mehrere Registrierungs-Threads gesperrt wurden. Wir führen jetzt die Sitzungssperre nach Sitzungs-ID durch, die die VDA-Registrierungen Deadlocking stoppt.

Wir haben diese Verhaltensänderung intern getestet und festgestellt, dass es dazu beigetragen hat, einige Probleme in unseren Neuregistrierungsmaßstabstests zu lösen. Da einige Kunden jedoch sehr komplexe Umgebungen haben, haben wir diese Sperre nicht vollständig entfernt, um Zeit für mehr Tests zu geben. Stattdessen haben wir für Kunden mit XenApp und XenDesktop 7.12 oder höher eine abstimmbare Version zur Verfügung gestellt. Diese Tunable befindet sich in der Tabelle chb_Config.Site der XenApp und XenDesktop 7.12-Datenbank:

select SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations from chb_config.Site

SerializeMultiSessionAudits SerializeMultiSessionDeregistrations

--------------------------- ------------------------------------

1 1

Sie können diese Flags auf 0 setzen, um die Verwendung der Sperre zu entfernen:

update chb_config.Site set SerializeMultiSessionAudits=0, SerializeMultiSessionDeregistrations=0

select SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations from chb_config.Site

(1 row(s) affected)

SerializeMultiSessionAudits SerializeMultiSessionDeregistrations

--------------------------- ------------------------------------

0 0

Künftige Releases wird erwartet, dass diese Sperre nicht durchgeführt wird, und dass Kunden, die das Sperren wieder aktivieren müssen, die stimmen können.

Dieser Artikel wurde aus einem Blogbeitrag von Chris Gilbert geändert. Um den ursprünglichen Blog zu lesen und die Kommentare zu sehen, gehen Sie zuhttps://www.citrix.com/blogs/2017/03/06/latency-and-sql-blocking-query-improvements.

XenApp und XenDesktop 7.11 bis aktuelle Version: Verbesserungen bei der Wartezeit und SQL-Blockierungen