Jaki jest próg opóźnienia dla uruchomienia serwera terminali (RDS) przez sieć WAN?

11

Widziałem: wydajność serwera terminali w stosunku do łączy o wysokim opóźnieniu

Ale mam klienta, który jest zainteresowany przeniesieniem infrastruktury systemu do centrum danych, które ma opóźnienie ~ 62 ms od głównej siedziby.

Środowisko składa się z trzech serwerów RDS systemu Windows Server 2008 R2, usług plików i drukowania oraz Microsoft Exchange 2010. Wszystko to jest obecnie zwirtualizowane w klastrze vSphere 5.5. Łącznie 80 użytkowników łączy się lokalnie z systemami RDS przy użyciu cienkich klientów HP.

Z powodu problemów z urządzeniami oraz wzrostu liczby użytkowników zdalnych i zdalnych istnieje potrzeba przeniesienia systemów do centrum danych. Nowa witryna będzie zawierać wyższej klasy hosty vSphere i pamięć flash typu flash.

Łączność z obiektem kolokacji zostanie ustanowiona za pośrednictwem sieci VPN typu lokacja-lokacja z wieloma dostawcami usług internetowych i przełączaniem awaryjnym.

Czy to jednak zły pomysł? Często łączę się z tą witryną w celu prac konserwacyjnych nad RDP i SSH, wydajność jest całkiem do przyjęcia w moim przypadku użycia. Użytkownicy korzystają z podstawowego pakietu MS Office i kilku lekkich aplikacji ERP opartych na terminalach SSH.

Czy 62 ms jest uzasadnione dla tego typu obciążenia użytkownika i Microsoft RDS?

ewwhite
źródło
2
62ms nie brzmi okropnie, ale opóźnienie jest zabójcą wrażeń dla TS / RDS. Jeśli użytkownicy zaczną narzekać na opóźnienia w pisaniu, może to wskazywać na problem z opóźnieniem. Mój klient, który prowadzi farmę RDS z 300 użytkownikami, ma klientów na całym świecie, a największe problemy z wydajnością związane są z opóźnieniami. Użytkownicy, którzy są najdalej i mają największe opóźnienia, narzekają na wydajność. Czy można przetestować tylko garstkę użytkowników, aby sprawdzić ich wydajność?
joeqwerty
1
Rozkręcę testową maszynę wirtualną ... I może spróbuję połączyć podzbiór użytkowników.
ewwhite
1
Pamiętaj, aby wyłączyć „niepotrzebne animacje” w systemie Windows, co eliminuje potrzebę jawnego wyłączania go również w MS Office. Animacje sprawiają, że problemy z opóźnieniami stają się znacznie bardziej widoczne i marnują cenne pasmo, lepiej wykorzystywane do wysyłania odpowiednich aktualizacji ekranu. Office 2013 pod tym względem jest okropny na RDS / XenApp! Wyłączenie akceleracji sprzętowej grafiki w pakiecie Office może czasem poprawić wydajność i zmniejszyć problemy.
abstrask

Odpowiedzi:

11

Mam kilka tysięcy ludzi na całym świecie, którzy codziennie łączą się i korzystają z oprogramowania księgowego / biurowego. Tak długo, jak czasy odpowiedzi są poniżej 300 ms, nie otrzymujemy skarg, ale ymmv.

Jako dowód koncepcji skonfigurowałem jeden z naszych przełączników użytkownika za pomocą linux / netem box i zwiększałem opóźnienie / utratę pakietów, aż zacząłem mieć skargi. To było o wiele łatwiejsze do lokalnej replikacji warunków sieciowych, niż dwukrotne przenoszenie aplikacji.

Tim Brigham
źródło
Jak zmieniłeś opóźnienie / utratę pakietów?
ewwhite
@ewwhite Dodałem stary serwer w trybie pomostu między przełącznikiem użytkownika a routerem i ustawiłem parametry netem.
Tim Brigham,
1
Użyłem TMNetSim do symulacji doświadczenia użytkownika dla określonego opóźnienia. Zasadniczo konfigurujesz go za pomocą opcji „wdrożono na kliencie” i wskazujesz cel na 127.0.0.1. Symulator przekierowuje go do celu po podłączeniu z przepustowością sieci. tmurgent.com/appv/index.php/en/resources/tools/…
Greg Askew
1
+10 za eksperymentowanie z użytkownikami na żywo
Patrick
10

Wydaje mi się, że jest to subiektywne, ponieważ niektórzy użytkownicy nie będą zadowoleni, chyba że opóźnienie będzie podobne do korzystania z lokalnego pulpitu, a inni użytkownicy będą zadowoleni i nie będą narzekać, nawet jeśli opóźnienie wynosi 300 ms.

Prawdą jest jednak, że opóźnienie jest zabójcze dla użytkownika, dokładnie o ile zależy ono od indywidualnego postrzegania.

To całkiem niezły film z TechEd 2014 na temat wrażeń użytkownika w scenariuszach podobnych do tego (ten film dotyczy VDI, ale jest podobny do usług pulpitu zdalnego).

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

Więc możesz powiedzieć, nigdy nie przekraczaj 300ms. 62ms to prawdopodobnie „OK”.

Ryan Ries
źródło
5

Odpowiedź na to pytanie nie jest prawdziwie uniwersalna i obiektywna. Wyniki naprawdę zależą od rodzaju obciążenia i wymagań użytkowników. Nie ma nic lepszego niż testy UX.

Często pracuję zdalnie przez RDP z różnych lokalizacji, przez większość czasu łącząc się przez sieć LTE (4G), która oferuje opóźnienia podobne do 62 ms. W tej chwili jestem w hotelu z wolnym ~ 1 Mbit / s opóźnieniami ~ 27-28 ms - mniej niż połowa wartości w twoim przypadku. Nawet przy tej ostatniej wartości mam trudności z przeglądaniem stron internetowych lub oglądaniem dużej grafiki (szczególnie bez AdBlocka, witryny bogate w grafikę mogą renderować przez kilka sekund w przeglądarce Firefox!). Również próba napisania prostego dokumentu przy użyciu programu Microsoft Word wywołała frustrację z powodu poniŜej średniej odpowiedzialności za interfejs (z kolei LibreOffice Writer poczuł się znacznie lepiej). Nie wspominając nawet o pracy z filmami ... Mogę dość wygodnie pracować z MMC, pocztą Outlook (do pewnego stopnia), przeglądaniem plików i ogólnie zadaniami administracyjnymi systemu.

Ta wartość powinna być odpowiednia do zdalnego administrowania systemem i podobnych zadań wykonywanych rutynowo i mających doświadczenie. Ale jeśli ma całkowicie zastąpić lokalny ekran, oczekiwałbym frustracji i narzekał.

Jedną rzecz do dodania - pracuję pod Ubuntu, a rdesktop 1.7.1 jest moim wybranym klientem RDP. W oryginalnym kliencie Microsoftu (lub innych) mogą istnieć pewne optymalizacje, które mogą poprawić wydajność dzięki linkom o wysokim opóźnieniu.

sam_pan_mariusz
źródło
4

Opóźnienie poniżej 100 ms prawdopodobnie nie będzie stanowiło problemu, chyba że klienci grają w tę sieć . Jednak w niektórych aplikacjach intensywnie korzystających z grafiki może zabraknąć przepustowości (szczególnie w przypadku odtwarzania wideo), co negatywnie wpłynie na opóźnienie i spowoduje jego przekroczenie znacznie powyżej 100 ms, irytując użytkowników.

RDP 8 (Server 2012 i nowsze) zawiera optymalizacje (czytaj: algorytmy kompresji stratnej) dla tych scenariuszy. Ponadto obsługa transportu UDP poprawi jakość obsługi użytkownika przez łącza o znacznie różnych opóźnieniach lub zauważalnych stratach pakietów (> 0,1%). Więc jeśli masz którekolwiek z nich, możesz chcieć uaktualnić hosty sesji RD.

the-wabbit
źródło
To zdecydowanie opcja. Nie zdawałem sobie sprawy, że 2012 oferuje te korzyści. Czy korzyści te nadal obowiązywałyby, gdyby urządzeniami źródłowymi były cienkie klienty HP z systemem Linux?
ewwhite
@ewwhite tylko wtedy, gdy ciency klienci rzeczywiście obsługują protokół RDP8. Rdesktop (popularny klient Linux RDP) obecnie tego nie robi, FreeRDP (widelec Rdesktop) twierdzi, że obsługuje RDP8 , ale bliższe spojrzenie na listę funkcji pokazuje, że jest to głównie RDP7. YMMV, ponieważ ostatecznie nie wiem, czego HP używa. Klienci Windows obsługują RDP8 począwszy od Embedded Standard 7
the-wabbit
ThinPro HP jest rdesktop. Szkoda, ponieważ wielu z tych klientów zostało zakupionych przez lata. Klient właśnie kupił najcieńszego klienta, który był najtańszy.
ewwhite
@ewwhite Rozumiem, dlaczego - klienci Windows Embedded mają duże wymagania sprzętowe i koszty licencji. Patrząc na całkowity koszt zakupu, równie dobrze możesz kupować tanie komputery biznesowe Windows i używać ich jako klientów RDP.
the-wabbit