Concepts avancés

XenApp et XenDesktop 7.7 : zones, latence et performances de courtage

Zones

Les déploiements qui couvrent des emplacements très dispersés connectés par un réseau étendu peuvent faire face à des problèmes de latence et de fiabilité du réseau. Plutôt que de créer plusieurs sites, dont chacun nécessiterait sa propre base de données de site SQL Server que vous devrez gérer séparément, vous pouvez configurer des zones au sein d’un seul site.

Impact de la latence sur les performances de négociation

La majorité des utilisateurs finaux énuméreront et lanceront des ressources chaque jour. Avec l’ajout de zones, les utilisateurs peuvent désormais être sur des liens à latence plus élevée tant qu’il y a un broker local.

Avec cette latence supplémentaire, il y aura inévitablement un impact sur l’expérience de l’utilisateur final. Pour la majorité du travail que les utilisateurs feront, ils verront la lenteur attendue liée aux aller-retour entre les brokers satellites et la base de données SQL.

Cependant, pour lancer des applications, il y a un point douloureux dans les sessions de courtage en fait. Ce point douloureux est dû à la nécessité de choisir le VDA le plus chargé sur lequel lancer une application. Cela se produit dans une transaction de base de données et nécessite un instantané de toutes les charges actuelles sur les VDA dans le groupe de mise à disposition. Pour ce faire, un verrou est retiré sur tous les travailleurs d’un groupe de mise à disposition, ce qui empêche les autres utilisateurs (entraîne la sérialisation) de prendre les mêmes verrous. Il attend et bloque également les changements d’état du travailleur (tels que les événements de session).

Avec une faible latence, le délai entre la prise des verrous et leur libération est très faible. Cependant, à mesure que la latence augmente, le temps que les verrous sont maintenus, et le temps pour les sessions de courtage augmente.

Pour la sauvegarder, nous avons examiné une variété de latences et de taux de lancement. Les latences sont les temps d’aller-retour (RTT) et ont été basées sur les statistiques de latence IP de Verizon. Notez que la plupart des RTT sont inférieurs aux valeurs maximales indiquées, mais nous voulions nous assurer que nous testons avec des RTT utiles.

Des durées aller-retour de 10 millisecondes (ms) couvrent la plupart des retards internationaux ; 45 ms couvrent l’Amérique du Nord, l’Europe et le Japon ; 90 ms couvre la Transatlantique ; 160 ms couvre la Trans-Pacifique, l’Amérique latine et l’Asie-Pacifique ; et 250 ms couvre l’EMEA vers l’Asie-Pacifique.

Nous avons testé avec une variété de demandes simultanées, couvrant des valeurs de 12 à 60 par incréments de 12.

Remarque : les sessions VDA sont simulées, car les tests sont axés sur l’impact de la latence sur le broker. Pour ce test, il y a 57 VDA dans un groupe de mise à disposition. Chaque test a tenté de lancer 10 000 utilisateurs.

10 ms RTT résultats          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (s) 0.9 1.4 1.6 2.1 2.6
Demandes auprès du broker par seconde 14 17.8 22.9 23.2 22.9
Erreurs (%âge) 0 0 0 0 0
Délai de lancement de 10 000 utilisateurs 11m 57s 9m 24s 7m 16s 7m 11s 7m 17s

Comme prévu, 10 ms est assez rapide pour gérer les charges placées sur le système, et il n’y a pas eu d’erreurs. C’est le moyen le plus rapide de lancer les utilisateurs. Au taux de lancement maximal de 60 utilisateurs simultanés, les temps de réponse moyens étaient de 2,6 secondes, ce qui a pris 7 minutes et 17 secondes pour lancer les 10 000 utilisateurs.

45 ms RTT résultats          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (s) 1.7 3.1 4.3 6.4 7.3
Demandes auprès du broker par seconde 7.1 7.8 8.4 7.5 8.2
Erreurs (%âge) 0 0 0 0.01 0.01
Délai de lancement de 10 000 utilisateurs 23m 28s 21m 19s 19m 51s 22m 15s 20m 19s

Avec 45 ms, les résultats étaient toujours bons. À des taux de lancement très élevés, un ou deux utilisateurs ont vu une erreur.

Remarque : L’impact de la sérialisation peut être vu sur les temps de réponse, avec une augmentation de 1,7 secondes à 7,3 secondes pour broker une session. Le temps total pour broker 10 000 utilisateurs était de 20 à 23 minutes.

90 ms RTT résultats          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (s) 2.9 6.4 9.5 12.9 16.2
Demandes auprès du broker par seconde 4.1 3.7 3.8 3.7 3.7
Erreurs (%âge) 0 0 0 0.01 0.01
Délai de lancement de 10 000 utilisateurs 40m 30s 44m 29s 44m 11s 44m 55s 45m 04s

Les résultats de 90 ms ont vu peu d’erreurs. Cependant, l’impact des transactions sur latence devient plus évident, les utilisateurs ayant un temps moyen acceptable de 2,9 secondes pour broker une session avec 12 demandes simultanées, passant à 16,2 secondes probablement inacceptable pour broker une session avec 60 demandes simultanées. Dans ce cas, il est en fait plus avantageux de broker des utilisateurs à un taux inférieur. Il a fallu 40 à 45 minutes pour lancer les 10 000 utilisateurs.

160 ms RTT résultats          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (s) 5.7 11.4 17.3 23.2 28.0
Demandes auprès du broker par seconde 2.1 2.1 2.1 2.1 2.1
Erreurs (%âge) 0 0 0.12 4.0 17.7
Délai de lancement de 10 000 utilisateurs 1 h 19m 0s 1 h 19m 27s 1 h 19m 55s 1 h 20m 26s S.O.

Avec les 160 ms, nous commençons à voir des erreurs significatives se produire avec des taux de lancement plus élevés, avec 4 % d’erreurs à 48 demandes, et 17,7 % d’erreurs à 60 demandes, avec des temps de réponse approchant 30 secondes. Cependant, jusqu’à 36 demandes, le taux d’erreur est de 0,1 % avec un temps moyen de courtage de 17 secondes.

Remarque : Il est difficile de juger du temps de lancement de 60 demandes, car 17 % d’échec est difficile à prendre en compte.

Avec cette latence, nous vous recommandons de ne pas transmettre 24 demandes simultanées. En outre, la taille du site peut être un facteur — lancer 1 000 utilisateurs prendrait environ 8 minutes. Cela pourrait atteindre une heure et 20 minutes pour 10 000 utilisateurs. Par conséquent, nous ne recommandons pas un site de grande taille avec ce niveau de latence à la base de données.

250 ms RTT résultats          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (s) 9.3 15.4 26.7 - -
Demandes auprès du broker par seconde 1.3 1.6 1.3 - -
Erreurs (%âge) 0 0 4.6 42.8 99.0
Délai de lancement de 10 000 utilisateurs 2h 8m 33s 1h 46m 52s 2h 3m 46s S.O. S.O.

Avec une latence aussi élevée, un grand nombre de temporisations se sont produites à des taux de lancement simultanés plus élevés. Sur 48 demandes, 42,8 % des demandes ont échoué. À 60 demandes, les délais d’attente étaient si fréquents que le Site serait inutilisable, puisque 99 % des demandes ont échoué. Les seuls taux de lancement acceptables étaient 12 et 24 demandes. Il serait difficile de recommander le déploiement d’un grand site avec ce niveau de latence : le lancement de 1 000 utilisateurs prend 13 minutes avec 12 demandes simultanées et 11 minutes avec 24 demandes simultanées. Cela prendrait jusqu’à 2 heures et 8 minutes pour 10 000 utilisateurs.

Demandes de limitation

Si vous devez travailler avec une latence élevée et constater que trop de délais d’expiration se produisent, une clé de Registre a été ajoutée à XenApp/XenDesktop 7.7 pour lui permettre de gérer uniquement un nombre fixe de demandes de courtage simultané. StoreFront réessayera les demandes au-delà de la limite après quelques secondes. Cela aidera à reculer les demandes, réduisant ainsi la file d’attente de verrouillage. Cependant, certains utilisateurs peuvent voir des délais de lancement prolongés, car ils sont toujours malchanceux et leur demande est toujours annulée.

La clé est un DWORD et doit être stockée dans :HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions

Si la clé n’existe pas, aucune limite sur les demandes de courtage n’est faite.

Remarque : la clé est par Delivery Controller, donc le total des demandes sur SQL Server doit être divisé entre les Controller distants.

Résumé

Le courtage fonctionne sur la latence, mais la latence doit être prise en compte pour le dimensionnement d’une zone distante. Si une zone est grande, il peut toujours être souhaitable de conserver une base de données locale dans cette zone. Si la zone est petite, l’utilisation d’une zone distante peut fonctionner correctement et réduire les coûts de gestion sans affecter l’expérience de l’utilisateur final.

Nous recommandons que vos zones disposent de moins de 250 ms de RTT ; au-delà de cela, vous devriez envisager de configurer différents sites.

Cet article a été modifié à partir d’un billet de blog écrit par Chris Gilbert. Pour lire le blog original et voir les commentaires, rendez-vous sur https://www.citrix.com/blogs/2016/02/09/zones-latency-and-brokering-performance-2/.

XenApp et XenDesktop 7.7 : zones, latence et performances de courtage