XenApp und XenDesktop 7.11 bis aktuelle Version: Verbesserungen bei der Wartezeit und SQL-Blockierungen
Leistungsinformationen für das Brokering mit Latenz wurden in dem Artikel XenApp und XenDesktop 7.7: Zonen, Latenz und Brokering-Performancebereitgestellt. 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. Dies bedeutet, dass, obwohl wir möglicherweise nicht den am wenigsten geladenen Worker erhalten — vielleicht nur den zweiten oder dritten am wenigsten geladenen Worker — wir dies tun können, ohne alle anderen Startanforderungen 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
Die folgende Tabelle fügt zwei Datenpunkte zu den Daten im vorherigen Artikel hinzu, um das daraus resultierende Brokering mit Latenzverbesserungen zu zeigen:
| 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. | – | 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 — und wir wissen, dass einige Kunden LTSR 7.6 CU3 mit etwas 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
Seit XenApp und XenDesktop 7.15 ist die Standardeinstellung, dass diese Sperre deaktiviert ist. Durch ein Upgrade auf XenApp und XenDesktop 7.15 oder höher wird auch das Sperren deaktiviert. Das Tuneable ist für Kunden vorgesehen, die das Sperren wieder aktivieren müssen.
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 zu https://www.citrix.com/blogs/2017/03/06/latency-and-sql-blocking-query-improvements/.