Logon Performance #1 – XenDesktop Hotfix

Cet article me permet d’introduire un nouvel ami de Phenisys : uberAgent ! Cet outil fonctionne exclusivement sur Splunk Enterprise et utilise un système d’agents à placer sur les serveurs à observer. La grande majorité de ses métriques sont tirés des API Microsoft/Citrix/VMware et uberAgent se positionne donc comme un outil d’analyse de performances système. Le […]

JTJonas Tremsal/23 février 2016/3 min de lecture
ScreenLaunchApp

Cet article me permet d’introduire un nouvel ami de Phenisys :uberAgent! Cet outil fonctionne exclusivement sur Splunk Enterprise et utilise un système d’agents à placer sur les serveurs à observer. La grande majorité de ses métriques sonttirés des API Microsoft/Citrix/VMwareet uberAgent se positionne donc comme unoutil d’analyse de performances système.

Le contexte

Phenisys ayant récemment monté un lab’ XenDesktop 7.6 à des fins de R&D, nous avons été très surpris de constater un grand écart entre le temps deconnexion via XenDesktop, qui dépassait allègrement les12 secondes via ICA (HDX)et celui viaRDP qui plafonnait à 2,5 secondesseulement. Et en regardant bien le moniteur à l’ouverture de la session XenDesktop, on constate également un écran noir durant quelques secondes.

Certes notre lab’ ne respecte pas forcement les bonnes pratiques Citrix mais de là à multiplier par 5 le temps de connexion …

C’est en parcourant le blog de uberAgent que je suis tombé sur unarticledu fondateur détaillant exactement les symptômes rencontrés.

Analyse en profondeur

Penchons-nous en détail sur les différents éléments permettant à UberAgent de statuer un « Logon Duration » de 12,11 secondes, en commençant par l’état du serveuren terme de CPU/RAM/Réseauà ce moment-là :

On ne remarquerien d’anormalsur les métriques serveurs si ce n’est unléger pic CPUde 5% à l’ouverture de la session, pas de quoi s’alarmer.

Analysons maintenant le premier maillon des actions menées durant un logon, ladécouverte de l’Active Directory:

330 ms, notre AD01, serveur d’authentification de notre utilisateur Administrateur, se porte bien.Cen’est donc pas lui qui pose problème.

Regardons maintenant les seconds acteurs d’une ouverture de session, j’ai nommé lesStratégies de Groupes:

Ladurée totale de l’application des stratégiesa pris … la bagatelle de15 ms! On est encore bien loin des 12 secondes énoncées plus haut.

Continuons à forer en observant ledétail des processus systèmequi se sont exécutés pour notre utilisateur :

On observeun fossé de 10 secondesentre la fin de l’application des Stratégies de Groupes et le Userinit.exe, qui a la mission de déclencher l’Explorer.exe, lui-même chargé de nous offrir un environnement graphique.

Résolution

Grâce à l’article de uberAgent cité plus haut, la solution fut rapidement trouvée : unpatch à appliquer. (http://support.citrix.com/article/CTX142036)

Le Hotfix corrige, je cite, «When starting a published application, users can experience slow logons.»

Installons-le et observons la magie de l’informatique opérer …

… et nous offrir untemps de connexion divisé par plus de deux fois!

On constate bien qu’entre l’application des Stratégies et le lancement de Userinit,il ne s’écoule plus 10 secondes mais seulement 2 secondes.

Conclusion

Citrixest définitivement une solutiondifficile à diagnostiquer. Toutefois, en s’appuyant sur un outil comme UberAgent, le temps d’analyse est nettementaccéléréet permet deplacer des indicateurssur des actions et d’enmesurertous leurs bienfaits, ou à l’inverse pouvoir rapidementfairemachine arrière en voyant les métriques s’envoler.


Avez-vous jeté un oeil sur la partie 2 concernant la concurrence d’accès à l’ouverture de session ? Non ? Alors c’est par ici !

JT

Jonas Tremsal

Consultant NPM

Auteur