Dlaczego RDP działa wolno, choć łącze jest szybkie? – osobno badamy wejście, rysowanie i komunikację

Test prędkości pokazuje kilkaset Mb/s, a mimo to w pulpicie zdalnym znaki pojawiają się z lekkim opóźnieniem. Przy przewijaniu strony z wieloma zdjęciami obraz się zacina. Aplikacja biznesowa zatrzymuje się na kilka sekund tylko po kliknięciu wyszukiwania. Od czego zacząć diagnozę takiego stanu, w którym „łącze jest szybkie, a RDP działa wolno”?

Szybkość reakcji RDP na czynności nie zależy wyłącznie od szybkości transferu łącza. Nawet przy dobrym wyniku testu prędkości oczekiwanie może pojawić się w dowolnym z tych miejsc: przesył w obie strony, oczekiwanie na wejście w aplikacji na komputerze zdalnym, kodowanie obrazu albo dekodowanie i wyświetlanie na komputerze lokalnym. Najpierw ustal, „która czynność jest wolna”, i porównuj tę samą czynność, zmieniając warunki pojedynczo. Porównania i pomiary zawężają obszar diagnozy, a ustawienia UDP i GPU dobiera się do ich wyników. Zob. odcinki pomiaru jakości połączenia, czynniki wydajności hosta sesji.

Na etapie zawężania obszaru diagnozy przyczyna źródłowa nie jest jednak jeszcze ustalona. Nawet jeśli obniżenie rozdzielczości przynosi poprawę, zmienia się nie tylko komunikacja, lecz także przetwarzanie obrazu po obu stronach, dlatego nie przesądzamy, że „przyczyną było łącze”. Wyniki zapisuje się, oddzielając odcinki zmierzone od niezmierzonych.

W tym artykule diagnozujemy wpisywanie, przewijanie i reakcje aplikacji po nawiązaniu połączenia. Podobne objawy nie muszą mieć jednej przyczyny. Przypadki typu „długo trwa, zanim pojawi się ekran logowania” lub „zatrzymuje się tylko na uwierzytelnianiu” traktujemy jako osobny problem, który bada się na podstawie zapisów nawiązywania połączenia i uwierzytelniania.

Artykuł jest przeznaczony głównie dla użytkowników i administratorów, którzy łączą się z Windows 11 lub Windows Server za pomocą aplikacji Windows „Podłączanie pulpitu zdalnego” (mstsc). Przykłady poleceń są przeznaczone dla Windows PowerShell 5.1. Zakładamy, że tę samą czynność można odtworzyć w już nawiązanej sesji.

Połączenie bezpośrednie, VPN, RD Gateway i Azure Virtual Desktop różnią się ścieżką, dostępnymi informacjami diagnostycznymi i tym, do czego stosuje się ustawienia. Przykład sprawdzania TCP 3389 dotyczy wyłącznie dozwolonego połączenia bezpośredniego z hostem RDP używającym standardowego portu. Funkcji diagnostycznych i ustawień GPU z dokumentacji dla Azure Virtual Desktop nie przenosimy bez zmian na zwykłe komputery firmowe.

Na urządzeniach firmowych diagnozę prowadzi się w zakresie dozwolonym przez administratora. Na współdzielonym hoście zidentyfikuj własną sesję i badany proces, a jeśli potrzebne są dane innych użytkowników, poproś o nie administratora. Dostępność liczników wydajności, ich nazwy wyświetlane i wymagane uprawnienia sprawdza się w każdym środowisku.

Przedstawione tu metody sprawdzania opierają się na oficjalnej dokumentacji. Nie jest to raport z pomiarów, w których odtworzono i usunięto awarię na konkretnym urządzeniu. Przykłady liczbowe wyraźnie oznaczamy jako założenia służące wyjaśnieniu.

Mechanizm można poznawać po kolei, zaczynając od następnej sekcji „Szybkość transferu a czas w obie strony”. Jeśli chcesz zacząć od objawów, przejdź do sekcji „Pierwsze porównanie według objawów”. Procedury znajdują się w sekcjach „Porównywanie warunków pojedynczo” i „Pomiar miejsca oczekiwania”.

Na diagramie linia ciągła oznacza relację, która zachodzi zawsze, a linia przerywana relację warunkową (warunki podano przy każdej relacji na stronie szczegółów). Pełną listę relacji (łącznie 7, wraz z uzasadnieniem i pewnością) oraz definicje głównych pojęć zebrano na stronie szczegółów mapy wiedzy (w języku japońskim). Dane: JSON-LD / Turtle

Szybkość transferu a czas w obie strony

RDP (Remote Desktop Protocol) to protokół, za pomocą którego urządzenie lokalne i komputer zdalny wymieniają m.in. dane wejściowe i informacje o obrazie ekranu. Obsługuje nie tylko obraz i wejście, lecz także dane przekierowania urządzeń, drukowania itp. Zob. informacje przesyłane przez RDP.

Szybkość transferu łącza określa, ile danych można przenieść w ciągu sekundy. „500 Mb/s” z testu prędkości to liczba dotycząca tej ilości. Nie jest to liczba, która pokazuje czas od wykonania czynności do nadejścia odpowiedzi. Zob. wymagania RDP dotyczące przepustowości.

flowchart TB
    accTitle: Co oznacza wynik testu prędkości
    accDescr: Pokazuje, że 500 Mb/s z testu prędkości to ilość danych przenoszona w ciągu sekundy, a więc inna liczba niż czas od wykonania czynności do nadejścia odpowiedzi.
    A["Test prędkości: 500 Mb/s"] --> B["Dane przenoszone w sekundę"]
    B -.->|"inna liczba"| C["Czas do nadejścia odpowiedzi"]

Rys. 1: Wynik testu prędkości wyraża ilość, którą można przenieść, a nie czas do nadejścia odpowiedzi.

Czas w obie strony (RTT) to czas, w którym komunikat dociera do drugiej strony i wraca. Różnica między zwiększeniem szybkości transferu a skróceniem czasu w obie strony przypomina różnicę między dobudowaniem pasów ruchu na drodze a skróceniem odległości do celu. Nawet jeśli wzrośnie zdolność przenoszenia dużej liczby plików, przy niezmienionym czasie w obie strony oczekiwanie na odpowiedź na czynność pozostaje. Zob. RTT i opóźnienie wyświetlania obrazu.

flowchart TB
    accTitle: Szybkość transferu i czas w obie strony porównane do drogi
    accDescr: Diagram porównuje zwiększenie szybkości transferu do dobudowania pasów ruchu, a skrócenie czasu w obie strony do skrócenia odległości do celu.
    A["Większa szybkość transferu"] -->|"na drodze"| B["Więcej pasów ruchu"]
    B ~~~ C["Krótszy czas w obie strony"]
    C -->|"na drodze"| D["Krótsza odległość"]

Rys. 2: Dodatkowe pasy ruchu nie skracają odległości do celu.

Zanim wróci wynik jednego znaku

Wyobraźmy sobie wpisanie jednego znaku w zdalnym Notatniku. Notatnik działa na komputerze zdalnym. Jeśli na potrzeby wyjaśnienia przyjmiemy, że dotarcie czynności trwa 50 milisekund, a powrót informacji o obrazie z wynikiem kolejne 50 milisekund, komunikacja zajmuje łącznie 100 milisekund, czyli 0,1 sekundy. Czas przetwarzania po obu stronach pomijamy w tym przykładzie.

flowchart TB
    accTitle: Przykład czasu komunikacji do powrotu wyniku jednego znaku
    accDescr: Przykład, w którym na potrzeby wyjaśnienia przyjęto po 50 milisekund w każdą stronę. Nie obejmuje czasu przetwarzania po obu stronach i nie przedstawia liczby pakietów na klawisz.
    A["Wpisanie znaku lokalnie"] -->|"tam: 50 ms"| B["Host odbiera wejście"]
    B --> C["Wysłanie obrazu z wpisanym znakiem"]
    C -->|"z powrotem: 50 ms"| D["Wynik dociera lokalnie"]

Rys. 3: Jeśli przyjąć 50 ms tam i 50 ms z powrotem, sama komunikacja zajmuje 0,1 sekundy. Nie są to wartości zmierzone.

Nawet gdy łącze może przenieść więcej danych, te 0,1 sekundy pozostają, jeśli czas w obie strony się nie zmienia. Rysunek 3 to diagram koncepcyjny, który ma pomóc zrozumieć przetwarzanie. Nie oznacza, że dla każdego klawisza wysyłana jest osobna wymiana pakietów tam i z powrotem. Ścieżka do serwera testu prędkości i do komputera zdalnego RDP także jest inna; trzeba uwzględnić VPN, bramę, łącze wysyłające po stronie komputera zdalnego i przeciążenia po drodze. Zob. podejście do RTT, wydajność sieci i hosta.

Tworzenie i dostarczanie obrazu ekranu

Opóźnienie reakcji na czynność oznacza tu oczekiwanie od wykonania czynności lokalnie do zobaczenia wyniku. Udział ma w nim nie tylko RTT, lecz także przetwarzanie w aplikacji oraz tworzenie i dostarczanie obrazu ekranu. Odróżniamy je też od opóźnienia samego odcinka transferu obrazu. Zob. odcinek pomiaru od przechwycenia obrazu do wyświetlenia.

Gdy dane wejściowe dotrą z komputera lokalnego do zdalnego, aplikacja na komputerze zdalnym je przetwarza i aktualizuje ekran, zakodowane informacje o obrazie są przenoszone łączem, a komputer lokalny je dekoduje i wyświetla. Także przed komunikacją i po niej są zadania, które wykonują różne komputery. Zob. przetwarzanie od przechwycenia obrazu do wyświetlenia.

flowchart TB
    accTitle: Przed łączem i za nim też jest przetwarzanie obrazu
    accDescr: Przebieg od dotarcia wejścia z komputera lokalnego do zdalnego, przez przetworzenie w aplikacji, utworzenie i kompresję obrazu, przeniesienie informacji o obrazie łączem, aż po przywrócenie ich lokalnie do postaci do wyświetlenia i wyświetlenie.
    I["Lokalnie: wpisanie czynności"] --> J["Łącze: przenosi wejście"]
    J --> K["Zdalnie: przetwarza aplikacja"]
    K --> A["Zdalnie: obraz i kompresja"]
    A --> B["Łącze: przenosi obraz"]
    B --> C["Lokalnie: postać do wyświetlenia"]
    C --> D["Wyświetlenie na ekranie lokalnym"]

Rys. 4: Przetwarzanie i kompresja na komputerze zdalnym, przeniesienie łączem i przywrócenie do wyświetlenia lokalnie. Każde z tych zadań wykonuje się w innym miejscu.

Kodowanie oznacza w tym artykule przetwarzanie, które na komputerze zdalnym przekształca i kompresuje obraz do postaci łatwej do wysłania. Niezależnie od transferu łączem zajmuje ono czas przetwarzania na komputerze zdalnym. Zob. czas kodowania na komputerze zdalnym.

Dekodowanie oznacza w tym artykule przetwarzanie, które przywraca otrzymane informacje o obrazie do postaci możliwej do wyświetlenia na komputerze lokalnym. Odróżniamy je od odszyfrowywania w sensie zdejmowania szyfrowania. Zob. dekodowanie i czas wyświetlania na komputerze lokalnym.

Jeśli kompresja na komputerze zdalnym trwa długo, czeka się na przygotowanie wysyłki, nawet gdy łącze jest wolne. Nawet gdy informacje już dotarły, aktualizacja się opóźnia, jeśli lokalne dekodowanie lub wyświetlanie nie nadąża. Nie zawsze jest tak, że „komputer firmowy jest wydajny, więc sprzęt lokalny może być dowolny”. Zapas przepustowości łącza i zapas mocy przetwarzania na obu jego końcach to dwie różne rzeczy. Zob. liczniki wydajności przetwarzania obrazu.

flowchart TB
    accTitle: Opóźnienie, gdy przetwarzanie po obu stronach nie nadąża
    accDescr: Pokazuje, że gdy kompresja na komputerze zdalnym trwa długo, czeka się na przygotowanie wysyłki mimo wolnego łącza, a gdy lokalne dekodowanie lub wyświetlanie nie nadąża, aktualizacja się opóźnia mimo dotarcia informacji.
    A["Kompresja zdalnie trwa długo"] --> B["Wysyłka czeka mimo wolnego łącza"]
    B ~~~ C["Lokalne dekodowanie nie nadąża"]
    C --> D["Dotarło, a aktualizacja się opóźnia"]

Rys. 5: Nawet przy zapasie przepustowości łącza aktualizacja obrazu się opóźnia, jeśli przetwarzanie po obu stronach nie nadąża.

Wpisywanie tekstu a przewijanie

Gdy dopisujesz jeden znak w Notatniku, zmienia się mały fragment ekranu. Przy przewijaniu strony z wieloma zdjęciami raz za razem zmienia się obraz na dużym obszarze. RDP ogranicza ilość przesyłanych danych, przesyłając zmienione fragmenty oraz stosując kompresję i pamięć podręczną dopasowane do treści. Nie wysyła za każdym razem całego ekranu bez kompresji. Ilość pracy zależy od treści ekranu i częstotliwości aktualizacji. Zob. zależność między treścią ekranu a przepustowością.

flowchart TB
    accTitle: Ilość pracy z obrazem przy wpisywaniu i przewijaniu
    accDescr: Mała zmiana pojedynczego znaku i ciągłe aktualizacje dużego obszaru różnią się charakterem pracy przy tworzeniu i wysyłaniu obrazu.
    A{"Zmiana ekranu"} -->|"dodanie znaku"| B["Mały obszar"]
    A -->|"przewijanie"| D["Duży obszar, bez przerwy"]
    B --> E["Kompresja i transfer wg zmian"]
    D --> E

Rys. 6: Nawet przy tym samym połączeniu ilość pracy jest inna przy dodaniu jednego znaku i przy ciągłym ruchu na dużym obszarze.

Nawet jeśli nieruchomy dokument nie stanowi obciążenia, podczas przewijania transferowi obrazu może zabraknąć zapasu. Zwiększenie rozdzielczości lub liczby monitorów po stronie zdalnej powiększa też ekran, który trzeba przetworzyć. Porównanie z obniżoną rozdzielczością to eksperyment sprawdzający, czy płynność wraca, gdy zmniejszy się pracę związaną z tworzeniem i wysyłaniem obrazu. Nie jest to obliczenie, które wyznacza ilość przesyłanych danych z samej liczby pikseli. Zob. wpływ rozdzielczości, aktualizacji ekranu i kompresji.

Oczekiwanie w aplikacji

Jeśli tylko wyszukiwanie w aplikacji biznesowej zatrzymuje się na kilka sekund, a w Notatniku w tej samej sesji można normalnie pisać, sprawdź, na co czeka ta aplikacja. Aplikacja na komputerze zdalnym może z kolei zlecać wyszukiwanie innej bazie danych lub czytać pliki z folderu udostępnionego i czekać na odpowiedź. To ścieżka odrębna od komunikacji RDP łączącej komputer lokalny ze zdalnym. Zob. komunikacja z komputera zdalnego do backendu.

flowchart TB
    accTitle: Za RDP też są partnerzy komunikacji
    accDescr: Pokazuje sytuację, w której niezależnie od komunikacji między urządzeniem lokalnym a komputerem zdalnym aplikacja na komputerze zdalnym czeka na odpowiedź serwera biznesowego.
    A["Urządzenie lokalne"] -->|"RDP"| B["Aplikacja biznesowa na hoście"]
    B -->|"wyszukiwanie, żądanie pliku"| C["Baza danych, folder udostępniony"]
    C -->|"oczekiwana odpowiedź"| B

Rys. 7: Aplikacja biznesowa za RDP może z kolei czekać na odpowiedź innego serwera.

Gdy przetwarzanie odpowiedzialne za ekran i wejście ma do wykonania długą pracę, kolejne dane wejściowe i aktualizacje ekranu się opóźniają. Na przykład w WPF długotrwałe zajęcie wątku UI pogarsza responsywność. Samo niskie użycie całego CPU nie wyklucza oczekiwania konkretnego wątku UI. Zob. Dispatcher i wątek UI.

flowchart TB
    accTitle: Zator w przetwarzaniu odpowiedzialnym za ekran i wejście
    accDescr: Pokazuje, że gdy przetwarzanie odpowiedzialne za ekran i wejście ma długą pracę, kolejne wejście i aktualizacje ekranu się opóźniają, a samo niskie użycie całego CPU tego oczekiwania nie wyklucza.
    A["Przetwarzanie ekranu i wejścia"] --> B["Ma długą pracę"]
    B --> C["Kolejne wejście i ekran się opóźniają"]
    C -.- D["Niskie CPU tego nie wyklucza"]

Rys. 8: Oczekiwania wątku UI nie wyklucza samo użycie całego CPU.

Pierwsze porównanie według objawów

Ilość, którą można przenieść, czas oczekiwania na odpowiedź i czas tworzenia oraz wyświetlania obrazu to różne rzeczy. Jeśli zachowasz to rozróżnienie, nie sprowadzisz stwierdzenia „RDP działa wolno” do jednej przyczyny, tylko zaczniesz od czynności, która jest wolna teraz.

flowchart TB
    accTitle: Najpierw rozdziel trzy rzeczy, potem badaj
    accDescr: Pokazuje, że zamiast sprowadzać „RDP działa wolno” do jednej przyczyny, rozdziela się ilość możliwą do przeniesienia, czas oczekiwania na odpowiedź i czas tworzenia i wyświetlania obrazu, a badanie zaczyna od czynności, która jest wolna teraz.
    A["„RDP działa wolno”"] --> S
    subgraph S["Osobno"]
    direction TB
    B["Ilość do przeniesienia"] ~~~ C["Czas oczekiwania na odpowiedź"]
    C ~~~ D["Czas tworzenia i wyświetlania obrazu"]
    end
    S --> E["Badanie od czynności wolnej teraz"]

Rys. 9: Rozdzielenie ilości do przeniesienia, czasu oczekiwania na odpowiedź i czasu tworzenia i wyświetlania obrazu pozwala zacząć od czynności, która jest wolna teraz.

Celem diagnozy jest ograniczenie miejsca, w którym szuka się przyczyny spowolnienia. Celem nie jest przypadkowe przyspieszenie przez zbiorczą zmianę ustawień. Wykorzystując różnice typu „Notatnik działa, a zatrzymuje się tylko wyszukiwanie” czy „wpisywanie jest normalne, a wolne jest tylko przewijanie”, można wybrać punkt wyjścia diagnozy jeszcze przed zmianą ustawień komunikacji.

Poniższa tabela to punkt wyjścia diagnozy. Nie służy do rozstrzygania o przyczynie. Najpierw porównaj czynności w tej samej sesji, a dopiero potem zmieniaj w razie potrzeby urządzenie, ścieżkę lub warunki wyświetlania.

Opóźnione znaki w wielu aplikacjach

Jeśli w wielu aplikacjach tej samej sesji każdy znak pojawia się z opóźnieniem, porównaj tę samą czynność także z innego urządzenia lub inną dozwoloną ścieżką. Zestaw czas w obie strony, oczekiwanie na wejście na komputerze zdalnym i obciążenie całego komputera zdalnego; nie ustalaj przyczyny na podstawie jednej liczby.

Zacina się tylko przewijanie

Nawet jeśli wpisywanie jest normalne, przewijanie strony z wieloma zdjęciami wywołuje ciągłe aktualizacje ekranu na dużym obszarze. Zmieniaj pojedynczo rozdzielczość lub liczbę monitorów po stronie zdalnej i porównuj na tej samej stronie. Jeśli nastąpi poprawa, kolejnym przedmiotem diagnozy są kompresja na komputerze zdalnym, transfer obrazu i lokalne dekodowanie. Sama rozdzielczość nie powie, który z tych trzech elementów jest przyczyną. Zob. obciążenie zależne od treści ekranu i rozdzielczości.

Zawiesza się tylko jedna aplikacja

Jeśli zatrzymuje się tylko aplikacja biznesowa, w której kliknięto wyszukiwanie, sprawdź, czy Notatnik lub inna aplikacja w tej samej sesji reaguje. Jeśli inne aplikacje działają, najpierw zbadaj przetwarzanie w danej aplikacji, dysk oraz żądania do bazy danych i folderu udostępnionego. To, że pracujesz przez RDP, i to, że komunikacja RDP jest przyczyną oczekiwania, to dwie różne rzeczy. Zob. czynniki wydajności aplikacji i backendu.

Wolno u wszystkich, gdy przybywa użytkowników

Jeśli w tych samych godzinach spowolnienie dotyka wielu użytkowników, zapytaj administratora o stan innych sesji. Obciążenie CPU, pamięci i magazynu danych współdzielonego hosta oraz współdzielonego łącza zestawia się z godziną wystąpienia objawu. Nie uzyskuj bez zgody dostępu do danych ani procesów innych użytkowników i nie zatrzymuj ich zadań. Zob. zasoby współdzielonego hosta a liczba użytkowników.

Spowolnienie podczas kopiowania lub drukowania

Jeśli problemy zbiegają się w czasie z rozpoczęciem własnego kopiowania lub drukowania, wstrzymaj tylko te transfery, których zatrzymanie jest dozwolone, i porównaj. Zapisz, czy po zatrzymaniu działanie wraca do normy i czy po wznowieniu znowu zwalnia, a następnie zbadaj konkurencję z transferami innymi niż obraz i z przekierowaniem urządzeń. Nie wykonuje się porównań polegających na zbiorczym wyłączeniu urządzeń potrzebnych do pracy. Zob. wpływ przekierowania urządzeń.

Porównywanie warunków pojedynczo

Nie trzeba po kolei zmieniać wszystkich ustawień. Najpierw ustal punkt odniesienia do porównań, a potem wybierz tylko te sprawdzenia, które pasują do objawów. Przed zmianą ustawień i ponownym połączeniem zapisz swoją pracę oraz zanotuj pierwotne wartości i sposób ich przywrócenia. Jeśli brakuje potrzebnych uprawnień lub funkcji, nie włączaj ich na siłę, tylko przekaż sprawę administratorowi.

Praca bezpośrednio przy komputerze i praca przez RDP nie zawsze odbywają się w tych samych warunkach. To, że na fizycznym ekranie komputera zdalnego wszystko działa szybko, jest pomocną wskazówką, ale sesja i warunki rysowania mogą się różnić. Zadbaj o tego samego użytkownika, te same dane i ten sam stan aplikacji i nie ograniczaj przyczyny do łącza tylko dlatego, że „na fizycznym ekranie działa szybko”.

Porównanie tej samej czynności

Przygotuj tego samego użytkownika, te same dane i tę samą czynność. Na współdzielonym hoście sprawdź własną sesję i nie zatrzymuj aplikacji ani procesów innych użytkowników. Korzystanie z innego urządzenia lub innej ścieżki również ogranicza się do zakresu dozwolonego przez administratora.

1. Odtwórz wolną czynność przy pierwotnych ustawieniach i zapisz godzinę oraz objaw.

   W Notatniku w tej samej sesji zdalnej co problematyczna aplikacja wpisz podobną ilość tekstu. Rozróżnij, czy dotyczy to jednej aplikacji, czy całej sesji.

2. Sprawdź obciążenie komputera zdalnego i lokalnego w tym samym czasie.

   W Menedżerze zadań na komputerze zdalnym obserwuj CPU, pamięć i dysk danej aplikacji, a na komputerze lokalnym obciążenie klienta RDP. Sprawdzaj nie tylko wartość dla całego CPU, ale też konkretny proces. Zob. co sprawdzać pod kątem obciążenia.

3. Zmień tylko jeden warunek spośród: inne urządzenie, inna dozwolona ścieżka, warunki wyświetlania, i powtórz tę samą czynność.

   Jeśli przy porównaniu jednocześnie zmienia się też stan komputera zdalnego lub aplikacji, zapisz również tę różnicę. Wyniku zmiany kilku warunków nie traktuje się jako efektu jednego warunku.

4. Przywróć pierwotne warunki i ponownie sprawdź tę samą czynność.

   Jeśli po przywróceniu nadal działa szybko, możliwa jest też np. przejściowa zmiana obciążenia. Nie zakładaj z góry, że zmiana pomogła, tylko zapisz warunki, w których objaw się odtwarza.

Masz wtedy komplet wyników dla stanu pierwotnego, stanu po zmianie i stanu po przywróceniu i możesz porównać, które warunki odpowiadają objawom. Warunek, przy którym nastąpiła poprawa, to wskazówka dla diagnozy, a sam w sobie nie dowodzi przyczyny źródłowej.

flowchart TB
    accTitle: Ograniczenie warunków zmienianych naraz
    accDescr: Przebieg, w którym ustala się czynność odtwarzaną w stanie pierwotnym, zmienia tylko jeden warunek, porównuje i sprawdza też wynik po przywróceniu.
    A["Ta sama czynność, ustawienia pierwotne"] --> B["Zmiana jednego warunku"]
    B --> C["Powtórzenie tej samej czynności"]
    C --> D["Przywrócenie i ponowne sprawdzenie"]
    D --> E["Zapis warunku z poprawą"]

Rys. 10: Tę samą czynność powtarza się w stanie pierwotnym, po zmianie i po przywróceniu, i zapisuje się warunek, przy którym nastąpiła zmiana.

Porównanie rozdzielczości po stronie zdalnej

To porównanie wykonuje się, gdy aktualizacje ekranu, np. przy przewijaniu, są ciężkie. Zanotuj rozdzielczość i liczbę monitorów sprzed zmiany, zapisz swoją pracę i połącz się ponownie. Ustawień, które pogarszają potrzebny do pracy obraz lub czytelność tekstu, nie zostawia się na stałe.

1. Zmień tylko jedno: liczbę monitorów albo rozdzielczość.

   W mstsc można porównywać za pomocą ustawień na karcie „Ekran” przed połączeniem albo przez podanie szerokości i wysokości. Zob. ustawienia ekranu w mstsc.

2. Upewnij się, że rzeczywisty rozmiar pulpitu komputera zdalnego się zmienił, i przewiń tę samą stronę.

   Samo zmniejszenie okna lokalnego może oznaczać jedynie pomniejszone wyświetlanie dużego pulpitu. Odróżnij rozdzielczość dynamiczną od smart sizing i sprawdź warunki obsługi w używanym kliencie. Zob. rozdzielczość pulpitu i skalowanie wyświetlania.

3. Przywróć pierwotne ustawienia, powtórz tę samą czynność i porównaj obciążenie po obu stronach oraz płynność obrazu.

   Jeśli jednocześnie obniżono rozdzielczość i przełączono się na jeden monitor, porównanie jest tylko orientacyjne. Jeśli nastąpiła poprawa, przywracaj ustawienia pojedynczo, aby rozdzielić ich wpływ.

Jeśli nastąpiła poprawa, wskazówka leży w obszarze przetwarzania i transferu obrazu. 3840×2160 to czterokrotnie więcej pikseli niż 1920×1080, ale ilość przesyłanych danych nie zawsze rośnie czterokrotnie. Zależy ona od zmienionych fragmentów i kompresji, a zmiana rozdzielczości wpływa też na przetwarzanie po obu stronach. Zob. zależność między liczbą pikseli a ilością danych, sprawdzanie przetwarzania obrazu.

flowchart TB
    accTitle: Co pokazuje porównanie z obniżoną rozdzielczością
    accDescr: Obniżenie rozdzielczości po stronie zdalnej może zmienić obciążenie zarówno przetwarzania obrazu, jak i transferu, więc sama poprawa nie pozwala ograniczyć przyczyny do łącza.
    A["Niższa rozdzielczość zdalna"] --> S
    subgraph S["Co się zmienia"]
    direction TB
    B["Przetwarzanie obrazu na hoście"] ~~~ C["Ilość wysyłanych danych"]
    C ~~~ D["Lokalne wyświetlanie"]
    end

Rys. 11: Zmiana rozdzielczości to porównanie, które wpływa nie tylko na łącze, lecz także na przetwarzanie obrazu na komputerze zdalnym i lokalnym.

Zestawienie kopiowania i drukowania z objawami

Wstrzymuje się tylko te procesy, których zatrzymanie jest dozwolone, np. transfery rozpoczęte przez siebie. Nie zatrzymuje się firmowych kopii zapasowych, procesów bezpieczeństwa ani zadań innych użytkowników. Nie wyłącza się zbiorczo przekierowania urządzeń audio i wejściowych potrzebnych do pracy.

1. Przed rozpoczęciem kopiowania, synchronizacji z chmurą lub drukowania oraz w ich trakcie zapisz tę samą czynność i obciążenie.

   Przez RDP poza obrazem przepływają też m.in. dane dysków i drukarek. Przekierowanie, które pozwala używać urządzeń lokalnych na komputerze zdalnym, może podczas korzystania z nich zwiększać obciążenie komunikacji i przetwarzania. Zob. wpływ przekierowania urządzeń.

2. Wstrzymaj dany transfer w dozwolonym zakresie i ponownie sprawdź tę samą czynność.

   Jeśli można wznowić transfer i porównać, zapisz także objawy po wznowieniu. Również przy próbach z niepotrzebnym przekierowaniem urządzeń zmieniaj je pojedynczo i zachowaj możliwość przywrócenia pierwotnych ustawień.

Można wtedy ocenić, czy rozpoczęcie transferu odpowiada problemom, a wstrzymanie powrotowi do normy. Jeśli widać taki związek, zestaw transfery inne niż obraz i obciążenie współdzielonych zasobów z zapisami administratora.

flowchart TB
    accTitle: Problemy przed i po na tej samej osi czasu
    accDescr: Zapisuje się tę samą czynność i obciążenie przed transferem, w jego trakcie i po zatrzymaniu, a następnie porównuje związek między problemami a pracą.
    A["Czynność i obciążenie przed transferem"] --> B["Czynność i obciążenie w trakcie"]
    B --> C["Czynność i obciążenie po zatrzymaniu"]
    C --> D["Czy problem i powrót się pokrywają"]

Rys. 12: Sprawdza się, jak przed transferem, w jego trakcie i po zatrzymaniu zmieniają się powolność tej samej czynności i obciążenie.

Pomiar miejsca oczekiwania

Z komputera lokalnego bada się przesył w obie strony i połączenie TCP, a na komputerze zdalnym oczekiwanie w kolejce wejściowej i aktualizacje ekranu. Każda z tych liczb mierzy ograniczony odcinek, dlatego wyniki odczytuje się w zestawieniu z tabelą w sekcji „Zakres wyników pomiarów”.

Sprawdzenie ICMP i połączenia TCP

Polecenia uruchamia się na lokalnym urządzeniu z Windows. Dotyczy to wyłącznie konfiguracji, w której przez firmową sieć LAN lub dozwolony VPN łączysz się bezpośrednio z hostem RDP używającym standardowego portu TCP 3389. W konfiguracjach przez RD Gateway lub Azure Virtual Desktop albo z niestandardowym portem ustal z administratorem, co sprawdzać. Nie otwiera się portów ani nie zmienia ustawień zapory.

1. Podaj dozwolony komputer docelowy i zapisz wyniki odpowiedzi ICMP oraz połączenia TCP.

   $target = Read-Host 'Nazwa lub adres IP hosta RDP, którego badanie jest dozwolone'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Podaj komputer docelowy.'
   }
       
   # Sprawdź czas odpowiedzi ICMP kilka razy. Sam brak odpowiedzi nie oznacza niedostępności RDP.
   ping.exe -n 20 $target
       
   # Sprawdzenie tylko dla konfiguracji z bezpośrednim połączeniem na standardowy port TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Zestaw wyniki z okresu spowolnienia i z normalnego działania z godziną wystąpienia objawu i rzeczywistą ścieżką połączenia.

   20 zapytań ping to krótka obserwacja. Zapisz wahania wartości i brak odpowiedzi, pamiętając, że ICMP może być blokowane. Nie wykluczaj przerywanych zatrzymań na podstawie samej średniej, tylko korzystaj z informacji o połączeniu i zapisów komunikacji prowadzonych przez administratora. Zob. co mierzy ping.

TcpTestSucceeded: True oznacza, że połączenie TCP z podanym portem się powiodło. Nie mierzy to przepustowości, UDP, działania po uwierzytelnieniu ani płynności obrazu. Test-NetConnection nie ma przełącznika -UDP do sprawdzania UDP. Zob. składnia i wyniki Test-NetConnection.

Oceniając wyniki, pamiętaj o różnicach w ścieżkach i usługach. Przy RD Gateway i podobnych ścieżka ICMP lub bezpośredniego połączenia TCP z hostem może nie pokrywać się z rzeczywistą ścieżką RDP. W Azure Virtual Desktop można korzystać z RTT i szacowanej przepustowości dla każdego połączenia, ale ta funkcja diagnostyczna jest przeznaczona dla tej usługi. Krótkich zatrzymań nie wyklucza się na podstawie samej średniej. Zob. dzienniki jakości połączenia Azure Virtual Desktop.

flowchart TB
    accTitle: Sprawdzona ścieżka a rzeczywista ścieżka RDP
    accDescr: W konfiguracjach z RD Gateway i podobnymi ścieżka ICMP lub bezpośredniego połączenia TCP z urządzenia lokalnego do hosta może nie pokrywać się z rzeczywistą ścieżką RDP.
    A["Urządzenie lokalne"] -->|"ICMP, bezpośrednie TCP"| C["Host RDP"]
    A -->|"rzeczywiste RDP"| B["RD Gateway itp."]
    B --> C

Rys. 13: ICMP i bezpośrednie połączenie TCP z hostem mogą przebiegać inną ścieżką niż rzeczywiste RDP.

Pomiar oczekiwania w kolejce wejściowej

User Input Delay mierzy oczekiwanie od trafienia danych wejściowych do kolejki na komputerze zdalnym do ich pobrania przez proces. Nie jest to całkowity czas od naciśnięcia klawisza do zobaczenia znaku. Zob. definicja User Input Delay.

Pomiar wykonuje się w sesji zdalnej na komputerze zdalnym. Według Microsoftu wymagany jest Windows 10 w wersji 1809 lub nowszej albo Windows Server 2019 lub nowszy. W tych systemach nie trzeba dodawać wpisu rejestru, aby włączyć licznik. Sprawdź nazwę wyświetlaną, uprawnienia i dostępność licznika, a jeśli nie da się z niego skorzystać, zapisz ten fakt i skonsultuj się z administratorem. Zob. wymagania i ustawienia.

1. W PowerShell w tej samej sesji zanotuj godzinę i identyfikator sesji.

   Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
   (Get-Process -Id $PID).SessionId
   query.exe session
       
   

   Do sprawdzania sesji innych użytkowników mogą być potrzebne dodatkowe uprawnienia. Standardowa nazwa wystąpienia dla badanego procesu to SessionID:ProcessID <Process Image>. Uważaj, aby na podstawie samego identyfikatora sesji nie mieszać wartości innych użytkowników ani procesów o tej samej nazwie. Zob. uprawnienia query session, identyfikacja wystąpień.

2. W perfmon.exe dodaj dostępny licznik User Input Delay per Process lub User Input Delay per Session.

   Wybierz badany proces lub sesję i na początek obserwuj z domyślnym interwałem 1 sekundy. Odróżniaj wystąpienie zbiorcze, które łączy wiele sesji, od wartości poszczególnych sesji.

3. Odtwórz czynność z opóźnionym wejściem i porównaj oczekiwanie w kolejce z godziną wystąpienia objawu.

   Dla pojedynczego mierzonego obiektu licznik pokazuje największy czas oczekiwania w interwale pomiaru. Nawet przy niskiej wartości pozostają przetwarzanie po pobraniu danych wejściowych przez aplikację i opóźnienie do powrotu wyniku na komputer lokalny.

Pozwala to sprawdzić, czy dane wejściowe czekają w kolejce na komputerze zdalnym. Jest to inny wskaźnik niż odczuwalny czas obejmujący przesył w obie strony i wyświetlanie na komputerze lokalnym. Zob. znaczenie maksimum i interwału pomiaru.

flowchart TB
    accTitle: Odcinek mierzony przez User Input Delay
    accDescr: Mierzony odcinek trwa od kolejki wejściowej na komputerze zdalnym do pobrania danych przez aplikację; nie obejmuje komunikacji ani wyświetlania obrazu przed nim i po nim.
    A["Wejście dociera z komputera lokalnego"] --> B["Trafia do kolejki na hoście"]
    B -->|"to jest mierzone"| C["Aplikacja pobiera wejście"]
    C --> D["Przetwarzanie i transfer obrazu"]
    D --> E["Wyświetlenie lokalnie"]

Rys. 14: Mierzy się oczekiwanie w kolejce wejściowej na komputerze zdalnym. To coś innego niż całkowity czas do zobaczenia wyniku lokalnie.

Badanie aktualizacji ekranu i przyczyn pomijania klatek

Przygotuj czynność z ciągłymi aktualizacjami ekranu, np. przewijanie. Dostępność liczników RemoteFX Graphics i miejsce pomiaru trzeba sprawdzić, bo zależą od systemu operacyjnego, konfiguracji hosta i uprawnień. Tutaj tylko odczytujemy dostępne liczniki. Nie jest to procedura instalowania ani włączania starej funkcji RemoteFX. Zob. warunki stosowania liczników Graphics.

1. Za pomocą query session lub qwinsta sprawdź nazwę badanej sesji i wybierz odpowiadające jej wystąpienie licznika.

2. Podczas czynności z aktualizacjami ekranu porównaj Input Frames/Second i Output Frames/Second.

   Jeśli klatek wyjściowych jest mniej niż wejściowych, część klatek jest po drodze pomijana. Sprawdź wartości Frames Skipped/Second z podziałem na brak zasobów komputera zdalnego, sieci i klienta.

3. Zestaw przyczyny pomijania klatek z obciążeniem obu stron i komunikacji oraz sprawdź też Average Encoding Time.

   Jeśli czas kodowania jest długi, zbadaj kompresję na komputerze zdalnym. Jeśli klatek jest mało już po stronie wejściowej, możliwe też, że aplikacja nie aktualizuje ekranu często. Niska liczba klatek przy nieruchomym obrazie sama w sobie nie jest nieprawidłowością.

Na podstawie klatek wejściowych i wyjściowych podczas aktualizacji ekranu, przyczyn pomijania klatek i czasu kodowania można zawęzić obszar diagnozy. Podział w licznikach to wskazówka; ocenia się go razem z rzeczywistym obciążeniem i konfiguracją połączenia. Zob. jak odczytywać liczbę klatek i czas kodowania.

flowchart TB
    accTitle: Zawężanie diagnozy na podstawie pomijania klatek
    accDescr: Podczas czynności z aktualizacjami ekranu porównuje się liczbę klatek wejściowych i wyjściowych, a liczniki przyczyn pomijania klatek służą jako wskazówka do zestawienia z obciążeniem przetwarzania, komunikacji i wyświetlania.
    A["Wejście i wyjście przy przewijaniu"] --> B["Mniej wyjścia: sprawdź pomijanie"]
    B --> C["Liczniki według przyczyn"]
    C --> D["Obciążenie: host, sieć, lokalnie"]

Rys. 15: Porównuje się wejście i wyjście podczas przewijania, a przyczyny pomijania klatek zestawia z obciążeniem komputera zdalnego, łącza i komputera lokalnego.

Diagramów koncepcyjnych transferu obrazu ani starszej dokumentacji nie uogólnia się na wszystkie konfiguracje. Istnieją konfiguracje, w których wideo i dźwięk są przesyłane innym mechanizmem. Dokumentacja liczników Graphics opisuje też starsze konfiguracje, dlatego podanych tam liczb nie należy odczytywać jako wspólnej specyfikacji typu „każde RDP ma maksymalnie 30 fps”. Przed użyciem sprawdź, do czego odnoszą się dane funkcje i liczby. Zob. transfer obrazu a rodzaj obciążenia, dokumentacja liczników Graphics.

Zakres wyników pomiarów

Niska wartość liczbowa to nie to samo co komfortowa praca. Zakres każdego wskaźnika można sprawdzić w dokumentacji Microsoftu wskazanej w procedurach.

Ustawienia sieci i GPU

Ustawienia UDP i GPU dobiera się do tego, co wykazały porównania i pomiary. Gdy podejrzana jest komunikacja, najpierw sprawdź sposób połączenia i ścieżkę, a gdy podejrzane jest przetwarzanie obrazu, najpierw sprawdź etap, na którym używany jest GPU.

Sprawdzenie TCP/UDP i ścieżki połączenia

Gdy porównania i pomiary wskazują na komunikację, sprawdź z administratorem używany klient, ścieżkę i zastosowane zasady. Nawet jeśli zmiana ustawień jest konieczna, ogranicz ją do zatwierdzonego zakresu i zapisz wartości sprzed zmiany oraz sposób przywrócenia. Nie wyłącza się zapory ani uwierzytelniania i nie wystawia się portu RDP bezpośrednio do internetu.

1. Na podstawie informacji o połączeniu, dzienników diagnostycznych produktu i zapisów komunikacji administratora sprawdź, czy faktycznie używane jest TCP, czy UDP, oraz jaka jest ścieżka.

   RDP używa TCP lub UDP w zależności od konfiguracji i warunków komunikacji. W zasadzie „Select RDP transport protocols” można wybrać ustawienie korzystające z UDP lub TCP albo ustawienie tylko z TCP. Ponieważ możliwe jest też użycie TCP, gdy połączenie UDP nie dojdzie do skutku, samo udane połączenie nie mówi, który sposób jest używany. Zob. wybór transportu RDP i powrót awaryjny.

2. Zestaw godzinę wystąpienia objawu ze ścieżką i sposobem połączenia, a następnie porównuj pojedynczo tylko potrzebne ustawienia.

   Nie zmienia się ustawień schematycznie w przekonaniu, że „wyłączenie UDP przyspieszy działanie”. Porównuj przy ujednoliconych warunkach VPN i bramy, czynności i warunkach wyświetlania, a zbędne zmiany wycofuj.

Znając sposób połączenia i ścieżkę, można zapisać związek między zmianą a objawem. Ograniczenie do TCP nie zawsze przyspiesza działanie.

flowchart TB
    accTitle: Najpierw sprawdź sposób połączenia, potem porównuj ustawienia sieci
    accDescr: Odróżnia się zwykłe połączenie bezpośrednie od połączenia przez bramę lub usługę, sprawdza rzeczywistą ścieżkę i sposób połączenia, a dopiero potem wykonuje dozwolone porównania.
    A["Używany klient i konfiguracja"] --> B["Sprawdzenie ścieżki i TCP/UDP"]
    B --> C["Zestawienie z godziną objawu"]
    C --> D["Potrzebne ustawienia pojedynczo"]

Rys. 16: Sprawdź używany sposób połączenia i ścieżkę, zestaw je z objawami, a dopiero potem porównuj tylko potrzebne ustawienia.

RDP Shortpath to mechanizm Azure Virtual Desktop. Nawiązuje ścieżkę UDP tej usługi i zależnie od konfiguracji używa ścieżki bezpośredniej lub przekaźnika. Jeśli nie uda się jej nawiązać, wraca do połączenia opartego na TCP. Nie można go opisać tą samą tabelą ustawień co bezpośrednie połączenie przez mstsc z komputerem firmowym. Zob. ścieżki RDP Shortpath i powrót awaryjny.

flowchart TB
    accTitle: Ścieżki RDP Shortpath i powrót awaryjny
    accDescr: RDP Shortpath w Azure Virtual Desktop próbuje nawiązać ścieżkę UDP; jeśli się to uda, zależnie od konfiguracji używa ścieżki bezpośredniej lub przekaźnika, a jeśli nie, wraca do połączenia opartego na TCP.
    A["RDP Shortpath"] --> B{"Ścieżka UDP"}
    B -->|"nawiązana"| C["Bezpośrednio lub przez przekaźnik"]
    B -->|"nienawiązana"| D["Powrót do połączenia TCP"]

Rys. 17: Jeśli RDP Shortpath nie nawiąże ścieżki UDP, wraca do połączenia opartego na TCP.

Sprawdzenie użycia GPU w przetwarzaniu obrazu

Sprawdzenie wykonuje się, gdy porównania i pomiary wskazują na przetwarzanie obrazu. Sprawdź wyniki pomiarów przetwarzania obrazu oraz obsługiwane systemy operacyjne, sterowniki, zasady i klienty. Nie zmienia się ustawień tylko dlatego, że komputer ma GPU. Najpierw uzyskaj zgodę administratora i przygotuj możliwość przywrócenia ustawień.

1. Rozdziel rysowanie w aplikacji na komputerze zdalnym, kodowanie RDP i lokalne dekodowanie, a następnie wybierz podejrzany etap.

   Nawet jeśli GPU jest dostępny, nie każdy etap musi z niego korzystać. Również w dokumentacji konfiguracji Microsoftu dla Azure Virtual Desktop rysowanie w sesji zdalnej i sprzętowe kodowanie klatek konfiguruje się i weryfikuje osobno. Zob. konfiguracja i weryfikacja GPU dla rysowania i kodowania.

2. Zgodnie z procedurą dla danego produktu sprawdź rzeczywiste użycie i zmierz tę samą czynność przed potrzebną zmianą i po niej.

   Jeśli czas kompresji jest długi, zbadaj użycie GPU do kodowania. Zmiana ustawień kodowania w przypadku aplikacji czekającej w kolejce wejściowej trafia w niewłaściwe miejsce. Przy czytelności tekstu i płynności wideo inaczej dobiera się też jakość obrazu, ilość przesyłanych danych i obciążenie przetwarzaniem. Zob. różnice zależne od rodzaju obciążenia.

Można wtedy zapisać nie tylko to, czy GPU jest obecny, lecz także to, czy jest używany na problematycznym etapie i jak zmieniły się obciążenie i reakcja przy tej samej czynności. Zmiany, które nie przyniosły poprawy, wycofuje się po uzgodnieniu z administratorem.

flowchart TB
    accTitle: Sprawdzanie użycia GPU etap po etapie
    accDescr: Rozdziela się rysowanie w aplikacji na komputerze zdalnym, kodowanie RDP i lokalne dekodowanie, a ponieważ nawet przy obecnym GPU nie każdy etap musi z niego korzystać, sprawdza się użycie na podejrzanym etapie.
    A["Rysowanie w aplikacji na hoście"] --> B["Kodowanie RDP"]
    B --> C["Lokalne dekodowanie"]
    C -.- D["Użycie GPU na każdym etapie"]

Rys. 18: Nawet jeśli GPU jest dostępny, rysowanie, kodowanie i dekodowanie nie muszą wszystkie z niego korzystać.

Ponowna weryfikacja i przekazanie

Poprawę potwierdza się tym, że po zmianie tę samą czynność da się wykonać bez przeszkód, a ponadto zachowane są potrzebna jakość obrazu, urządzenia i funkcje biznesowe. Zestaw też wynik po przywróceniu pierwotnych warunków. Jeśli poprawa była tylko chwilowa, nie ustalaj przyczyny, tylko zapisz wyniki, uwzględniając godziny szczytu i równoległe przetwarzanie.

flowchart TB
    accTitle: Kolejność potwierdzania poprawy
    accDescr: Pokazuje, że po zmianie sprawdza się, czy tę samą czynność da się wykonać bez przeszkód i czy zachowane są potrzebna jakość obrazu, urządzenia i funkcje biznesowe, zestawia z wynikiem po przywróceniu pierwotnych warunków, a sama chwilowa poprawa nie przesądza o przyczynie.
    A["Ta sama czynność po zmianie"] --> B["Jakość obrazu, urządzenia, funkcje"]
    B --> C["Zestawienie z wynikiem po przywróceniu"]
    C -.- D["Chwilowa poprawa nie przesądza"]

Rys. 19: Oprócz wyniku tej samej czynności zestawia się potrzebne funkcje i wynik po przywróceniu.

Przekazanie nierozwiązanego problemu

Brak poprawy, brak odtworzenia problemu czy niedostępność licznika to również przydatne wyniki. Oddziel porównania, które udało się wykonać, od sprawdzeń, których nie dało się przeprowadzić, i przekaż sprawę administratorowi lub programiście za pomocą poniższej notatki. Z udostępnianych dzienników usuń informacje biznesowe niepotrzebne do diagnozy, takie jak nazwy użytkowników czy komputery docelowe.

Godzina wystąpienia objawu i strefa czasowa:
System komputera zdalnego, używany klient i jego wersja:
Bezpośrednio/VPN/RD Gateway/Azure Virtual Desktop itp.:
Wolna czynność i aplikacja, reakcja innych aplikacji w tej samej sesji:
Rozdzielczość i liczba monitorów po stronie zdalnej:
Równoczesne kopiowanie, drukowanie itp.:
Jedyny zmieniony warunek i wynik po przywróceniu:
Obciążenie i liczniki zaobserwowane zdalnie i lokalnie:

Dopisz też, czy udało się potwierdzić faktycznie używane TCP lub UDP, których elementów nie sprawdzono, np. z powodu braku uprawnień, oraz jakie ustawienia są dopuszczalne z punktu widzenia pracy. Zamiast przekazywać „łącze jest wolne”, lepiej napisać „w Notatniku pisze się normalnie, ale przewijanie zdjęć się zatrzymuje”; wtedy kolejna osoba może prowadzić diagnozę w tych samych warunkach.

Użytkownik zapisuje czynność, która odtwarza problem, i wyniki porównań, a administrator zestawia zapisy dotyczące ścieżki połączenia, współdzielonego hosta i sesji. Sam fakt, że oczekiwanie występuje w RDP, nie oznacza, że przetwarzanie, na które się czeka, też leży po stronie RDP. Zob. podział ról między hostem a backendem.

Programista aplikacji rejestruje osobno przyjęcie zdarzenia wejściowego, początek i koniec operacji na bazie danych i plikach oraz odzwierciedlenie zmian w UI. Rozważa też projekt, w którym ciężka praca nie zajmuje na długo wątku UI. Dziennik zakończenia przetwarzania na komputerze zdalnym nie rejestruje jednak zakończenia wyświetlania na komputerze lokalnym. Zob. rozdzielenie przetwarzania dla zachowania responsywności UI.

Powiązane artykuły

• Jak rozumieć izolację sesji w Windows
• Bezpieczna diagnoza 100% użycia dysku w Windows
• Dlaczego „pozostała 1 sekunda” nie chce się skończyć?

Źródła

Poniżej znajdują się źródła pierwotne z Microsoft Learn. Treść, do której się odwołujemy, sprawdzono 17 września 2026 r. Czytając je, odróżniaj warunki stosowania poszczególnych produktów i pamiętaj, że nie są to pomiary wykonane na potrzeby tego artykułu.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Rozróżnienie RTT i opóźnienia od przechwycenia obrazu na komputerze zdalnym do wyświetlenia na komputerze lokalnym. Sama funkcja diagnostyczna jest przeznaczona dla Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Zależność ilości przesyłanych danych od treści ekranu, rozdzielczości, aktualizacji klatek, kompresji i pamięci podręcznej.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Sposób sprawdzania klatek wejściowych i wyjściowych, przyczyn pomijania klatek i czasu kodowania. Dokument opisuje też starsze konfiguracje, dlatego nie uogólniamy podanych limitów liczbowych na każde RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Obciążenie współdzielonego hosta, komunikacja z komputera zdalnego do backendu i wpływ przekierowania urządzeń.
• Microsoft Learn, Threading model. Wątek UI i Dispatcher w WPF, rozdzielenie przetwarzania dla zachowania responsywności.
• Microsoft Learn, mstsc. Ustawianie szerokości i wysokości pulpitu zdalnego oraz wielu monitorów.
• Microsoft Learn, Supported RDP properties. Rozróżnienie rozdzielczości pulpitu, rozdzielczości dynamicznej i smart sizing. Należy sprawdzić obsługiwane klienty i warunki stosowania dla poszczególnych produktów.
• Microsoft Learn, ping. Sprawdzanie odpowiedzi za pomocą ICMP Echo i opcje polecenia.
• Microsoft Learn, Test-NetConnection. Sprawdzanie połączenia TCP i znaczenie danych wyjściowych.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Odcinek pomiaru User Input Delay, obsługiwane systemy, wystąpienia i znaczenie wartości maksymalnej.
• Microsoft Learn, query session. Informacje o sesjach i uprawnienia potrzebne do sprawdzania innych sesji.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Wybór TCP lub UDP używanego przez RDP i powrót awaryjny.
• Microsoft Learn, RDP Shortpath. Ścieżka UDP dla Azure Virtual Desktop i zachowanie, gdy nie można jej nawiązać.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Konfiguracja i weryfikacja GPU osobno dla rysowania i kodowania klatek.

Powiązane artykuły

Najnowsze artykuły oznaczone tymi samymi tagami. Pozwalają pogłębić wiedzę na pokrewne tematy.

Powiązane tematy

Strony tematyczne zbliżone do tego zagadnienia. Od artykułu mogą Państwo przejść do powiązanych usług i innych artykułów.

Usługi powiązane z tym tematem

Ten artykuł prowadzi do poniższych stron usług. Prosimy wybrać najbliższy punkt wyjścia.

Najczęściej zadawane pytania

Pytania, które najczęściej padają podczas konsultacji na temat tego artykułu.

Dlaczego wpisywanie w RDP jest powolne, skoro test prędkości pokazuje kilkaset Mb/s?

Szybkość przenoszenia dużych ilości danych i czas, po którym wraca reakcja na czynność, to dwie różne rzeczy. Udział mają w tym wysłanie danych wejściowych, przetwarzanie w aplikacji na komputerze zdalnym, kompresja obrazu, transfer i wyświetlenie na komputerze lokalnym. Ponadto ścieżka sieciowa do serwera testu prędkości jest inna niż do komputera zdalnego RDP.

Tekst wpisuje się normalnie, a zacina się tylko przewijanie. Czy to problem łącza?

Nie da się zawęzić przyczyny do samego łącza. Gdy przybywa aktualizacji ekranu, może nie nadążać rysowanie i kompresja na komputerze zdalnym, komunikacja albo dekodowanie i wyświetlanie na komputerze lokalnym. Zmieniaj pojedynczo rozdzielczość lub liczbę monitorów po stronie zdalnej i porównuj wyniki, a w razie potrzeby sprawdź liczniki związane z rysowaniem.

Czy szybki ping oznacza, że komunikacja RDP działa prawidłowo?

Samo to nie pozwala tego ocenić. ping mierzy odpowiedź na ICMP, a nie mierzy transferu obrazu RDP ani przetwarzania w aplikacji. W konfiguracjach z RD Gateway i podobnymi ścieżka też może się nie zgadzać. Również gdy odpowiedzi brak, odróżniaj blokowanie ICMP od braku łączności samego RDP.

Czy User Input Delay to czas od naciśnięcia klawisza do pojawienia się znaku?

Nie. To licznik, który mierzy czas oczekiwania od trafienia danych wejściowych do kolejki na komputerze zdalnym do ich pobrania przez proces. Nie jest to odczuwalne opóźnienie obejmujące przesył w obie strony, przetwarzanie w aplikacji po pobraniu danych oraz kompresję, dekodowanie i wyświetlenie obrazu.

Czy przy wolnym RDP należy wyłączyć UDP?

Nie zalecamy tego jako ogólnej reguły. Najpierw sprawdź rzeczywisty sposób połączenia, ścieżkę i zastosowane zasady. Bywa, że UDP jest niedostępne i połączenie już przeszło awaryjnie na TCP, a ograniczenie do samego TCP nie zawsze przyspiesza działanie. Porównuj przy ujednoliconych warunkach za zgodą administratora i wycofuj zbędne zmiany.

Profil autora

Strona z profilem autora artykułu.

Go Komura

Przedstawiciel KomuraSoft LLC

Zajmuje się głównie tworzeniem oprogramowania dla systemu Windows, konsultacjami technicznymi i diagnostyką błędów. Szczególnie dobrze sprawdza się w projektach z istniejącymi zasobami oraz w analizie awarii o trudnych do wskazania przyczynach.