Découvrez le goulot d'étranglement du serveur Windows Remote Desktop (serveur Terminal Server)


11

J'ai Windows Server 2008 R2 (SP1) installé sur mon hôte VMware pour fonctionner comme serveur RDS. Parfois, mes utilisateurs distants peuvent voir le retard / retard sur le serveur RDS. Quelqu'un peut-il me dire d'après son expérience quelles sont les meilleures pratiques pour trouver le goulot d'étranglement pour ce serveur?


1
Qu'avez-vous fait pour essayer de dépister la latence? Les clients sont-ils sur un réseau local? Composition de l'équipement réseau? Est-ce qu'ils traînent tous en même temps? Ressources serveur; processeur (s), RAM, disque? Moniteur de performances? Versions client, extension, RemoteFX?
Chris S

Si vous exécutez un TS, en tant que machine virtuelle, combien de processeurs virtuels avez-vous attribués? Vous pouvez être mieux avec plusieurs VM avec un plus petit nombre de CPU.
Zoredache

Merci pour les suggestions. Je n'ai rien fait pour retrouver la latence. Je vais essayer de comprendre étape par étape ...
Hemal

Réponses:


16

Comme Chris S l'a mentionné, plusieurs éléments peuvent contribuer à de mauvaises performances du bureau à distance. D'après mon expérience, ce sont les principales causes, par ordre de probabilité.

Bande passante
La cause n ° 1 des performances médiocres avec le bureau à distance est le manque de bande passante. Selon ce qui est fait exactement, une session peut utiliser de quelques kbps à quelques Mbps de bande passante. Mes propres tests ont montré que faire défiler un PDF consommerait jusqu'à 3 Mbps. À mesure que la bande passante disponible diminue, les performances perçues augmentent également.

Vous devez d'abord déterminer les besoins en bande passante de votre application. Cela nécessite de tester dans un environnement LAN contrôlé, puis de mesurer l'utilisation de la bande passante lorsque vous effectuez des tâches normales. J'ai personnellement eu du succès avec NetLimiter sur mon poste de travail personnel. Vous pouvez également aborder le problème sous un autre angle et utiliser NetLimiter pour forcer votre vitesse de connexion à la valeur nominale de votre connexion WAN. Cela devrait donner une bonne indication de ce que voient vos utilisateurs distants.

Une fois que vous connaissez la bande passante souhaitée par votre application, vous devez déterminer s'il s'agit du facteur limitant. Tout d'abord, mesurez la bande passante disponible entre le client et le serveur. Un excellent outil pour cela est iperf. Je suppose que vous disposez d'une bande passante suffisante lors d'un test contrôlé.

Ensuite, vous souhaiterez configurer une sorte de surveillance de la bande passante pour voir si les problèmes signalés par les utilisateurs sont en corrélation avec des pics de trafic ou d'autres indésirables. Ma préférence est de vider le trafic d'un commutateur ou d'un routeur vers ntop, car il fournit des rapports utiles en temps réel et historiques sur l'utilisation de la bande passante.

Si vous rencontrez des problèmes de bande passante, une modification simple consiste à modifier les paramètres "Expérience" sur la connexion du bureau à distance. Désactivez les styles visuels et les animations, et de nombreuses opérations de bureau sembleront magiquement plus rapides.

Latence
Un autre problème courant avec les connexions de bureau à distance est la latence. Il doit y avoir un temps d'aller-retour raisonnablement rapide entre le client et le serveur, sinon les gens pourront percevoir un retard. En règle générale, la plupart des gens commencent à remarquer des problèmes entre 50 et 100 ms de temps de ping.

Heureusement, cela est généralement facile à diagnostiquer. Vous pouvez configurer des outils de surveillance tels que SmokePing ou PRTG Network Monitor pour fournir des rapports sur la latence entre votre serveur de surveillance et tout autre hôte arbitraire. Vous pouvez même simplement utiliser la ping -tcommande intégrée pour de courtes sessions. Normalement, vous souhaitez localiser le serveur de surveillance sur le même réseau local que votre serveur de bureau distant, puis configurer la surveillance par rapport au serveur et à vos clients. Essayez de corréler les rapports de problèmes avec les incidents de temps de ping élevé.

Si vous rencontrez des problèmes avec des temps de ping élevés, utilisez traceroutepour savoir où le retard est introduit. Si vous déterminez que le problème réside dans votre propre réseau, pensez à introduire le filtrage QoS pour prioriser le trafic en temps réel comme Remote Desktop.

Aussi, méfiez-vous de toute personne qui se connecte sur un support sans fil, que ce soit 802.11 (WiFi), ou pire, une connexion satellite. Les connexions sans fil sont sujettes à des interférences environnementales qui peuvent provoquer des problèmes de latence extrêmes dans diverses conditions et pour des périodes de temps variables. Et utiliser un bureau à distance via un satellite est toujours nul.

CPU local ou mémoire Et enfin, il est possible que votre serveur soit simplement surchargé. Surveillez l'utilisation du processeur et de la mémoire, en particulier pendant les heures de pointe, pour vous assurer que le serveur est capable de répondre aux demandes en temps opportun.

L'un des outils mentionnés ci-dessus (PRTG) peut être configuré pour surveiller l'utilisation du processeur et de la mémoire d'un serveur au fil du temps, et peut produire des graphiques qui facilitent la corrélation des rapports de problèmes avec des erreurs spécifiques.

Astuce bonus: si vos utilisateurs ont du mal à taper, en particulier en ce qui concerne les touches de modification qui ne s’appliquent pas correctement, essayez de modifier les paramètres de votre clavier sur le raccourci de connexion Bureau à distance afin que Appliquer les combinaisons de touches Windows soit défini sur On the local computer.


Bonne réponse. Je gère une ferme de 20 serveurs TS et les 2 causes les plus courantes de problèmes de performances que nous voyons sont les 2 que vous avez répertoriées en premier dans votre réponse: bande passante et latence. Ces 2 facteurs ont le plus grand impact sur la performance (ou la performance perçue) à mon avis. Mes propres tests ont montré qu'un utilisateur exécutant plusieurs applications Office, IE et ouvrant des fichiers PDF consommait en moyenne 100 Kbps sur une période de 8 heures. C'est ce que nous prévoyons en termes d'allocation de bande passante par utilisateur et c'est ce que nous recommandons à nos clients pour avoir des sessions "performantes".
joeqwerty

Salut Nic, Merci beaucoup pour la belle réponse détaillée. Je vais le parcourir et essayer de le comprendre .. Merci beaucoup pour la réponse. Merci également à Joeqwerty pour ses commentaires ..
Hemal

Je gère une petite ferme et je suis d'accord. Nous utilisons également PRTG pour voir si les données historiques correspondent aux problèmes signalés. Nos problèmes numéro deux sont le bandwitch (problèmes locaux / FAI) et le CPU (mauvais programmes sur les serveurs à faible nombre de cœurs). La meilleure façon de voir rapidement si sa bande passante est de demander aux utilisateurs si la saisie de texte semble en retard.
Gomibushi

Vous avez mentionné de nombreux excellents outils, mais quelle quantité de bande passante pour les sessions peut être collectée via WMI? ou encore de meilleurs compteurs de performances? Je suis nouveau sur TS, mais j'ai été chargé de faire apparaître diverses statistiques sur une session. Merci d'avance pour votre temps.
codeputer

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.