Qual è la soglia di latenza per l'esecuzione di un Terminal Server (RDS) sulla WAN?

11

Ho visto: prestazioni del server terminal su collegamenti ad alta latenza

Ma ho un cliente interessato a trasferire la propria infrastruttura di sistema in un datacenter che ha una latenza di ~ 62ms dalla sede principale.

L'ambiente è composto da un trio di server RDS di Windows Server 2008 R2, servizi di file e stampa e Microsoft Exchange 2010. Attualmente è tutto virtualizzato su un cluster vSphere 5.5. Esistono 80 utenti totali che attualmente si connettono localmente ai sistemi RDS utilizzando i thin client HP.

A causa di problemi alla struttura e di un aumento degli utenti fuori sede e remoti, c'è una spinta a spostare i sistemi in una struttura di data center. Il nuovo sito includerà host vSphere di fascia alta e storage all-flash.

La connettività alla struttura di co-locazione verrà stabilita tramite VPN da sito a sito con più ISP e failover in atto.

È una cattiva idea, però? Mi collego a questo sito spesso per lavori di manutenzione su RDP e SSH, le prestazioni sono abbastanza accettabili per il mio caso d'uso. Gli utenti utilizzano la suite MS Office di base e un paio di leggere applicazioni ERP basate su terminali SSH.

62ms è ragionevole per questo tipo di caricamento utente e Microsoft RDS?

— ewwhite
fonte

2

62ms non sembra terribile, ma la latenza è un killer di esperienza per TS / RDS. Se gli utenti iniziano a lamentarsi di ritardi in cose come la digitazione, potrebbe indicare un problema di latenza. Il mio cliente che gestisce una farm RDS da 300 utenti ha clienti in tutto il mondo e i maggiori problemi di prestazioni sono legati alla latenza. Gli utenti più lontani e con la più alta latenza sono quelli che si lamentano delle prestazioni. È possibile testare con solo una manciata di utenti per avere un'idea delle loro prestazioni?

— joeqwerty,

1

Farò girare una VM di prova ... E forse proverò a connettere un sottoinsieme di utenti.

— ewwhite,

1

Assicurati di disattivare "animazioni non necessarie" in Windows, il che elimina la necessità di disabilitarla esplicitamente anche in MS Office. Le animazioni rendono i problemi di latenza molto più evidenti e sprecano preziosa larghezza di banda, meglio utilizzata per inviare aggiornamenti dello schermo pertinenti. In questo senso, Office 2013 è terribile su RDS / XenApp. Inoltre, la disabilitazione dell'accelerazione HW grafica in Office a volte può migliorare le prestazioni e ridurre i problemi.

— abstrask

11

Ho diverse migliaia di persone in tutto il mondo che si connettono e utilizzano quotidianamente software di contabilità / ufficio. Finché i loro tempi di risposta sono inferiori a 300 ms non riceviamo lamentele ma ymmv.

Come prova del concetto ho impostato uno degli switch del nostro utente usando una scatola linux / netem e ho continuato a spingere verso l'alto la perdita di latenza / pacchetto fino a quando ho iniziato a lamentarmi. È stato molto più facile replicare localmente le condizioni della rete, quindi spostare due volte le mie applicazioni.

— Tim Brigham
fonte

Come hai modificato la latenza / la perdita di pacchetti?

— ewwhite,

@ewwhite Ho aggiunto un vecchio server in modalità bridge tra uno switch utente e il router e scosso da parametri netem.

— Tim Brigham,

1

Ho usato TMNetSim per simulare l'esperienza dell'utente per una latenza specifica. Fondamentalmente lo si configura usando l'opzione "distribuito sul client" e si punta il target su 127.0.0.1. Il simulatore lo reindirizza alla destinazione dopo aver effettuato il jack con il throughput di rete. tmurgent.com/appv/index.php/en/resources/tools/…

— Greg Askew il

1

+10 per la sperimentazione su utenti live

— Patrick,

10

Sento che questo è un po 'soggettivo, poiché alcuni utenti non saranno felici a meno che la latenza non sia proprio come un'esperienza desktop locale, e altri utenti saranno felici e non si lamenteranno anche se la latenza è 300ms.

È vero che la latenza è un killer dell'esperienza dell'utente, tuttavia, esattamente quanto è una questione di percezione individuale.

Questo è un video abbastanza buono di TechEd 2014 sull'esperienza utente in scenari simili a questo (questo video parla di VDI, ma è un'esperienza simile ai Servizi Desktop remoto.)

https://www.youtube.com/watch?v=CcKAwzebHoc&feature=youtu.be

Quindi potresti dire, non andare mai oltre i 300ms. 62ms è probabilmente "OK".

— Ryan Ries
fonte

5

Non è possibile rispondere a questa domanda in modo veramente universale e oggettivo. I risultati dipendono davvero dal tipo di carico di lavoro e dalle esigenze degli utenti. Niente può essere migliore qui dei test UX.

Lavoro spesso in remoto su RDP da diverse posizioni, il più delle volte collegandomi tramite rete LTE (4G) che offre latenze simili a 62 ms. In questo momento sono in un hotel con una connessione lenta ~ 1 Mbit / s e latenze ~ 27-28 ms - meno della metà del valore nel tuo caso. Anche con quest'ultimo valore, faccio fatica a navigare o visualizzare grafica di grandi dimensioni (specialmente senza AdBlock, i siti ricchi di grafica possono essere visualizzati per pochi secondi in Firefox!). Anche un tentativo di scrivere un semplice documento usando Microsoft Word ha generato una certa frustrazione a causa di una responsabilità dell'interfaccia inferiore alla media (a sua volta LibreOffice Writer si è sentito molto meglio). Per non parlare del lavoro con i video ... Le cose su cui posso lavorare abbastanza comodamente sono MMC, Outlook Mail (in una certa misura), esplorazione dei file e generalmente attività di amministrazione del sistema.

Questo valore dovrebbe essere OK per l'amministrazione del sistema remoto e attività simili che esegui abitualmente e con cui hai esperienza. Ma se si tratta di sostituire completamente lo schermo locale mi aspetterei frustrazione e lamentele.

Una cosa da aggiungere: lavoro sotto Ubuntu con rdesktop 1.7.1 come mio client RDP preferito. Potrebbero esserci alcune ottimizzazioni nel client originale (o in altri) di Microsoft che possono migliorare le prestazioni con collegamenti ad alta latenza.

— sam_pan_mariusz
fonte

4

La latenza inferiore a 100 ms probabilmente non sarà un problema a meno che i tuoi clienti non stiano giocando su questa rete . Ma potresti esaurire la larghezza di banda in alcune applicazioni ad alta intensità grafica (in particolare le riproduzioni video) che influiranno negativamente sulla latenza e la spingeranno oltre i 100 ms, infastidendo i tuoi utenti.

RDP 8 (Server 2012 e versioni successive) include ottimizzazioni (leggi: algoritmi di compressione con perdita) per questi scenari. Inoltre, il supporto del trasporto UDP migliorerà l'esperienza dell'utente rispetto ai collegamenti con latenza significativamente variabile o notevoli perdite di pacchetti (> 0,1%). Quindi, se ne hai uno, potresti voler aggiornare i tuoi host di sessione RD.

— the-Wabbit
fonte

Questa è sicuramente un'opzione. Non mi ero reso conto che il 2012 offrisse quei benefici. Tali vantaggi sarebbero comunque applicabili se i dispositivi di origine sono thin client basati su HP Linux?

— ewwhite,

@ewwhite solo se i thin client supportano effettivamente RDP8. Rdesktop (un popolare client Linux RDP) al momento no, FreeRDP (un fork Rdesktop) sta sostenendo di supportare RDP8 , ma uno sguardo più da vicino all'elenco delle funzionalità mostra che è principalmente RDP7. YMMV poiché non so cosa stia usando HP alla fine. I client Windows supportano RDP8 a partire da Embedded Standard 7

— the-wabbit il

HP ThinPro è rdesktop. È un peccato, perché molti di questi clienti sono stati acquistati nel corso degli anni. Il cliente ha appena acquistato il thin client più economico.

— ewwhite,

@ewwhite Posso capire perché: i client Windows Embedded presentano requisiti hardware e costi di licenza importanti. Considerando il costo complessivo di acquisto, potresti anche acquistare desktop Windows di fascia bassa e utilizzarli come client RDP.

— the-wabbit il