Prečo je RDP pomalé, hoci je pripojenie rýchle? — Vstup, vykresľovanie a komunikáciu skúmajte oddelene

Test rýchlosti ukazuje stovky Mb/s, a predsa sa vo vzdialenej pracovnej ploche znaky zobrazujú s miernym oneskorením. Pri posúvaní stránky s množstvom fotografií obraz zadrháva. Len po stlačení vyhľadávania v podnikovej aplikácii sa všetko na niekoľko sekúnd zastaví. Kde začať skúmať taký stav, keď „je pripojenie rýchle, ale RDP pomalé“?

Odozvu RDP na vaše akcie neurčuje len prenosová rýchlosť pripojenia. Aj keď test rýchlosti vychádza dobre, môže sa čakať na komunikáciu tam a späť, na to, kým aplikácia na vzdialenom počítači prevezme vstup, na kódovanie obrazu alebo na dekódovanie a zobrazenie na lokálnom počítači. Najprv rozlíšte, „ktorá operácia je pomalá“, a tú istú operáciu porovnávajte vždy so zmenou jedinej podmienky. Porovnaním a meraním zúžite oblasť vyšetrovania a nastavenia UDP alebo GPU zvolíte podľa výsledku. Pozri: Merané úseky kvality pripojenia, Faktory výkonu hostiteľa relácií.

Vo fáze, keď ste oblasť vyšetrovania len zúžili, však koreňová príčina ešte nie je potvrdená. Ak sa situácia po znížení rozlíšenia zlepší, mení sa nielen komunikácia, ale aj spracovanie obrazu na oboch koncoch, a preto netvrdíme, že „príčinou bolo pripojenie“. Výsledky zaznamenávame oddelene pre úseky, ktoré sme zmerali, a pre tie, ktoré zmerané nie sú.

Tento článok sa venuje rozlišovaniu problémov so vstupom, posúvaním a odozvou aplikácií po nadviazaní pripojenia. Ani pri podobných príznakoch nemusí byť príčina len jedna. Prípady typu „trvá dlho, kým sa zobrazí prihlasovacia obrazovka“ alebo „zastaví sa to len pri overovaní“ považujeme za iný problém, ktorý sa skúma zo záznamov o nadviazaní pripojenia a overovaní.

Článok je určený najmä používateľom a správcom, ktorí sa z aplikácie Windows „Pripojenie vzdialenej pracovnej plochy“ (mstsc) pripájajú k Windows 11 alebo Windows Serveru. Príklady príkazov sú určené pre Windows PowerShell 5.1. Predpokladáme, že tú istú operáciu možno zopakovať v už pripojenej relácii.

Priame pripojenie, VPN, RD Gateway a Azure Virtual Desktop sa líšia cestou, dostupnými diagnostickými informáciami aj tým, kde sa nastavenia uplatnia. Príklad kontroly TCP 3389 platí len pre povolené priame pripojenie k hostiteľovi RDP, ktorý používa štandardný port. Diagnostické funkcie a nastavenia GPU z dokumentácie pre Azure Virtual Desktop neprenášame bez zmeny na bežné firemné počítače.

Na firemných zariadeniach skúmame len v rozsahu, ktorý povolil správca. Na zdieľanom hostiteľovi rozlíšte svoju reláciu a cieľový proces, a ak potrebujete záznamy iných používateľov, požiadajte o ne správcu. Dostupnosť počítadiel výkonu, ich zobrazované názvy a potrebné oprávnenia overujeme v každom prostredí osobitne.

Tu uvedené spôsoby kontroly vychádzajú z oficiálnej dokumentácie. Nejde o správu o meraní, pri ktorom by sa porucha na konkrétnom zariadení reprodukovala a odstránila. Číselné príklady uvádzame zreteľne odlíšené ako predpoklady na účely výkladu.

Princíp si môžete prečítať postupne od nasledujúcej časti „Prenosová rýchlosť a čas prenosu tam a späť“. Ak chcete začať od príznakov, prejdite na časť „Prvé porovnanie podľa príznaku“. Postupy nájdete v častiach „Porovnanie po jednej podmienke“ a „Meranie, kde sa čaká“.

V diagrame plná čiara označuje vzťah, ktorý platí vždy, a prerušovaná čiara vzťah podmienený (podmienky sú uvedené pri každom vzťahu na stránke s podrobnosťami). Úplný zoznam vzťahov (spolu 7, s dôkazmi a mierou istoty) a definície hlavných pojmov sú zhromaždené na stránke s podrobnosťami znalostnej mapy (v japončine). Údaje: JSON-LD / Turtle

Prenosová rýchlosť a čas prenosu tam a späť

RDP (Remote Desktop Protocol) je protokol, ktorým si lokálne zariadenie a vzdialený počítač vymieňajú vstup, obrazové dáta a ďalšie informácie. Okrem obrazu a vstupu prenáša aj dáta na presmerovanie zariadení, tlač a podobne. Pozri: Aké dáta RDP prenáša.

Prenosová rýchlosť pripojenia vyjadruje, koľko dát možno preniesť za sekundu. Hodnota „500 Mb/s“ z testu rýchlosti sa týka práve tohto množstva. Neudáva, ako dlho po akcii trvá, kým príde odpoveď. Pozri: Požiadavky RDP na šírku pásma.

flowchart TB
    accTitle: Čo vyjadruje číslo z testu rýchlosti
    accDescr: Ukazuje, že 500 Mb/s z testu rýchlosti je číslo vyjadrujúce množstvo dát prenesených za sekundu a že ide o iné číslo ako čas od akcie po príchod odpovede.
    A["Test rýchlosti: 500 Mb/s"] --> B["Dáta prenesené za 1 s"]
    B -.->|"Iné číslo"| C["Čas do príchodu odpovede"]

Obrázok 1: Číslo z testu rýchlosti vyjadruje prenesiteľné množstvo, nie čas do príchodu odpovede.

Čas prenosu tam a späť (RTT) je čas, za ktorý komunikácia dorazí k protistrane a vráti sa späť. Rozdiel medzi zvýšením prenosovej rýchlosti a skrátením času prenosu tam a späť pripomína rozdiel medzi pridaním jazdných pruhov na ceste a skrátením vzdialenosti do cieľa. Aj keď vzrastie schopnosť prenášať veľké množstvo súborov, čakanie na odpoveď na akciu zostane, ak sa čas prenosu tam a späť nezmení. Pozri: RTT a oneskorenie zobrazenia obrazovky.

flowchart TB
    accTitle: Prenosová rýchlosť a čas tam a späť ako cesta
    accDescr: Diagram prirovnáva zvýšenie prenosovej rýchlosti k pridaniu jazdných pruhov na ceste a skrátenie času prenosu tam a späť ku skráteniu vzdialenosti do cieľa.
    A["Zvýšiť prenosovú rýchlosť"] -->|"V doprave"| B["Pridať jazdné pruhy"]
    B ~~~ C["Skrátiť čas tam a späť"]
    C -->|"V doprave"| D["Skrátiť vzdialenosť"]

Obrázok 2: Pridaním jazdných pruhov sa vzdialenosť do cieľa neskráti.

Kým sa vráti výsledok jedného znaku

Uvažujme situáciu, keď do vzdialeného Poznámkového bloku napíšete jeden znak. Poznámkový blok beží na vzdialenom počítači. Ak na účely výkladu predpokladáme, že akcia dorazí za 50 milisekúnd a obrazové dáta s výsledkom sa vrátia za 50 milisekúnd, komunikácia zaberie spolu 100 milisekúnd, teda 0,1 sekundy. Čas spracovania na oboch koncoch sme z tohto príkladu vynechali.

flowchart TB
    accTitle: Príklad času komunikácie, kým sa vráti výsledok jedného znaku
    accDescr: Príklad na účely výkladu, ktorý predpokladá 50 milisekúnd tam a 50 milisekúnd späť. Nezahŕňa čas spracovania na oboch koncoch a nevyjadruje ani počet paketov na jeden kláves.
    A["Zadanie znaku na lokálnom PC"] -->|"Tam: 50 ms"| B["Vzdialený PC prijme vstup"]
    B --> C["Odoslanie obrazu so vstupom"]
    C -->|"Späť: 50 ms"| D["Výsledok príde na lokálny PC"]

Obrázok 3: Pri predpoklade 50 ms tam a 50 ms späť zaberie samotná komunikácia 0,1 sekundy. Nejde o namerané hodnoty.

Aj keď vzrastie množstvo dát, ktoré pripojenie dokáže preniesť, týchto 0,1 sekundy zostane, ak sa nezmení čas prenosu tam a späť. Obrázok 3 je koncepčná schéma, ktorá pomáha pochopiť spracovanie. Neznamená, že sa pre každý kláves posiela samostatný paket tam a späť. Cesta k serveru testu rýchlosti a k cieľovému počítaču RDP sa tiež líši, a preto počítame aj s VPN, bránou, odchádzajúcim pásmom na strane vzdialeného počítača a preťažením po ceste. Pozri: Ako chápať RTT, Výkon siete a hostiteľa.

Vytvorenie a doručenie obrazu

Oneskorenou odozvou na akcie tu rozumieme čakanie od akcie na lokálnom počítači do chvíle, keď uvidíte výsledok. Podieľa sa na nej nielen RTT, ale aj spracovanie v aplikácii a vytvorenie a doručenie obrazu. Odlišujeme ju aj od oneskorenia samotného úseku prenosu obrazu. Pozri: Meraný úsek od zachytenia obrazovky po zobrazenie.

Keď vstup dorazí z lokálneho počítača na vzdialený, aplikácia na vzdialenom počítači ho spracuje a aktualizuje obrazovku, zakódované obrazové dáta sa prenesú cez pripojenie a lokálny počítač ich dekóduje a zobrazí. Pred komunikáciou aj po nej teda prebieha práca, ktorú majú na starosti rôzne počítače. Pozri: Spracovanie od zachytenia obrazovky po zobrazenie.

flowchart TB
    accTitle: Spracovanie obrazu pred prenosom aj po ňom
    accDescr: Priebeh od chvíle, keď vstup z lokálneho počítača dorazí na vzdialený počítač, cez spracovanie v aplikácii, vytvorenie a kompresiu obrazu až po prevedenie prenesených obrazových dát na lokálnom počítači do zobraziteľnej podoby a ich zobrazenie.
    I["Lokálny PC: zadanie akcie"] --> J["Pripojenie: prenos vstupu"]
    J --> K["Vzdialený PC: spracovanie v aplikácii"]
    K --> A["Vzdialený PC: tvorba a kompresia obrazu"]
    A --> B["Pripojenie: prenos obrazu"]
    B --> C["Lokálny PC: prevod na zobrazenie"]
    C --> D["Zobrazenie na lokálnom PC"]

Obrázok 4: Spracovanie a kompresia na vzdialenom počítači, prenos cez pripojenie a prevod na zobrazenie na lokálnom počítači. Každú z týchto prác vykonáva iné miesto.

Kódovaním v tomto článku rozumieme spracovanie, pri ktorom vzdialený počítač prevedie a skomprimuje obraz do podoby vhodnej na odoslanie. Okrem prenosu cez pripojenie zaberá aj čas spracovania na vzdialenom počítači. Pozri: Čas kódovania na vzdialenom počítači.

Dekódovaním v tomto článku rozumieme spracovanie, pri ktorom lokálny počítač prevedie doručené obrazové dáta späť do zobraziteľnej podoby. Odlišujeme ho od dešifrovania v zmysle zrušenia šifrovania. Pozri: Dekódovanie a čas zobrazenia na lokálnom počítači.

Ak kompresia na vzdialenom počítači trvá dlho, čaká sa na pripravenie odoslania, aj keď je pripojenie voľné. Aj keď dáta dorazia, aktualizácia sa oneskorí, ak lokálne dekódovanie alebo zobrazenie nestíha. Neplatí vždy, že „keď je firemný počítač výkonný, na lokálnom zariadení nezáleží“. Rezerva pripojenia a rezerva spracovania na jeho oboch koncoch sú dve rozdielne veci. Pozri: Počítadlá výkonu spracovania obrazu.

flowchart TB
    accTitle: Oneskorenie, keď spracovanie na oboch koncoch nestíha
    accDescr: Ukazuje, že keď kompresia na vzdialenom počítači trvá dlho, čaká sa na pripravenie odoslania aj pri voľnom pripojení, a keď lokálne dekódovanie alebo zobrazenie nestíha, aktualizácia sa oneskorí, aj keď dáta dorazili.
    A["Kompresia na vzdialenom PC trvá"] --> B["Odoslanie čaká aj pri voľnej linke"]
    B ~~~ C["Lokálne dekódovanie nestíha"]
    C --> D["Aktualizácia sa oneskorí aj po doručení"]

Obrázok 5: Aj keď má pripojenie rezervu, aktualizácia obrazovky sa oneskorí, ak spracovanie na oboch koncoch nestíha.

Rozdiel medzi písaním a posúvaním

Keď do Poznámkového bloku pridáte jeden znak, zmení sa len malá časť obrazovky. Pri posúvaní stránky s množstvom fotografií sa jedna za druhou menia veľké plochy zobrazenia. RDP obmedzuje objem komunikácie prenosom zmenených častí a kompresiou a ukladaním do vyrovnávacej pamäte prispôsobenými obsahu. Neposiela zakaždým celú obrazovku bez kompresie. Množstvo práce sa mení podľa obsahu obrazovky a frekvencie aktualizácií. Pozri: Vzťah medzi obsahom obrazovky a šírkou pásma.

flowchart TB
    accTitle: Práca s obrazom pri písaní a posúvaní
    accDescr: Malá zmena znaku a súvislé aktualizácie veľkej plochy sa líšia povahou práce pri vytváraní a odosielaní obrazu.
    A{"Zmena obrazovky"} -->|"Pridanie znaku"| B["Malá oblasť"]
    A -->|"Posúvanie"| D["Súvislá veľká plocha"]
    B --> E["Kompresia a prenos podľa zmeny"]
    D --> E

Obrázok 6: Aj v rámci toho istého pripojenia sa množstvo práce líši medzi pridaním jedného znaku a situáciou, keď sa neustále pohybuje veľká plocha.

Statický dokument môže byť nenáročný, ale pri posúvaní môže prenosu obrazovky dôjsť rezerva. Keď na vzdialenej strane zvýšite rozlíšenie alebo počet monitorov, zväčší sa aj spracovávaná obrazovka. Porovnanie so zníženým rozlíšením je experiment, ktorý ukáže, či sa plynulosť vráti, keď ubudne práce s vytváraním a odosielaním obrazu. Nejde o výpočet, ktorý by objem komunikácie určil len z počtu pixelov. Pozri: Vplyv rozlíšenia, aktualizácií obrazovky a kompresie.

Čakanie v aplikácii

Ak sa na niekoľko sekúnd zastaví len vyhľadávanie v podnikovej aplikácii, ale do Poznámkového bloku v tej istej relácii možno písať normálne, overíme, na čo táto aplikácia čaká. Aplikácia na vzdialenom počítači môže posielať dopyt do ďalšej databázy alebo čítať súbor zo zdieľaného priečinka a čakať na odpoveď. To je iná cesta ako komunikácia RDP medzi lokálnym a vzdialeným počítačom. Pozri: Komunikácia zo vzdialeného počítača do back-endu.

flowchart TB
    accTitle: Aj za RDP sú ďalšie protistrany komunikácie
    accDescr: Ukazuje, že okrem komunikácie medzi lokálnym zariadením a vzdialeným počítačom môže aplikácia na vzdialenom počítači čakať na odpoveď podnikového servera.
    A["Lokálne zariadenie"] -->|"RDP"| B["Podniková aplikácia na vzdialenom PC"]
    B -->|"Vyhľadávanie, požiadavka na súbor"| C["DB, zdieľaný priečinok"]
    C -->|"Očakávaná odpoveď"| B

Obrázok 7: Podniková aplikácia za RDP môže čakať na odpoveď ešte ďalšieho servera.

Keď spracovanie, ktoré má na starosti obrazovku a vstup, dostane dlhú úlohu, ďalší vstup a aktualizácie obrazovky sa oneskoria. Napríklad vo WPF sa schopnosť reagovať zhorší, keď je vlákno UI dlho obsadené. Samotné nízke celkové využitie CPU nevylučuje čakanie konkrétneho vlákna UI. Pozri: Dispatcher a vlákno UI.

flowchart TB
    accTitle: Spracovanie obrazovky a vstupu sa zahltí
    accDescr: Ukazuje, že keď spracovanie, ktoré má na starosti obrazovku a vstup, dostane dlhú úlohu, ďalší vstup a aktualizácie obrazovky sa oneskoria, a nízke celkové využitie CPU samo osebe toto čakanie nevylučuje.
    A["Spracovanie obrazovky a vstupu"] --> B["Dostane dlhú úlohu"]
    B --> C["Ďalší vstup a prekreslenie meškajú"]
    C -.- D["Nízke celkové CPU to nevylučuje"]

Obrázok 8: Čakanie vlákna UI nemožno vylúčiť len podľa celkového využitia CPU.

Prvé porovnanie podľa príznaku

Prenesiteľné množstvo dát, čas čakania na odpoveď a čas vytvorenia a zobrazenia obrazu sú tri rozdielne veci. Ak ich budete rozlišovať, nepripíšete „pomalé RDP“ jedinej príčine a môžete skúmať od operácie, ktorá je pomalá práve teraz.

flowchart TB
    accTitle: Najprv oddeliť tri veci, potom skúmať
    accDescr: Ukazuje, že „pomalé RDP“ nepripisujeme jedinej príčine, ale oddelíme prenesiteľné množstvo, čas čakania na odpoveď a čas vytvorenia a zobrazenia obrazu a skúmame od operácie, ktorá je pomalá práve teraz.
    A["„Pomalé RDP“"] --> S
    subgraph S["Sledovať oddelene"]
    direction TB
    B["Prenesiteľné množstvo"] ~~~ C["Čas čakania na odpoveď"]
    C ~~~ D["Čas tvorby a zobrazenia obrazu"]
    end
    S --> E["Skúmať od práve pomalej operácie"]

Obrázok 9: Keď oddelíte prenesiteľné množstvo, čas čakania na odpoveď a čas vytvorenia a zobrazenia obrazu, môžete skúmať od operácie, ktorá je pomalá práve teraz.

Cieľom rozlišovania je obmedziť miesta, kde sa pomalosť skúma. Cieľom nie je hromadne zmeniť nastavenia a náhodou dosiahnuť zrýchlenie. Keď využijete rozdiely ako „Poznámkový blok funguje, ale zastavuje sa len vyhľadávanie“ alebo „písanie je normálne, ale pomalé je len posúvanie“, môžete vstupný bod vyšetrovania zvoliť ešte pred zmenou sieťových nastavení.

Nasledujúca tabuľka je východiskovým bodom vyšetrovania. Nie je to tabuľka, podľa ktorej sa určuje príčina. Najprv porovnáte operácie v tej istej relácii a až potom meníte potrebné zariadenie, cestu alebo podmienky zobrazenia.

Znaky sa oneskorujú vo viacerých aplikáciách

Ak sa znaky po jednom oneskorujú vo viacerých aplikáciách v tej istej relácii, porovnáme tú istú operáciu aj z iného zariadenia alebo cez inú povolenú cestu. Čas prenosu tam a späť, čakanie na vstup na vzdialenom počítači a záťaž celého vzdialeného počítača posudzujeme spoločne a príčinu neurčujeme podľa jediného čísla.

Trhá sa len posúvanie

Aj keď je písanie normálne, pri posúvaní stránky s množstvom fotografií prebiehajú nepretržité aktualizácie veľkej časti obrazovky. Rozlíšenie alebo počet monitorov na vzdialenej strane meníme po jednom a porovnávame na tej istej stránke. Ak sa situácia zlepší, ďalším predmetom vyšetrovania je kompresia na vzdialenom počítači, prenos obrazovky a lokálne dekódovanie. Samotné rozlíšenie neprezradí, ktorá z týchto troch vecí je príčinou. Pozri: Záťaž podľa obsahu obrazovky a rozlíšenia.

Zamŕza len jedna aplikácia

Ak sa zastaví len podniková aplikácia, v ktorej ste stlačili vyhľadávanie, porovnáme, či reaguje Poznámkový blok alebo iná aplikácia v tej istej relácii. Ak iné aplikácie fungujú, najprv skúmame spracovanie v cieľovej aplikácii, disk a požiadavky do databázy alebo zdieľaného priečinka. To, že aplikáciu ovládate cez RDP, a to, že príčinou čakania je komunikácia RDP, sú dve rozdielne veci. Pozri: Faktory výkonu aplikácie a back-endu.

Spomalenie všetkých len pri náraste používateľov

Ak sa v rovnakom čase spomalí viac používateľov, overíme u správcu stav ostatných relácií. Záťaž CPU, pamäte a úložiska zdieľaného hostiteľa a zdieľaného pripojenia porovnávame s časom výskytu príznakov. K záznamom a procesom ostatných používateľov bez povolenia nepristupujeme a ich úlohy nezastavujeme. Pozri: Prostriedky zdieľaného hostiteľa a počet používateľov.

Spomalenie počas kopírovania alebo tlače

Ak sa ťažkosti časovo kryjú so spustením vášho kopírovania alebo tlače, pozastavíme na porovnanie len tie prenosy, ktorých zastavenie je povolené. Zaznamenáme, či sa po pozastavení stav vráti do normálu a či sa po obnovení opäť spomalí, a skúmame súbeh s inými prenosmi ako obrazovky a s presmerovaním zariadení. Porovnanie, pri ktorom by sa hromadne vypli zariadenia potrebné na prácu, nevykonávame. Pozri: Vplyv presmerovania zariadení.

Porovnanie po jednej podmienke

Nie je potrebné postupne meniť všetky nastavenia. Najprv vytvoríme základ na porovnanie a vyberieme len kontroly zodpovedajúce príznaku. Pred zmenou nastavení alebo opätovným pripojením uložte rozpracovanú prácu a zaznamenajte pôvodné hodnoty a spôsob, ako ich vrátiť. Ak chýbajú potrebné oprávnenia alebo funkcie, nezapíname ich nasilu a vec odovzdáme správcovi.

Lokálne ovládanie a ovládanie cez RDP nemusia prebiehať za rovnakých podmienok. To, že je vzdialený počítač rýchly priamo na svojej fyzickej obrazovke, je užitočná indícia, ale relácia a podmienky vykresľovania sa môžu líšiť. Zjednoťte používateľa, dáta a stav aplikácie a neobmedzujte príčinu na pripojenie len preto, že „priamo na obrazovke je to rýchle“.

Porovnanie tej istej operácie

Pripravíte toho istého používateľa, tie isté dáta a tú istú operáciu. Na zdieľanom hostiteľovi si overíte svoju reláciu a aplikácie ani procesy ostatných používateľov sa nezastavujú. Aj použitie iného zariadenia alebo inej cesty je obmedzené na rozsah povolený správcom.

1. V pôvodných nastaveniach zopakujete pomalú operáciu a zaznamenáte čas a príznak.

   V Poznámkovom bloku v tej istej vzdialenej relácii ako problémová aplikácia napíšete približne rovnaké množstvo textu. Rozlíšite tak, či ide len o jednu aplikáciu, alebo o celú reláciu.

2. V rovnakom čase skontrolujete záťaž vzdialeného a lokálneho počítača.

   V Správcovi úloh sledujete na vzdialenom počítači CPU, pamäť a disk cieľovej aplikácie a na lokálnom počítači záťaž klienta RDP. Nekontrolujete len celkovú hodnotu CPU, ale aj cieľový proces. Pozri: Čo sledovať pri skúmaní záťaže.

3. Zmeníte len jednu z týchto podmienok: iné zariadenie, inú povolenú cestu alebo podmienky zobrazenia, a tú istú operáciu zopakujete.

   Ak sa pri porovnaní súčasne zmení aj stav vzdialeného počítača alebo aplikácie, zaznamenáte aj tento rozdiel. Výsledok, pri ktorom sa zmenilo viac podmienok, nepovažujeme za účinok jedinej podmienky.

4. Vrátite pôvodné podmienky a tú istú operáciu znova overíte.

   Ak zostane rýchlosť zachovaná aj po vrátení, môže ísť okrem iného o dočasnú zmenu záťaže. Neusudzujeme hneď, že zmena pomohla, a zaznamenáme podmienky, za ktorých sa príznak opakuje.

Máte pohromade výsledky z pôvodného stavu, po zmene a po vrátení späť a môžete porovnať, ktoré podmienky zodpovedajú ktorým príznakom. Podmienka, s ktorou sa situácia zlepšila, je indíciou pre vyšetrovanie a sama osebe koreňovú príčinu nedokazuje.

flowchart TB
    accTitle: Obmedziť podmienky menené naraz
    accDescr: Postup, keď určíme operáciu, ktorá sa reprodukuje v pôvodnom stave, zmeníme len jednu podmienku, porovnáme a overíme aj výsledok po vrátení späť.
    A["Tá istá operácia v pôvodných nastaveniach"] --> B["Zmeniť len jednu podmienku"]
    B --> C["Zopakovať tú istú operáciu"]
    C --> D["Vrátiť späť a znova overiť"]
    D --> E["Zaznamenať podmienku zlepšenia"]

Obrázok 10: Tú istú operáciu opakujeme v pôvodnom stave, po zmene a po vrátení späť a zaznamenáme podmienku, ktorá sa zmenila.

Porovnanie rozlíšenia na vzdialenej strane

Toto porovnanie použijete, keď sú náročné aktualizácie obrazovky, napríklad pri posúvaní. Zaznamenáte rozlíšenie a počet monitorov pred zmenou, uložíte prácu a potom sa znova pripojíte. Nastavenie, ktoré zhoršuje obrazovku potrebnú na prácu alebo čitateľnosť textu, sa nepoužíva natrvalo.

1. Zmeníte len jedno z dvojice: počet monitorov, alebo rozlíšenie.

   V mstsc môžete porovnávať pomocou nastavení na karte „Zobrazenie“ pred pripojením alebo zadaním šírky a výšky. Pozri: Zadanie obrazovky v mstsc.

2. Overíte, že sa skutočná veľkosť pracovnej plochy vzdialeného počítača zmenila, a posúvate tú istú stránku.

   Ak len zmenšíte okno na lokálnom počítači, veľká pracovná plocha sa môže iba zobrazovať zmenšene. Rozlišujete dynamické rozlíšenie a smart sizing a overíte, za akých podmienok ich používaný klient podporuje. Pozri: Rozlíšenie pracovnej plochy a mierka zobrazenia.

3. Vrátite pôvodné nastavenia, zopakujete tú istú operáciu a porovnáte záťaž na oboch koncoch a pohyb obrazu.

   Ak ste naraz znížili rozlíšenie aj prešli na jeden monitor, ide len o hrubé porovnanie. Ak sa situácia zlepší, vracajte zmeny po jednej a ich vplyv oddeľte.

Ak sa situácia zlepší, indícia leží v oblasti spracovania a prenosu obrazovky. 3840×2160 má štvornásobok pixelov oproti 1920×1080, objem komunikácie však nemusí byť vždy štvornásobný. Mení sa podľa zmenených častí a kompresie a zmena rozlíšenia ovplyvňuje aj spracovanie na oboch koncoch. Pozri: Vzťah medzi počtom pixelov a objemom komunikácie, Kontrola spracovania obrazu.

flowchart TB
    accTitle: Čo ukáže porovnanie so zníženým rozlíšením
    accDescr: Zníženie rozlíšenia na vzdialenej strane môže zmeniť záťaž spracovania obrazu aj prenosu, a preto samotné zlepšenie neumožňuje obmedziť príčinu na pripojenie.
    A["Znížiť rozlíšenie na vzdialenej strane"] --> S
    subgraph S["Mení sa spracovanie"]
    direction TB
    B["Spracovanie obrazu na vzdialenom PC"] ~~~ C["Množstvo odosielaných dát"]
    C ~~~ D["Zobrazenie na lokálnom PC"]
    end

Obrázok 11: Zmena rozlíšenia je porovnanie, ktoré ovplyvňuje nielen pripojenie, ale aj spracovanie obrazu na vzdialenom a lokálnom počítači.

Porovnanie kopírovania a tlače s príznakmi

Pozastavujeme len procesy, ktorých zastavenie je povolené, napríklad prenosy, ktoré ste sami spustili. Firemné zálohovanie, bezpečnostné procesy ani úlohy ostatných používateľov nezastavujeme. Presmerovanie zvukových a vstupných zariadení potrebných na prácu hromadne nevypíname.

1. Pred spustením a počas kopírovania, synchronizácie s cloudom alebo tlače zaznamenáte tú istú operáciu a záťaž.

   Cez RDP prúdia okrem obrazovky aj dáta jednotiek, tlačiarní a podobne. Presmerovanie, ktoré umožňuje používať lokálne zariadenia na vzdialenom počítači, môže počas používania zvýšiť záťaž komunikácie a spracovania. Pozri: Vplyv presmerovania zariadení.

2. Cieľový prenos v povolenom rozsahu pozastavíte a tú istú operáciu znova overíte.

   Ak možno prenos obnoviť a porovnať, zaznamenáte aj príznaky po obnovení. Aj keď skúšate zmeny nepotrebného presmerovania zariadení, meníte ich po jednom a tak, aby sa dali vrátiť pôvodné nastavenia.

Môžete posúdiť, či si zodpovedá spustenie prenosu a ťažkosti a pozastavenie a zotavenie. Ak sa súvislosť ukáže, porovnáme prenosy mimo obrazovky a záťaž zdieľaných prostriedkov so záznamami správcu.

flowchart TB
    accTitle: Stav pred ťažkosťami a po nich na tej istej časovej osi
    accDescr: Pred prenosom, počas neho a po jeho zastavení zaznamenáme tú istú operáciu a záťaž a porovnáme vzťah medzi ťažkosťami a prácou.
    A["Operácia a záťaž pred prenosom"] --> B["Operácia a záťaž počas prenosu"]
    B --> C["Operácia a záťaž po zastavení"]
    C --> D["Zodpovedajú si ťažkosti a zotavenie?"]

Obrázok 12: Sledujeme, ako sa pred prenosom, počas neho a po zastavení mení pomalosť tej istej operácie a záťaž.

Meranie, kde sa čaká

Z lokálneho počítača skúmame komunikáciu tam a späť a pripojenie TCP, na vzdialenom počítači čakanie vo vstupnom fronte a aktualizácie obrazovky. Každé číslo meria len obmedzený úsek, a preto výsledky čítame v porovnaní s tabuľkou v časti „Rozsah platnosti výsledkov merania“.

Kontrola ICMP a pripojenia TCP

Spúšťa sa na lokálnom zariadení s Windows. Týka sa len konfigurácie, keď sa vo firemnej sieti LAN alebo cez povolenú VPN pripájate priamo k hostiteľovi RDP so štandardným TCP 3389. Pri konfiguráciách cez RD Gateway či Azure Virtual Desktop alebo s vlastným portom určte cieľ kontroly spolu so správcom. Porty nesprístupňujeme a bránu firewall nemeníme.

1. Zadáte povolený cieľový počítač a zaznamenáte výsledky odpovede ICMP a pripojenia TCP.

   $target = Read-Host 'Názov alebo IP adresa hostiteľa RDP, ktorého skúmanie je povolené'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Zadajte cieľový počítač.'
   }
       
   # Čas odpovede ICMP sledujeme viackrát. Samotné zlyhanie neznamená, že RDP nefunguje.
   ping.exe -n 20 $target
       
   # Kontrola len pre konfiguráciu s priamym pripojením na štandardný TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Výsledky z času spomalenia a z bežného času porovnáte s časom výskytu príznakov a so skutočnou cestou pripojenia.

   20 pokusov ping je len krátke pozorovanie. Kolísanie hodnôt a chýbajúce odpovede zaznamenáte, ICMP však môže byť blokované. Občasné výpadky nevylučujete len podľa priemernej hodnoty a použijete informácie o pripojení alebo záznamy komunikácie od správcu. Pozri: Čo ping meria.

TcpTestSucceeded: True znamená, že sa podarilo nadviazať pripojenie TCP k zadanému portu. Šírku pásma, UDP, operácie po overení ani plynulosť obrazu nemeria. Test-NetConnection nemá prepínač -UDP, ktorým by sa skúmalo UDP. Pozri: Syntax a výsledky Test-NetConnection.

Pri posudzovaní zohľadňujeme rozdiely v ceste a službe. Pri RD Gateway a podobne sa cesta ICMP alebo priameho pripojenia TCP k hostiteľovi nemusí zhodovať so skutočnou cestou RDP. V Azure Virtual Desktop sú k dispozícii RTT a odhad šírky pásma pre jednotlivé pripojenia, táto diagnostická funkcia je však určená pre túto službu. Krátke výpadky nevylučujeme len podľa priemernej hodnoty. Pozri: Protokoly kvality pripojenia v Azure Virtual Desktop.

flowchart TB
    accTitle: Overená cesta a skutočná cesta RDP
    accDescr: V konfiguráciách s RD Gateway a podobne sa cesta ICMP alebo priameho pripojenia TCP z lokálneho počítača k hostiteľovi nemusí zhodovať so skutočnou cestou RDP.
    A["Lokálne zariadenie"] -->|"ICMP, priame TCP"| C["Hostiteľ RDP"]
    A -->|"Skutočné RDP"| B["RD Gateway a pod."]
    B --> C

Obrázok 13: Cesta ICMP alebo priameho pripojenia TCP k hostiteľovi sa nemusí zhodovať s cestou skutočného RDP.

Meranie čakania vo vstupnom fronte

User Input Delay meria čakanie od chvíle, keď sa vstup na vzdialenom počítači zaradí do frontu, do chvíle, keď si ho proces vyzdvihne. Nejde o celkový čas od stlačenia klávesu po zobrazenie znaku. Pozri: Definícia User Input Delay.

Skúma sa vo vnútri vzdialenej relácie na vzdialenom počítači. Podľa Microsoftu sú podporované Windows 10 verzie 1809 a novšie a Windows Server 2019 a novšie. Na týchto systémoch nie je na zapnutie potrebné pridávať položku do registra. Overíte zobrazovaný názov, oprávnenia a prítomnosť počítadla, a ak ho nemožno použiť, zaznamenáte túto skutočnosť a poradíte sa so správcom. Pozri: Podmienky podpory a nastavenia.

1. V PowerShelli v tej istej relácii si poznačíte čas a ID relácie.

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

   Na dopytovanie na relácie ostatných používateľov môžu byť potrebné ďalšie oprávnenia. Štandardný názov inštancie cieľového procesu je SessionID:ProcessID <Process Image>. Dbáte na to, aby ste len podľa ID relácie nezmiešali hodnoty iných používateľov alebo procesov s rovnakým názvom. Pozri: Oprávnenia pre query session, Identifikácia inštancie.

2. V perfmon.exe pridáte dostupné počítadlo User Input Delay per Process alebo User Input Delay per Session.

   Vyberiete cieľový proces alebo reláciu a spočiatku sledujete v predvolenom intervale 1 sekundy. Rozlišujte agregovanú inštanciu, ktorá združuje viac relácií, a hodnoty jednotlivých relácií.

3. Zopakujete operáciu s pomalým vstupom a porovnáte čakanie vo fronte s časom výskytu príznaku.

   Pri jednotlivých meraných objektoch sa sleduje najdlhší čas čakania v meranom intervale. Aj keď je hodnota nízka, spracovanie po tom, ako aplikácia vstup vyzdvihne, a oneskorenie do návratu výsledku na lokálny počítač tým nezmiznú.

Môžete zistiť, či sa čaká vo vstupnom fronte na vzdialenom počítači. Ide o iný ukazovateľ ako vnímaný čas, ktorý zahŕňa komunikáciu tam a späť a zobrazenie na lokálnom počítači. Pozri: Význam maximálnej hodnoty a meraného intervalu.

flowchart TB
    accTitle: Úsek, ktorý meria User Input Delay
    accDescr: Meraným úsekom je čas od vstupného frontu na vzdialenom počítači po vyzdvihnutie aplikáciou; komunikácia a zobrazenie obrazovky pred ním a po ňom zahrnuté nie sú.
    A["Vstup príde z lokálneho PC"] --> B["Zaradenie do vstupného frontu"]
    B -->|"Meria sa tento úsek"| C["Aplikácia vyzdvihne vstup"]
    C --> D["Spracovanie v aplikácii a prenos obrazu"]
    D --> E["Zobrazenie na lokálnom PC"]

Obrázok 14: Meria sa čakanie vo vstupnom fronte na vzdialenom počítači. To nie je to isté ako celkový čas, kým uvidíte výsledok na lokálnom počítači.

Aktualizácie obrazovky a dôvody vynechávania snímok

Pripravíte operáciu so súvislými aktualizáciami obrazovky, napríklad posúvanie. Dostupnosť počítadiel RemoteFX Graphics a miesto merania treba overiť podľa OS, konfigurácie hostiteľa a oprávnení. Tu dostupné počítadlá iba čítame. Nejde o postup inštalácie alebo zapnutia starej funkcie RemoteFX. Pozri: Podmienky platnosti počítadiel Graphics.

1. Pomocou query session alebo qwinsta zistíte názov cieľovej relácie a vyberiete zodpovedajúcu inštanciu počítadla.

2. Počas operácie s aktualizáciami obrazovky porovnáte Input Frames/Second a Output Frames/Second.

   Ak je výstupných snímok menej ako vstupných, časť snímok sa cestou vynecháva. Skontrolujete hodnoty Frames Skipped/Second rozdelené podľa nedostatku prostriedkov na vzdialenom počítači, v sieti a na klientovi.

3. Dôvody vynechávania porovnáte so záťažou oboch koncov a komunikácie a skontrolujete aj Average Encoding Time.

   Ak je čas kódovania dlhý, skúmate kompresiu na vzdialenom počítači. Ak je snímok málo už na vstupe, je tiež možné, že aplikácia obrazovku často neaktualizuje. Nízky počet snímok pri statickej obrazovke sám osebe nie je anomália.

Zo vstupných a výstupných snímok počas aktualizácií obrazovky, z dôvodov vynechávania a z času kódovania môžete zúžiť oblasť vyšetrovania. Rozdelenie podľa počítadiel je indíciou a posudzujeme ho spolu so skutočnou záťažou a konfiguráciou pripojenia. Pozri: Ako čítať počty snímok a čas kódovania.

flowchart TB
    accTitle: Zúženie oblasti vyšetrovania podľa vynechávania snímok
    accDescr: Počas operácie s aktualizáciami obrazovky porovnáme počty vstupných a výstupných snímok a pomocou počítadiel dôvodov vynechávania ich porovnáme so záťažou spracovania, komunikácie a zobrazenia.
    A["Porovnať vstup a výstup pri posúvaní"] --> B["Menej výstupu: overiť vynechávanie"]
    B --> C["Sledovať počítadlá podľa dôvodu"]
    C --> D["Porovnať so záťažou vzdialeného PC, siete a lokálneho PC"]

Obrázok 15: Porovnáme vstup a výstup počas posúvania a dôvody vynechávania porovnáme so záťažou vzdialeného počítača, pripojenia a lokálneho počítača.

Koncepčné schémy prenosu obrazovky ani staršiu dokumentáciu nezovšeobecňujeme na všetky konfigurácie. Existujú aj konfigurácie, ktoré prenášajú video a zvuk iným mechanizmom. Dokumentácia k počítadlám Graphics opisuje aj staršie konfigurácie, a preto uvedené hodnoty nevykladáme ako spoločnú špecifikáciu typu „každé RDP má maximálne 30 fps“. Funkcie a hodnoty používame až po overení, na čo sa vzťahujú. Pozri: Prenos obrazovky a typ záťaže, Dokumentácia k počítadlám Graphics.

Rozsah platnosti výsledkov merania

Nízke číslo nestotožňujeme s pohodlným ovládaním. Rozsah jednotlivých ukazovateľov si môžete overiť v dokumentácii Microsoftu uvedenej v postupoch.

Nastavenia komunikácie a GPU

Nastavenia UDP a GPU volíme podľa toho, čo ukázalo porovnanie a meranie. Ak je podozrivá komunikácia, najprv overujeme spôsob pripojenia a cestu; ak je podozrivé spracovanie obrazu, najprv overujeme, v ktorých fázach sa GPU používa.

Kontrola TCP, UDP a cesty pripojenia

Ak porovnanie a meranie ukážu na komunikáciu, overíte so správcom používaného klienta, cestu a uplatňované politiky. Aj keď je zmena nastavení potrebná, obmedzíte ju na schválený rozsah a zaznamenáte hodnoty pred zmenou a spôsob obnovenia. Bránu firewall ani overovanie nevypíname a port RDP nesprístupňujeme priamo do internetu.

1. Pomocou informácií o pripojení, diagnostických protokolov produktu a záznamov komunikácie od správcu overíte skutočné použitie TCP či UDP a cestu.

   RDP používa TCP alebo UDP podľa konfigurácie a podmienok komunikácie. Pomocou „Select RDP transport protocols“ možno zvoliť nastavenie, ktoré používa UDP alebo TCP, alebo nastavenie len s TCP. Keďže pri nenadviazaní pripojenia UDP sa môže použiť TCP, samotné úspešné pripojenie spôsob prenosu neprezradí. Pozri: Výber transportu RDP a záložný prechod.

2. Čas výskytu príznakov porovnáte s cestou a spôsobom prenosu a po jednom porovnávate len potrebné nastavenia.

   Nastavenia nemeníme plošne s predstavou, že „vypnutím UDP sa to zrýchli“. Porovnávame pri rovnakých podmienkach VPN a brány, rovnakej operácii a rovnakých podmienkach zobrazenia a nepotrebné zmeny vraciame späť.

So znalosťou spôsobu prenosu a cesty môžete zaznamenať vzťah medzi zmenou a príznakmi. Obmedzenie len na TCP nemusí vždy znamenať zrýchlenie.

flowchart TB
    accTitle: Sieťové nastavenia porovnať až po overení spôsobu pripojenia
    accDescr: Rozlíšime bežné priame pripojenie a pripojenie cez bránu alebo službu, overíme skutočnú cestu a spôsob prenosu a až potom vykonáme povolené porovnanie.
    A["Používaný klient a konfigurácia pripojenia"] --> B["Overiť skutočnú cestu, TCP či UDP"]
    B --> C["Porovnať s časom príznakov"]
    C --> D["Porovnať po jednom len nutné nastavenia"]

Obrázok 16: Overíme používaný spôsob pripojenia a cestu, porovnáme ich s príznakmi a až potom porovnávame len nutné nastavenia.

RDP Shortpath je mechanizmus služby Azure Virtual Desktop. Nadväzuje cestu UDP tejto služby a podľa konfigurácie používa priamu cestu alebo cestu cez sprostredkovateľa. Ak ju nemožno nadviazať, vráti sa k pripojeniu založenému na TCP. Nedá sa preň použiť rovnaká tabuľka nastavení ako pre priame pripojenie k firemnému počítaču pomocou mstsc. Pozri: Cesty RDP Shortpath a záložný prechod.

flowchart TB
    accTitle: Cesty RDP Shortpath a záložný prechod
    accDescr: RDP Shortpath v Azure Virtual Desktop sa pokúsi nadviazať cestu UDP; ak sa to podarí, použije podľa konfigurácie priamu cestu alebo sprostredkovateľa, a ak nie, vráti sa k pripojeniu založenému na TCP.
    A["RDP Shortpath"] --> B{"Cesta UDP"}
    B -->|"Nadviazaná"| C["Priamo, alebo cez sprostredkovateľa"]
    B -->|"Nenadviazaná"| D["Návrat k TCP"]

Obrázok 17: Ak RDP Shortpath nedokáže nadviazať cestu UDP, vráti sa k pripojeniu založenému na TCP.

Kontrola využitia GPU pri spracovaní obrazu

Túto kontrolu vykonávate, ak porovnanie a meranie ukážu na spracovanie obrazu. Overíte výsledky merania spracovania obrazu a podporované OS, ovládače, politiky a klienta. Samotná prítomnosť GPU nie je dôvodom na zmenu nastavení. Najprv získate súhlas správcu a pripravíte sa na vrátenie späť.

1. Rozdelíte vykresľovanie v aplikácii na vzdialenom počítači, kódovanie RDP a lokálne dekódovanie a vyberiete podozrivú fázu.

   Aj keď je GPU k dispozícii, nemusia ho využívať všetky fázy. Aj v dokumentácii Microsoftu ku konfigurácii Azure Virtual Desktop sa vykresľovanie vo vzdialenej relácii a hardvérové kódovanie snímok nastavujú a overujú osobitne. Pozri: Konfigurácia a overenie GPU na vykresľovanie a kódovanie.

2. Podľa postupu pre daný produkt overíte skutočné využitie a pred nutnou zmenou aj po nej zmeriate tú istú operáciu.

   Ak je čas kompresie dlhý, skúmate využitie GPU na kódovanie. Ak aplikácia čaká vo vstupnom fronte, zmena nastavení kódovania mieri na iné miesto. Čitateľnosť textu a plynulosť videa si vyžadujú aj inú voľbu kvality obrazu, objemu komunikácie a záťaže spracovania. Pozri: Rozdiely podľa typu záťaže.

Môžete zaznamenať nielen to, či je GPU k dispozícii, ale aj to, či sa v problémovej fáze využíva a ako sa pri tej istej operácii zmenila záťaž a odozva. Zmeny, ktoré nepriniesli zlepšenie, po dohode so správcom vraciame späť.

flowchart TB
    accTitle: Overenie využitia GPU po fázach
    accDescr: Rozdelíme vykresľovanie v aplikácii na vzdialenom počítači, kódovanie RDP a lokálne dekódovanie; keďže ani s GPU ho nemusia využívať všetky fázy, overíme jeho využitie v podozrivej fáze.
    A["Vykresľovanie v aplikácii na vzdialenom PC"] --> B["Kódovanie RDP"]
    B --> C["Lokálne dekódovanie"]
    C -.- D["Overiť využitie GPU po fázach"]

Obrázok 18: Aj keď je GPU k dispozícii, nemusia ho využívať vykresľovanie, kódovanie aj dekódovanie.

Opätovné overenie a odovzdanie

Zlepšenie overujeme tak, že po zmene možno tú istú operáciu vykonať bez ťažkostí a zároveň zostáva zachovaná potrebná kvalita obrazu, zariadenia a pracovné funkcie. Porovnajte aj výsledok po návrate k pôvodným podmienkam. Ak ide len o chvíľkové zotavenie, príčinu nepovažujeme za potvrdenú a zaznamenáme aj čas špičky a súbežné procesy.

flowchart TB
    accTitle: Poradie overenia zlepšenia
    accDescr: Ukazuje, že po zmene overíme nielen to, či možno tú istú operáciu vykonať bez ťažkostí, ale aj zachovanie potrebnej kvality obrazu, zariadení a pracovných funkcií, porovnáme to s výsledkom po návrate k pôvodným podmienkam a podľa chvíľkového zotavenia príčinu nepotvrdzujeme.
    A["Po zmene skúsiť tú istú operáciu"] --> B["Overiť obraz, zariadenia a funkcie"]
    B --> C["Porovnať s výsledkom po vrátení"]
    C -.- D["Chvíľkové zotavenie nič nepotvrdzuje"]

Obrázok 19: Okrem výsledku tej istej operácie porovnáme aj potrebné funkcie a výsledok po vrátení späť.

Odovzdanie nevyriešeného problému

Užitočným výsledkom je aj to, že sa stav nezlepší, problém sa nereprodukuje alebo počítadlo nemožno použiť. Vykonané porovnania oddelíme od kontrol, ktoré sa vykonať nepodarilo, a pomocou nasledujúcej poznámky vec odovzdáme správcovi alebo vývojárovi. Zo zdieľaných protokolov odstráňte používateľské mená, cieľové počítače a ďalšie firemné informácie, ktoré na vyšetrovanie nie sú potrebné.

Čas výskytu príznaku a časové pásmo:
OS vzdialeného počítača, použitý klient a verzia:
Priame pripojenie / VPN / RD Gateway / Azure Virtual Desktop a pod.:
Pomalá operácia a aplikácia, odozva inej aplikácie v tej istej relácii:
Rozlíšenie na vzdialenej strane a počet monitorov:
Súbežne prebiehajúce kopírovanie, tlač a pod.:
Jediná zmenená podmienka a výsledok po vrátení späť:
Záťaž a počítadlá zistené na vzdialenom a lokálnom počítači:

Doplníme aj to, či sa podarilo overiť skutočné použitie TCP či UDP, položky, ktoré sa nepodarilo overiť napríklad pre nedostatočné oprávnenia, a nastavenia prijateľné z hľadiska prevádzky. Keď namiesto „pripojenie je pomalé“ napíšete „v Poznámkovom bloku sa píše normálne, ale pri posúvaní fotografií sa to zastaví“, ďalší riešiteľ môže skúmať za rovnakých podmienok.

Používateľ zaznamená operáciu, ktorá problém reprodukuje, a výsledky porovnania; správca porovná záznamy o ceste pripojenia, zdieľanom hostiteľovi a reláciách. Samotná skutočnosť, že sa čaká v RDP, neznamená, že aj spracovanie, ktoré čakanie spôsobuje, je RDP. Pozri: Rozdelenie úloh medzi hostiteľa a back-end.

Vývojár aplikácie zaznamenáva osobitne prijatie vstupnej udalosti, začiatok a koniec práce s databázou a súbormi a premietnutie do UI. Zvažuje aj návrh, ktorý nenecháva náročnú prácu blokovať vlákno UI. Protokol o dokončení spracovania na vzdialenom počítači však nezaznamenáva dokončenie zobrazenia na lokálnom počítači. Pozri: Oddelenie spracovania na zachovanie schopnosti UI reagovať.

Súvisiace články

• Ako rozumieť izolácii relácií vo Windows
• Ako bezpečne zistiť príčinu 100 % využitia disku vo Windows
• Prečo nekončí „zostáva 1 sekunda“?

Zdroje

Ide o primárne zdroje z Microsoft Learn. Odkazovaný obsah sme overili 17. septembra 2026. Pri čítaní rozlišujte podmienky platnosti pre jednotlivé produkty a skutočnosť, že nejde o merania vykonané v rámci tohto článku.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Rozlišovanie medzi RTT a oneskorením od zachytenia obrazovky na vzdialenom počítači po zobrazenie na lokálnom počítači. Samotná diagnostická funkcia je určená pre Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Vzťah medzi obsahom obrazovky, rozlíšením, aktualizáciou snímok, kompresiou, vyrovnávacou pamäťou a objemom komunikácie.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Spôsob kontroly vstupných a výstupných snímok, dôvodov vynechávania a času kódovania. Obsahuje opis starších konfigurácií, a preto číselné limity nezovšeobecňujeme na všetky RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Záťaž zdieľaného hostiteľa, komunikácia zo vzdialeného počítača do back-endu, vplyv presmerovania zariadení.
• Microsoft Learn, Threading model. Vlákno UI a Dispatcher vo WPF, oddelenie spracovania na zachovanie schopnosti reagovať.
• Microsoft Learn, mstsc. Zadanie šírky a výšky vzdialenej pracovnej plochy a viacerých monitorov.
• Microsoft Learn, Supported RDP properties. Rozdiel medzi rozlíšením pracovnej plochy, dynamickým rozlíšením a smart sizing. Podporovaných klientov a podmienky platnosti pre jednotlivé produkty overujeme.
• Microsoft Learn, ping. Kontrola odpovede pomocou ICMP Echo a parametre príkazu.
• Microsoft Learn, Test-NetConnection. Kontrola pripojenia TCP a význam výstupu.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Meraný úsek User Input Delay, podporované OS, inštancie a význam maximálnej hodnoty.
• Microsoft Learn, query session. Informácie o reláciách a oprávnenia potrebné na dopytovanie na iné relácie.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Výber TCP či UDP, ktoré RDP používa, a záložný prechod.
• Microsoft Learn, RDP Shortpath. Cesta UDP pre Azure Virtual Desktop a správanie, keď ju nemožno nadviazať.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Konfigurácia a overenie GPU osobitne pre vykresľovanie a kódovanie snímok.

Súvisiace články

Nedávne články s rovnakými štítkami. Prehĺbte si tému pomocou úzko súvisiacich textov.

Súvisiace témy

Toto sú stránky tém blízke téme tohto článku. Od článku môžete pokračovať k súvisiacim službám a ďalším článkom.

Služby, s ktorými táto téma súvisí

Tento článok nadväzuje na nasledujúce stránky služieb. Začnite tou, ktorá je vám najbližšia.

Často kladené otázky

Zhrnuli sme otázky k téme tohto článku, ktoré sa pri konzultáciách objavujú najčastejšie.

Prečo je vstup v RDP pomalý, keď test rýchlosti ukazuje stovky Mb/s?

Rýchlosť prenosu veľkých objemov dát a čas, kým sa na akciu vráti odozva, sú dve rozdielne veci. Podieľa sa na ňom odoslanie vstupu, spracovanie v aplikácii na vzdialenom počítači, kompresia obrazu, prenos a zobrazenie na lokálnom počítači. Komunikačná cesta k serveru testu rýchlosti a k cieľovému počítaču RDP sa navyše líši.

Písanie funguje normálne, ale posúvanie sa trhá. Je to problém pripojenia?

Nedá sa to zúžiť len na pripojenie. Keď pribudne aktualizácií obrazovky, nemusí stíhať vykresľovanie a kompresia na vzdialenom počítači, komunikácia alebo dekódovanie a zobrazenie na lokálnom počítači. Rozlíšenie alebo počet monitorov na vzdialenej strane meníme po jednom, porovnávame a v prípade potreby skúmame počítadlá súvisiace s vykresľovaním.

Keď je ping rýchly, je komunikácia RDP v poriadku?

Len podľa toho sa to posúdiť nedá. Ping meria odpoveď na ICMP, nie prenos obrazovky RDP ani spracovanie v aplikácii. V konfiguráciách s RD Gateway a podobne sa navyše nemusí zhodovať ani cesta. Aj keď odpoveď nepríde, rozlišujte medzi blokovaním ICMP a nedostupnosťou samotného RDP.

Je User Input Delay čas od stlačenia klávesu po zobrazenie znaku?

Nie je. Je to počítadlo, ktoré meria čas čakania od zaradenia vstupu do frontu na vzdialenom počítači po jeho vyzdvihnutie procesom. Nejde o vnímané oneskorenie, ktoré by zahŕňalo komunikáciu tam a späť, spracovanie v aplikácii po vyzdvihnutí vstupu a kompresiu, dekódovanie a zobrazenie obrazu.

Mám pri pomalom RDP vypnúť UDP?

Plošne to neodporúčame. Najprv overíme skutočný spôsob pripojenia, cestu a uplatňované politiky. Môže sa stať, že UDP nemožno použiť a spojenie už prešlo na TCP, a obmedzenie len na TCP preto nemusí vždy priniesť zrýchlenie. So súhlasom správcu porovnávame pri rovnakých podmienkach a nepotrebné zmeny vraciame späť.

Profil autora

Profilová stránka autora článku.

Go Komura

Zástupca spoločnosti KomuraSoft LLC

Zameriava sa najmä na vývoj softvéru pre Windows, technické konzultácie a vyšetrovanie chýb; má silné stránky v zákazkách, kde zostávajú existujúce aktíva, a pri vyšetrovaní porúch, ktorých príčina nie je dobre viditeľná.