Scopri il collo di bottiglia per il server desktop remoto di Windows (Terminal server)


11

Ho Windows Server 2008 R2 (SP1) installato sul mio host VMware per funzionare come server RDS. A volte i miei utenti remoti possono vedere il ritardo / ritardo sul server RDS. Qualcuno può dirmi dalla loro esperienza quali sono le migliori pratiche per trovare il collo di bottiglia per questo server?


1
Cosa hai fatto per cercare di rintracciare la latenza? I client sono su una rete locale? Composizione delle apparecchiature di rete? Sono tutti in ritardo allo stesso tempo? Risorse del server; processore / i, RAM, disco? Monitoraggio delle prestazioni? Versioni client, estensione, RemoteFX?
Chris S,

Se stai eseguendo un TS, come una VM, quante CPU virtuali hai assegnato? Potresti stare meglio con più macchine virtuali con un numero inferiore di CPU.
Zoredache,

Grazie per i suggerimenti Non ho fatto nulla per rintracciare la latenza. Proverò a capire passo dopo passo ...
Hemal,

Risposte:


16

Come ha detto Chris S, ci sono diverse cose che possono contribuire a scarse prestazioni del desktop remoto. Dalla mia esperienza, queste sono le cause principali, in ordine di probabilità.

Larghezza di banda
La causa numero 1 delle scarse prestazioni con il desktop remoto è la mancanza di larghezza di banda. A seconda esattamente di ciò che viene fatto, una sessione può usare ovunque da alcuni Kbps a pochi Mbps di larghezza di banda. I miei test hanno dimostrato che lo scorrimento di un PDF utilizzerà fino a 3 Mbps. Poiché la larghezza di banda disponibile diminuisce, diminuiscono anche le prestazioni percepite.

È innanzitutto necessario determinare le esigenze di larghezza di banda dell'applicazione. Ciò richiede il test in un ambiente LAN controllato, quindi la misurazione dell'utilizzo della larghezza di banda durante l'esecuzione delle normali attività. Personalmente ho avuto successo con NetLimiter sulla mia workstation personale. Puoi anche affrontare il problema da un'altra angolazione e utilizzare NetLimiter per forzare la velocità della tua connessione a qualunque sia la tua valutazione WAN. Questo dovrebbe dare una buona indicazione di ciò che vedono i tuoi utenti remoti.

Una volta a conoscenza della larghezza di banda richiesta dall'applicazione, è necessario determinare se si tratta del fattore limitante. Innanzitutto, misurare la larghezza di banda disponibile tra il client e il server. Uno strumento eccellente per questo è iperf. Presumo che tu abbia sufficiente larghezza di banda disponibile durante un test controllato.

Successivamente, vorrai impostare una sorta di monitoraggio della larghezza di banda per vedere se i problemi segnalati dall'utente sono correlati a picchi di traffico o altri indesiderabili. La mia preferenza è scaricare il traffico da uno switch o un router in ntop, poiché fornisce utili report storici e in tempo reale sull'utilizzo della larghezza di banda.

Se si verificano problemi di larghezza di banda, una semplice modifica è modificare le impostazioni "Esperienza" sulla connessione desktop remoto. Disabilita gli stili di visualizzazione e le animazioni e molte operazioni sul desktop sembreranno magicamente più veloci.

Latenza
Un altro problema comune con le connessioni desktop remoto è la latenza. È necessario un tempo di andata e ritorno ragionevolmente rapido tra client e server, altrimenti le persone saranno in grado di percepire un ritardo. Come regola generale, la maggior parte delle persone inizia a notare problemi con tempi di ping compresi tra 50 e 100 ms.

Fortunatamente, questo è di solito facile da diagnosticare. È possibile configurare strumenti di monitoraggio come SmokePing o PRTG Network Monitor per fornire report sulla latenza tra il server di monitoraggio e qualsiasi altro host arbitrario. Puoi anche semplicemente usare il ping -tcomando integrato per sessioni brevi. Normalmente si desidera individuare il server di monitoraggio sulla stessa LAN del server desktop remoto, quindi impostare il monitoraggio sia sul server che sui client. Prova a correlare le segnalazioni di problemi con incidenti con tempo di ping elevato.

In caso di problemi con tempi di ping elevati, utilizzare tracerouteper scoprire dove viene introdotto il ritardo. Se si determina che il problema risiede nella propria rete, prendere in considerazione l'introduzione del filtro QoS per dare priorità al traffico in tempo reale come Desktop remoto.

Inoltre, fai attenzione a chiunque si connetta tramite un supporto wireless, che sia 802.11 (WiFi) o, peggio, una connessione satellitare. Le connessioni wireless sono soggette a interferenze ambientali che possono causare problemi di latenza estrema in varie condizioni e per periodi di tempo variabili. E l'utilizzo del desktop remoto attraverso un satellite fa sempre schifo.

CPU o memoria locale E infine, è possibile che il tuo server sia semplicemente sovraccarico. Monitorare l'utilizzo della CPU e della memoria, soprattutto nelle ore di punta, per garantire che il server sia in grado di soddisfare le richieste in modo tempestivo.

Uno degli strumenti sopra menzionati (PRTG) può essere impostato per monitorare l'utilizzo della CPU e della memoria di un server nel tempo e può produrre grafici che semplificano la correlazione dei rapporti sui problemi con errori specifici.

Suggerimento bonus: se gli utenti hanno problemi a digitare, soprattutto per quanto riguarda i tasti modificatori che non si applicano correttamente, prova a modificare le impostazioni della tastiera sul collegamento alla connessione Desktop remoto in modo che Applica combinazioni di tasti Windows sia impostato su On the local computer.


Bella risposta. Gestisco una farm di 20 server TS e le 2 cause più comuni di problemi di prestazioni che vediamo sono i 2 elencati per primi nella risposta: larghezza di banda e latenza. A mio avviso, questi 2 fattori hanno il maggiore impatto sulle prestazioni (o sulle prestazioni percepite). I miei test hanno dimostrato che un utente che esegue diverse applicazioni di Office, IE e apre file PDF ha consumato in media 100 Kbps in un periodo di 8 ore. Questo è ciò che il nostro numero di pianificazione è in termini di allocazione della larghezza di banda per utente ed è quello che raccomandiamo ai nostri clienti per avere sessioni "ben funzionanti".
joeqwerty,

Ciao Nic, grazie mille per la bella risposta dettagliata. Lo esaminerò e proverò a capirlo .. Grazie mille per la risposta. Grazie a Joeqwerty anche per i commenti ..
Hemal,

Gestisco una piccola fattoria e sono d'accordo. Utilizziamo anche PRTG per verificare se i dati storici corrispondono a problemi segnalati. I nostri problemi numero due sono lo switch di banda (problemi locali / ISP) e la CPU (programmi errati su server con numero di core basso). Il modo migliore per vedere rapidamente se la larghezza di banda è chiedere agli utenti se l'immissione di testo sembra ritardare.
Gomibushi,

Hai citato molti ottimi strumenti, ma quanti requisiti di larghezza di banda di una sessione possono essere raccolti tramite WMI? o ancora migliori contatori delle prestazioni? Sono nuovo di TS, ma mi è stato assegnato il compito di presentare varie statistiche in una sessione. Grazie in anticipo per il tuo tempo.
codeputer,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.