XenApp et XenDesktop 7.11 à la version actuelle : Améliorations de latence et de blocage des requêtes SQL

Les informations sur les performances pour le courtage avec latence ont été fournies dans l’articleXenApp et XenDesktop 7.7 : zones, latence et performances de courtage. Cet article décrit les améliorations pour le courtage avec latence de XenApp et XenDesktop 7.11. Il décrit également les améliorations visant à éviter le blocage lors de l’enregistrement VDA.

Courtage avec des améliorations de latence

Dans XenApp et XenDesktop 7.11, nous avons revisité le code SQL de courtage principal qui détermine quel VDA est le moins chargé, puis envoie une demande de lancement à ce VDA. Nous avons décidé de passer d’un algorithme d’équilibrage de charge « parfait » à un algorithme d’équilibrage de charge « assez bon ».

Avant XenApp et XenDesktop 7.11, le code recherchait le VDA le moins chargé et verrouillait ou bloquerait d’autres demandes de lancement jusqu’à ce que ce VDA devienne disponible. Cela a bloqué toutes les autres demandes de courtage.

À partir de XenApp et XenDesktop 7.11, le code recherche le programme de travail le moins chargé qui n’est pas actuellement verrouillé. Cela signifie que, bien que nous ne puissions pas obtenir le travailleur le moins chargé - peut-être que nous n’obtenons que le deuxième ou le troisième moins chargé - nous pouvons le faire sans verrouiller toutes les autres demandes de lancement. Si nous ne trouvons pas de programme de travail déverrouillé, nous nous asseyons et attendons les verrouillages. Avec suffisamment de VDA, il est rare de les trouver tous verrouillés en même temps, mais quand cela arrive, le comportement est le même qu’avec l’algorithme précédent.

Dans certains scénarios, les administrateurs peuvent remarquer une légère différence dans l’équilibrage de charge, mais il doit être très attentif pour remarquer que nous n’utilisons pas le VDA le moins chargé.

Il existe d’autres emplacements dans le code de courtage principal où les problèmes de blocage SQL ont été améliorés. Citrix recommande que les grands sites utilisent un courtier 7.13 ou 7.6 CU3 pour avoir toutes les améliorations actuellement connues.

Résultats du rendement

Le tableau suivant ajoute deux points de données aux données duarticle précédentpour afficher le courtage résultant avec des améliorations de latence :

Version du produit 7.7 7.11+ 7.7 7.7 7.11+
Latence (ms) 90 90 250 250 250
Demandes simultanées 48 48 36 48 48
Temps de réponse moyen (s) 12.9 3.7 26.7 S.O. 7.6
Demandes de courtage par seconde 3.7 12.6 1.3 S.O. 6.3
Erreurs ( %) 0 0 4.6 42.8 0
Délai de lancement de 10 000 utilisateurs 44 min 55 s 13 min 10 s 2 h 03 min s.o. 26 min 27 s

Comme vous pouvez le voir avec une latence de 250 ms, XenApp et XenDesktop 7.11 surpasse maintenant le code 7.7 à 90 ms. Donc, plutôt que de passer du temps à tester beaucoup de points de données, nous avons testé un qui a échoué précédemment. Vous pouvez voir qu’avec 7.11 ou version ultérieure, les utilisateurs bénéficient d’un courtage plus rapide des ressources, même avec une latence entre un courtier et le serveur SQL.

Les clients des Controller LTSR 7.6 CU3 bénéficient également des mêmes améliorations. Bien que nous ne nous attendions pas à ce que LTSR 7.6 CU3 soit déployé avec latence, ces modifications améliorent encore les performances même sans latence - et nous savons que certains clients ont LTSR 7.6 CU3 avec une certaine latence.

Sérialisations de tempête d’enregistrement

Malheureusement, un domaine que nous savons qu’il y a un verrou est l’enregistrement VDA. La raison de la serrure est d’éviter les blocages lors de l’enregistrement des travailleurs. Nous avons maintenant une meilleure compréhension de la cause des blocages, ce qui était dû au fait que les sessions d’un travailleur ne sont pas verrouillées dans un ordre cohérent sur plusieurs threads d’enregistrement. Nous faisons maintenant le verrouillage de session par identifiant de session, ce qui arrête le blocage des enregistrements VDA.

Nous avons testé ce changement de comportement en interne et constaté qu’il a aidé à résoudre certains problèmes lors de nos tests d’échelle de réenregistrement. Cependant, parce que certains clients ont des environnements très complexes, nous n’avons pas complètement supprimé ce verrou, pour laisser du temps pour plus de tests. Au lieu de cela, nous avons fourni un accordable sur l’utilisation de ce verrou pour les clients avec XenApp et XenDesktop 7.12 ou version ultérieure. Ce réglage se trouve dans la table chb_Config.Site de la base de données XenApp et XenDesktop 7.12 :

sélectionnez SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations à partir de chb_Config.site

SerializeMultiSessionAudits SerializeMultiSessionDeregistrations

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

1 1

Vous pouvez définir ces indicateurs sur 0 pour supprimer l’utilisation du verrou :

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

sélectionnez SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations à partir de chb_Config.site

(1 ligne (s) affectée (s))

SerializeMultiSessionAudits SerializeMultiSessionDeregistrations

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

0 0

On s’attend à ce que les versions futures ne fassent pas ce verrouillage, et qu’elles fournissent l’accordable aux clients qui ont besoin de réactiver le verrouillage.

Cet article a été modifié à partir d’un billet de blog écrit par Chris Gilbert. Pour lire le blog original et pour voir les commentaires, allez à https://www.citrix.com/blogs/2017/03/06/latency-and-sql-blocking-query-improvements.

XenApp et XenDesktop 7.11 à la version actuelle : Améliorations de latence et de blocage des requêtes SQL