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

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?

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.

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”.

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.

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.