Miért lassú az RDP, ha gyors a hálózat? – A bevitel, a megjelenítés és a kommunikáció külön vizsgálata

A sebességmérés több száz Mbps-ot mutat, a távoli asztalon mégis kis késéssel jelennek meg a karakterek. Egy sok fényképet tartalmazó oldal görgetésekor megakad a kép. Egy üzleti alkalmazás csak a keresés indításakor áll meg néhány másodpercre. Hol érdemes elkezdeni az ilyen, „gyors a hálózat, mégis lassú az RDP” állapot vizsgálatát?

Az RDP válaszkészségét nem egyedül a hálózat átviteli sebessége határozza meg. Gyors sebességmérés mellett is előfordulhat várakozás a kommunikáció oda-vissza útján, a távoli gépen futó alkalmazás bemeneti várakozásánál, a képernyő kódolásánál vagy a helyi dekódolásnál és megjelenítésnél. Először különítse el, hogy „melyik művelet lassú”, majd ugyanazt a műveletet egyszerre csak egy feltételt módosítva hasonlítsa össze. Az összehasonlítással és a méréssel szűkítse le a vizsgálandó területet, az UDP- és GPU-beállításokat pedig ennek eredményéhez igazítva válassza meg. Lásd: A kapcsolat minőségének mérési szakaszai, A munkamenetgazda teljesítményét befolyásoló tényezők.

Ugyanakkor amikor leszűkítettük a vizsgálandó területet, a kiváltó ok még nincs megállapítva. Ha a felbontás csökkentése javít is a helyzeten, nem jelentjük ki, hogy „a hálózat volt az ok”, hiszen ilyenkor nemcsak a kommunikáció, hanem a két végpont képfeldolgozása is megváltozik. Az eredményeket úgy rögzítjük, hogy elkülönítjük a mért és a nem mért szakaszokat.

Ez a cikk a kapcsolódás utáni bevitel, görgetés és alkalmazásválasz behatárolásával foglalkozik. Hasonló tünetek mellett sem biztos, hogy egyetlen oka van a problémának. Ha „sokáig tart, mire megjelenik a bejelentkezési képernyő”, vagy „csak a hitelesítésnél akad el”, azt külön problémaként kezeljük, amelyet a kapcsolat létrehozásának és a hitelesítésnek a naplóiból kell vizsgálni.

A cikk elsősorban azoknak a felhasználóknak és rendszergazdáknak szól, akik a Windows „Távoli asztali kapcsolat” alkalmazásával (mstsc) Windows 11-re vagy Windows Serverre csatlakoznak. A parancspéldák a Windows PowerShell 5.1-hez készültek. Feltételezzük, hogy egy már létrejött munkamenetben ugyanaz a művelet reprodukálható.

A közvetlen kapcsolat, a VPN, az RD Gateway és az Azure Virtual Desktop esetében eltér az útvonal, az elérhető diagnosztikai információ és az is, hogy a beállítások hol érvényesek. A TCP 3389-es port ellenőrzésére adott példa csak a szabványos portot használó RDP-gazdagépekhez való, engedélyezett közvetlen kapcsolatra vonatkozik. Az Azure Virtual Desktophoz készült dokumentációban szereplő diagnosztikai funkciókat és GPU-beállításokat nem alkalmazzuk egy az egyben az általános vállalati számítógépekre.

Céges eszközön a rendszergazda által engedélyezett keretek között végezze a vizsgálatot. Megosztott gazdagépen azonosítsa a saját munkamenetét és a vizsgált folyamatot, ha pedig más felhasználók naplóira is szükség van, forduljon a rendszergazdához. A teljesítményszámlálók elérhetőségét, megjelenített nevét és a szükséges jogosultságokat környezetenként ellenőrizzük.

Az itt bemutatott ellenőrzési módszerek hivatalos dokumentáción alapulnak. Nem olyan mérési beszámolók, amelyekben egy adott eszközön reprodukáltunk és megoldottunk egy hibát. A számpéldákat szemléltető feltevésként, egyértelműen elkülönítve mutatjuk be.

A működést a következő, „Átviteli sebesség és körülfordulási idő” című szakasztól kezdve sorban olvashatja. Ha a tünetből indulna ki, ugorjon „Az első összehasonlítás a tünet alapján” című szakaszra. A konkrét lépések „A feltételek egyenkénti összehasonlítása” és „A várakozás helyének mérése” című szakaszokban találhatók.

Az ábrán a folytonos vonal mindig fennálló kapcsolatot, a szaggatott vonal feltételes kapcsolatot jelöl (a feltételeket a részletoldal kapcsolatonként ismerteti). A kapcsolatok teljes listája (összesen 7, bizonyítékokkal és megbízhatósági szinttel) és a fő fogalmak meghatározása a tudástérkép részletoldalán található (japánul). Adatok: JSON-LD / Turtle

Átviteli sebesség és körülfordulási idő

Az RDP (Remote Desktop Protocol) olyan protokoll, amely a helyi eszköz és a távoli gép között a bevitelt, a képernyőinformációt és egyéb adatokat továbbítja. Nemcsak a képernyőt és a bevitelt kezeli, hanem az eszközátirányítás, a nyomtatás és más funkciók adatait is. Lásd: Az RDP által továbbított információk.

A hálózat átviteli sebessége azt fejezi ki, hogy másodpercenként mennyi adatot tud szállítani. A sebességmérés „500 Mbps” értéke erre a mennyiségre vonatkozik. Nem azt mutatja meg, mennyi idő telik el egy művelettől a válasz megérkezéséig. Lásd: Az RDP sávszélesség-igénye.

flowchart TB
    accTitle: Mit fejez ki a sebességmérés eredménye
    accDescr: Az ábra azt mutatja, hogy a sebességmérés 500 Mbps-os értéke a másodpercenként szállítható adatmennyiséget jelzi, és ez más érték, mint a művelettől a válasz megérkezéséig eltelt idő.
    A["Sebességmérés: 500 Mbps"] --> B["Másodpercenként szállított adat"]
    B -.->|"Más érték"| C["A válasz megérkezésének ideje"]

1. ábra: A sebességmérés eredménye a szállítható mennyiséget mutatja, nem a válasz megérkezéséig eltelt időt.

A körülfordulási idő (RTT) az az idő, amíg a kommunikáció eljut a másik félhez, és onnan visszaér. Az átviteli sebesség növelése és a körülfordulási idő csökkentése között hasonló a különbség, mint aközött, hogy egy úton több forgalmi sávot nyitunk, vagy hogy lerövidítjük a célállomásig tartó távolságot. Hiába nő a nagy mennyiségű fájl szállításának képessége, ha a körülfordulási idő változatlan, a műveletekre adott válaszra továbbra is várni kell. Lásd: Az RTT és a képernyő-megjelenítés késése.

flowchart TB
    accTitle: Az átviteli sebesség és a körülfordulási idő útmetaforával
    accDescr: Az ábra az átviteli sebesség növelését az út forgalmi sávjainak bővítéséhez, a körülfordulási idő csökkentését a célállomásig tartó távolság rövidítéséhez hasonlítja.
    A["Átviteli sebesség növelése"] -->|"Ha út volna"| B["Több forgalmi sáv"]
    B ~~~ C["Körülfordulási idő csökkentése"]
    C -->|"Ha út volna"| D["Rövidebb távolság"]

2. ábra: Több forgalmi sávtól nem lesz rövidebb a célállomásig tartó távolság.

Amíg egy karakter eredménye visszaér

Vegyük azt a helyzetet, amikor egy karaktert gépelünk a távoli Jegyzettömbbe. A Jegyzettömb a távoli gépen fut. Ha szemléltetésként feltételezzük, hogy a művelet 50 milliszekundum alatt ér oda, az eredményül kapott képernyőinformáció pedig 50 milliszekundum alatt ér vissza, akkor a kommunikáció összesen 100 milliszekundumot, vagyis 0,1 másodpercet vesz igénybe. A két végpont feldolgozási idejét ebből a példából kihagytuk.

flowchart TB
    accTitle: Példa a kommunikációs időre, amíg egy karakter eredménye visszaér
    accDescr: Szemléltető példa, amelyben az oda- és a visszautat egyaránt 50 milliszekundumnak feltételezzük. A két végpont feldolgozási idejét nem tartalmazza, és nem a billentyűnkénti csomagok számát ábrázolja.
    A["Helyben beírunk egy karaktert"] -->|"Oda: 50 ms"| B["A távoli gép fogadja"]
    B --> C["Elküldi a frissített képet"]
    C -->|"Vissza: 50 ms"| D["Megérkezik az eredmény"]

3. ábra: Ha feltételezzük, hogy az odaút 50, a visszaút szintén 50 milliszekundum, pusztán a kommunikáció 0,1 másodpercet vesz igénybe. Ez nem mért érték.

Ha a hálózat szállítókapacitása nő, de a körülfordulási idő nem változik, ez a 0,1 másodperc megmarad. A 3. ábra a folyamat megértését segítő elvi ábra. Nem azt jelenti, hogy minden billentyűleütéshez egy önálló oda-vissza csomagváltás tartozik. A sebességmérés szervere és az RDP-vel elért gép felé az útvonal is eltér, ezért a VPN-t, az átjárót, a távoli oldal feltöltési irányát és az útközbeni torlódást is figyelembe kell venni. Lásd: Az RTT értelmezése, A hálózat és a gazdagép teljesítménye.

A képernyő előállítása és eljuttatása

Az itt használt értelemben a válaszkésés az a várakozás, amely egy helyi művelettől addig tart, amíg az eredmény láthatóvá válik. Ebben nemcsak az RTT, hanem az alkalmazás feldolgozása, valamint a képernyő előállítása és eljuttatása is szerepet játszik. Megkülönböztetjük attól a késéstől is, amely csak a képernyőátviteli szakaszra vonatkozik. Lásd: A mérési szakasz a képernyő rögzítésétől a megjelenítésig.

Amikor a bevitel eljut a helyi eszközről a távoli gépre, ott az alkalmazás feldolgozza és frissíti a képernyőt, a kódolt képernyőinformáció a hálózaton keresztül utazik, majd a helyi eszköz dekódolja és megjeleníti. A kommunikáció előtt és után is vannak feladatok, amelyeket két különböző számítógép végez. Lásd: A feldolgozás a képernyő rögzítésétől a megjelenítésig.

flowchart TB
    accTitle: A hálózat előtt és után is van képfeldolgozás
    accDescr: A folyamat, amelyben a helyi bevitel eljut a távoli gépre, ott az alkalmazás feldolgozza, a képernyőt előállítja és tömöríti, majd a hálózaton szállított képernyőinformációt a helyi eszköz megjeleníthető formára alakítja vissza és megjeleníti.
    I["Helyi: művelet bevitele"] --> J["Hálózat: a bevitel szállítása"]
    J --> K["Távoli: az alkalmazás feldolgoz"]
    K --> A["Távoli: kép előállítása, tömörítése"]
    A --> B["Hálózat: a képadatok szállítása"]
    B --> C["Helyi: megjeleníthető formára"]
    C --> D["Megjelenítés a helyi képernyőn"]

4. ábra: A távoli gép feldolgoz és tömörít, a hálózat szállít, a helyi eszköz visszaalakít a megjelenítéshez. Mindegyik más helyen végzett munka.

Ebben a cikkben a kódolás az a feldolgozás, amely a távoli gépen a képernyőt könnyen továbbítható formára alakítja és tömöríti. A hálózati átviteltől függetlenül ez is feldolgozási időt igényel a távoli gépen. Lásd: Kódolási idő a távoli gépen.

Ebben a cikkben a dekódolás az a feldolgozás, amely a megérkezett képernyőinformációt a helyi eszközön megjeleníthető formára alakítja vissza. Megkülönböztetjük a titkosítás feloldását jelentő visszafejtéstől. Lásd: Helyi dekódolási és megjelenítési idő.

Ha a távoli gépen sokáig tart a tömörítés, akkor szabad hálózati kapacitás mellett is várni kell a küldés előkészítésére. Ha az információ már megérkezett, de a helyi dekódolás vagy megjelenítés nem tud lépést tartani, a frissítés késik. Nem feltétlenül igaz, hogy „a céges gép nagy teljesítményű, így a helyi eszköz bármilyen lehet”. A hálózat tartaléka és a két végpont feldolgozási tartaléka két külön dolog. Lásd: A képfeldolgozás teljesítményszámlálói.

flowchart TB
    accTitle: Késés, amikor a két végpont feldolgozása lemarad
    accDescr: Az ábra azt mutatja, hogy ha a távoli gépen sokáig tart a tömörítés, szabad hálózat mellett is várni kell a küldés előkészítésére, ha pedig a helyi dekódolás vagy megjelenítés nem tart lépést, a frissítés a megérkezett információ ellenére is késik.
    A["Lassú tömörítés a távoli gépen"] --> B["Szabad hálózat mellett is vár"]
    B ~~~ C["A helyi dekódolás lemarad"]
    C --> D["Megérkezett, mégis késik"]

5. ábra: Hiába van tartalék a hálózatban, ha a két végpont feldolgozása lemarad, a képernyő frissítése késik.

A gépelés és a görgetés különbsége

Ha a Jegyzettömbben egy karaktert hozzáadunk, a képernyőnek csak egy kis része változik. Egy sok fényképet tartalmazó oldal görgetésekor viszont nagy területen változik egymás után a tartalom. Az RDP a megváltozott részek továbbításával, valamint a tartalomhoz illő tömörítéssel és gyorsítótárazással csökkenti a forgalmat. Nem küldi el minden alkalommal tömörítetlenül a teljes képernyőt. A munka mennyisége a képernyő tartalmától és a frissítés gyakoriságától függ. Lásd: A képernyő tartalma és a sávszélesség kapcsolata.

flowchart TB
    accTitle: A képernyőmunka mennyisége gépeléskor és görgetéskor
    accDescr: Egy kis karakterváltozás és egy nagy terület folyamatos frissítése eltérő jellegű munkát jelent a kép előállítása és továbbítása szempontjából.
    A{"Képernyőváltozás"} -->|"Egy karakter hozzáadása"| B["Kis terület"]
    A -->|"Görgetés"| D["Nagy terület folyamatosan"]
    B --> E["Tömörítés, átvitel a változás szerint"]
    D --> E

6. ábra: Ugyanazon a kapcsolaton is más a munka mennyisége, ha egy karaktert adunk hozzá, és ha nagy terület mozog folyamatosan.

Egy statikus dokumentum könnyű lehet, görgetés közben viszont elfogyhat a képernyőátvitel tartaléka. Ha a távoli oldal felbontását vagy a monitorok számát növeljük, a feldolgozandó képernyő is nagyobb lesz. A felbontás csökkentésével végzett összehasonlítás kísérlet arra, hogy kiderüljön: visszatér-e a gördülékenység, ha csökken a kép előállításának és továbbításának munkája. Nem olyan számítás, amely pusztán a képpontok számából határozza meg a forgalmat. Lásd: A felbontás, a képernyőfrissítés és a tömörítés hatása.

Várakozás az alkalmazásra

Ha egy üzleti alkalmazásban csak a keresés áll meg néhány másodpercre, ugyanabban a munkamenetben a Jegyzettömbbe viszont gond nélkül lehet gépelni, ellenőrizze, mire vár az adott alkalmazás. Előfordulhat, hogy a távoli gépen futó alkalmazás egy további adatbázisnak küld lekérdezést, vagy egy megosztott mappából olvas fájlt, és ennek válaszára vár. Ez a helyi eszközt és a távoli gépet összekötő RDP-kommunikációtól független útvonal. Lásd: Kommunikáció a távoli géptől a háttérrendszerek felé.

flowchart TB
    accTitle: Az RDP mögött is vannak kommunikációs partnerek
    accDescr: Az ábra azt az esetet mutatja, amikor a helyi eszközt és a távoli gépet összekötő kommunikációtól függetlenül a távoli gépen futó alkalmazás egy üzleti kiszolgáló válaszára vár.
    A["Helyi eszköz"] -->|"RDP"| B["Üzleti alkalmazás a távoli gépen"]
    B -->|"Keresés, fájlkérés"| C["Adatbázis, megosztott mappa"]
    C -->|"A várt válasz"| B

7. ábra: Az RDP mögötti üzleti alkalmazás maga is várhat egy másik kiszolgáló válaszára.

Ha a képernyőt és a bevitelt kezelő feldolgozás hosszú munkát végez, a következő bevitel és a képernyőfrissítés késik. A WPF-ben például romlik a válaszkészség, ha a UI-szálat hosszú ideig lefoglalja egy feladat. Pusztán az alacsony teljes CPU-kihasználtság alapján nem zárható ki, hogy egy adott UI-szál várakozik. Lásd: A Dispatcher és a UI-szál.

flowchart TB
    accTitle: Elakad a képernyőt és a bevitelt kezelő feldolgozás
    accDescr: Az ábra azt mutatja, hogy ha a képernyőt és a bevitelt kezelő feldolgozás hosszú munkát végez, a következő bevitel és a képernyőfrissítés késik, és ezt a várakozást az alacsony teljes CPU-kihasználtság önmagában nem zárja ki.
    A["A képet és a bevitelt kezelő rész"] --> B["Hosszú munkát végez"]
    B --> C["Késik a bevitel és a frissítés"]
    C -.- D["Alacsony CPU mellett sem kizárt"]

8. ábra: A UI-szál várakozása nem zárható ki pusztán a teljes CPU-kihasználtság alapján.

Az első összehasonlítás a tünet alapján

A szállítható mennyiség, a válaszra várakozás ideje, valamint a kép előállításának és megjelenítésének ideje három külön dolog. Ha ezt a megkülönböztetést megtartjuk, nem intézzük el a „lassú az RDP” jelenséget egyetlen okkal, és abból a műveletből indulhatunk ki, amely éppen lassú.

flowchart TB
    accTitle: Szétválasztás a vizsgálat előtt
    accDescr: Az ábra azt mutatja, hogy a „lassú az RDP” jelenséget nem intézzük el egyetlen okkal, hanem szétválasztjuk a szállítható mennyiséget, a válaszra várakozás idejét, valamint a kép előállításának és megjelenítésének idejét, és az éppen lassú műveletből indulunk ki.
    A["„Lassú az RDP”"] --> S
    subgraph S["Külön-külön vizsgáljuk"]
    direction TB
    B["Szállítható mennyiség"] ~~~ C["Várakozás a válaszra"]
    C ~~~ D["Kép előállítása, megjelenítése"]
    end
    S --> E["A lassú műveletből indulunk"]

9. ábra: Ha szétválasztjuk a szállítható mennyiséget, a válaszra várakozás idejét, valamint a kép előállításának és megjelenítésének idejét, az éppen lassú műveletből indulhatunk ki.

A behatárolás célja, hogy leszűkítsük azt a helyet, ahol a lassúságot vizsgáljuk. Nem cél, hogy a beállítások tömeges módosításával véletlenül gyorsabbá tegyük a rendszert. Ha kihasználjuk az olyan különbségeket, mint „a Jegyzettömb működik, de a keresés megáll” vagy „a gépelés normális, de a görgetés lassú”, már a hálózati beállítások módosítása előtt kiválaszthatjuk, honnan induljon a vizsgálat.

Az alábbi táblázat a vizsgálat kiindulópontja. Nem az ok megállapítására szolgál. Először ugyanabban a munkamenetben hasonlítsa össze a műveleteket, és csak utána változtasson a szükséges eszközön, útvonalon vagy megjelenítési feltételen.

Több alkalmazásban késnek a karakterek

Ha ugyanabban a munkamenetben több alkalmazásban is késve jelennek meg a karakterek, ugyanazt a műveletet egy másik eszközről vagy egy másik engedélyezett útvonalon is hasonlítsa össze. Vesse össze a körülfordulási időt, a távoli gép bemeneti várakozását és teljes terhelését, és ne egyetlen érték alapján döntsön az okról.

Csak a görgetés akadozik

Ha a gépelés normális is, egy sok fényképet tartalmazó oldal görgetésekor nagy területen folyik a képernyőfrissítés. Egyenként változtassa meg a távoli oldal felbontását vagy a monitorok számát, és ugyanazon az oldalon hasonlítson össze. Ha a helyzet javul, a következő vizsgálandó terület a tömörítés a távoli gépen, a képernyőátvitel és a helyi dekódolás. A felbontás alapján önmagában nem derül ki, hogy e három közül melyik az ok. Lásd: A képernyő tartalma és a felbontás okozta terhelés.

Csak egy alkalmazás fagy le

Ha csak az az üzleti alkalmazás áll meg, amelyben a keresést elindította, nézze meg, hogy a Jegyzettömb vagy más program ugyanabban a munkamenetben válaszol-e. Ha a többi alkalmazás működik, először a vizsgált alkalmazás feldolgozását, a lemezt, valamint az adatbázis és a megosztott mappa felé irányuló kéréseket vizsgálja meg. Az, hogy RDP-n keresztül dolgozunk, és az, hogy az RDP-kommunikáció okozza a várakozást, két különböző dolog. Lásd: Az alkalmazás és a háttérrendszer teljesítménytényezői.

Csak csúcsidőben lassú mindenki

Ha ugyanabban az időszakban több felhasználónál is lelassul a rendszer, kérdezze meg a rendszergazdától a többi munkamenet állapotát. A megosztott gazdagép CPU-, memória- és tárolóterhelését, valamint a megosztott hálózat terhelését a tünet időpontjához igazítva vesse össze. Ne férjen hozzá engedély nélkül más felhasználók naplóihoz vagy folyamataihoz, és ne állítsa le a feladataikat. Lásd: A megosztott gazdagép erőforrásai és a felhasználók száma.

Lassulás másolás vagy nyomtatás közben

Ha a saját másolásának vagy nyomtatásának kezdete egybeesik a problémával, csak azokat az átviteleket szüneteltesse az összehasonlításhoz, amelyek leállítására engedélye van. Jegyezze fel, hogy a leállítás után visszaáll-e a normál működés, és hogy a folytatáskor újra lelassul-e, majd vizsgálja meg a képernyőn kívüli átvitelekkel és az eszközátirányítással való versengést. Ne végezzen olyan összehasonlítást, amely a munkához szükséges eszközöket egyszerre tiltja le. Lásd: Az eszközátirányítás hatása.

A feltételek egyenkénti összehasonlítása

Nem kell minden beállítást sorra módosítani. Először hozzon létre egy összehasonlítási alapot, és csak a tünetnek megfelelő ellenőrzéseket válassza ki. Beállítás módosítása vagy újracsatlakozás előtt mentse a munkáját, és jegyezze fel az eredeti értékeket és a visszaállítás módját. Ha nincs meg a szükséges jogosultság vagy funkció, ne erőltesse az engedélyezést, hanem adja át a vizsgálatot a rendszergazdának.

A helyi és az RDP-n keresztüli használat nem feltétlenül azonos feltételek mellett zajlik. Hasznos támpont, ha a távoli gép fizikai képernyőjén gyors a működés, de a munkamenet és a rajzolási feltételek eltérhetnek. Használjon azonos felhasználót, adatokat és alkalmazásállapotot, és ne szűkítse le az okot a hálózatra pusztán azért, mert „a fizikai képernyőn gyors”.

Ugyanannak a műveletnek az összehasonlítása

Készítse elő ugyanazt a felhasználót, ugyanazokat az adatokat és ugyanazt a műveletet. Megosztott gazdagépen ellenőrizze a saját munkamenetét, és ne állítsa le más felhasználók alkalmazásait vagy folyamatait. Másik eszközt vagy másik útvonalat is csak a rendszergazda által engedélyezett keretek között használjon.

1. Az eredeti beállításokkal reprodukálja a lassú műveletet, és jegyezze fel az időpontot és a tünetet.

   A problémás alkalmazással azonos távoli munkamenetben nagyjából ugyanannyi szöveget gépeljen be a Jegyzettömbbe. Különítse el, hogy csak egy alkalmazásról vagy a teljes munkamenetről van-e szó.

2. Ugyanabban az időszakban ellenőrizze a távoli gép és a helyi eszköz terhelését.

   A Feladatkezelőben a távoli gépen a vizsgált alkalmazás CPU-, memória- és lemezhasználatát, a helyi eszközön pedig az RDP-ügyfél terhelését figyelje. Ne csak a teljes CPU-értéket nézze, hanem a vizsgált folyamatot is. Lásd: Mit kell vizsgálni a terhelésnél.

3. A másik eszköz, a másik engedélyezett útvonal és a megjelenítési feltételek közül csak egyet változtasson meg, és ismételje meg ugyanazt a műveletet.

   Ha az összehasonlítás során a távoli gép vagy az alkalmazás állapota is megváltozik, ezt az eltérést is jegyezze fel. Több feltétel egyidejű változásának eredményét ne tekintse egyetlen feltétel hatásának.

4. Állítsa vissza az eredeti feltételeket, és ellenőrizze újra ugyanazt a műveletet.

   Ha a visszaállítás után is gyors marad, átmeneti terhelésváltozás vagy más ok is szóba jöhet. Ne vegye biztosra, hogy a módosítás hozta a javulást, hanem jegyezze fel, milyen feltételek mellett jelentkezik a tünet.

Ha megvan az eredeti, a módosítás utáni és a visszaállított állapot eredménye, összehasonlíthatja, melyik feltétel melyik tünettel jár együtt. A javulást hozó feltétel a vizsgálat nyoma, de önmagában nem bizonyítja a kiváltó okot.

flowchart TB
    accTitle: Az egyszerre módosított feltételek korlátozása
    accDescr: A folyamat, amelyben rögzítjük az eredeti állapotban reprodukálódó műveletet, csak egy feltételt módosítva összehasonlítunk, majd a visszaállítás eredményét is ellenőrizzük.
    A["Ugyanaz a művelet eredetiben"] --> B["Csak egy feltétel módosítása"]
    B --> C["Ugyanaz a művelet ismét"]
    C --> D["Visszaállítás, újraellenőrzés"]
    D --> E["A javító feltétel rögzítése"]

10. ábra: Az eredeti, a módosított és a visszaállított állapotban ugyanazt a műveletet megismételve feljegyezzük, melyik feltétel változott.

A távoli oldal felbontásának összehasonlítása

Akkor végezze el ezt az összehasonlítást, ha a görgetéshez hasonló képernyőfrissítések nehézkesek. Jegyezze fel a módosítás előtti felbontást és monitorszámot, mentse a munkáját, majd csatlakozzon újra. Ne használjon tartósan olyan beállítást, amely rontja a munkához szükséges képernyőterületet vagy a szöveg olvashatóságát.

1. Csak a monitorok számát vagy csak a felbontást változtassa meg.

   Az mstsc esetében a csatlakozás előtti „Megjelenítés” lap beállításaival vagy a szélesség és a magasság megadásával hasonlíthat össze. Lásd: Képernyőbeállítások az mstsc-ben.

2. Ellenőrizze, hogy a távoli asztal tényleges mérete megváltozott-e, majd görgesse ugyanazt az oldalt.

   Ha csak a helyi ablakot kicsinyíti, előfordulhat, hogy egy nagy asztal kicsinyített képét látja. Különítse el a dinamikus felbontást és a smart sizing funkciót, és ellenőrizze, milyen feltételekkel támogatja ezeket a használt ügyfél. Lásd: Az asztal felbontása és a megjelenítési méretezés.

3. Állítsa vissza az eredeti beállítást, ismételje meg ugyanazt a műveletet, és hasonlítsa össze a két végpont terhelését és a kép mozgását.

   Ha egyszerre állított be alacsony felbontást és egyetlen monitort, az összehasonlítás csak durva képet ad. Ha javulást tapasztal, egyenként állítsa vissza a beállításokat, és különítse el a hatásokat.

Ha a helyzet javul, a nyom a képfeldolgozás és a képernyőátvitel tartományába mutat. A 3840×2160 négyszer annyi képpontot jelent, mint az 1920×1080, a forgalom mégsem lesz mindig négyszeres. Ez a változó részektől és a tömörítéstől függ, a felbontás módosítása pedig a két végpont feldolgozására is hatással van. Lásd: A képpontszám és a forgalom kapcsolata, A képfeldolgozás ellenőrzése.

flowchart TB
    accTitle: Mit árul el a felbontás csökkentésével végzett összehasonlítás
    accDescr: A távoli oldal felbontásának csökkentése a képfeldolgozás és az átvitel terhelését egyaránt megváltoztathatja, ezért a javulás alapján önmagában nem szűkíthető le az ok a hálózatra.
    A["A távoli felbontás csökkentése"] --> S
    subgraph S["Változó feldolgozás"]
    direction TB
    B["Képfeldolgozás a távoli gépen"] ~~~ C["Küldött adatmennyiség"]
    C ~~~ D["Megjelenítés a helyi eszközön"]
    end

11. ábra: A felbontás módosítása olyan összehasonlítás, amely nemcsak a hálózatra, hanem a távoli gép és a helyi eszköz képfeldolgozására is hat.

A másolás és a nyomtatás összevetése a tünettel

Csak olyan folyamatot szüneteltessen, amelynek leállítására engedélye van, például egy saját maga által indított átvitelt. Ne állítsa le a vállalati biztonsági mentési és biztonsági folyamatokat, sem más felhasználók feladatait. Ne tiltsa le egyszerre a munkához szükséges hang- és beviteli eszközök átirányítását.

1. A másolás, a felhőszinkronizálás vagy a nyomtatás megkezdése előtt és közben jegyezze fel ugyanazt a műveletet és a terhelést.

   Az RDP-n a képernyőn kívül meghajtók, nyomtatók és más eszközök adatai is áramlanak. A helyi eszközök távoli gépen való használatát lehetővé tevő átirányítás használat közben növelheti a kommunikációs és feldolgozási terhelést. Lásd: Az eszközátirányítás hatása.

2. Az engedélyezett keretek között szüneteltesse a kérdéses átvitelt, és ellenőrizze újra ugyanazt a műveletet.

   Ha a folytatás után is össze tud hasonlítani, a folytatás utáni tünetet is jegyezze fel. Ha a nem szükséges eszközátirányítást próbálja ki, azt is egyenként módosítsa, és gondoskodjon róla, hogy vissza tudja állítani az eredeti beállítást.

Megítélheti, hogy az átvitel megkezdése és a probléma, illetve a szüneteltetés és a helyreállás egybeesik-e. Ha látható az összefüggés, vesse össze a képernyőn kívüli átviteleket és a megosztott erőforrások terhelését a rendszergazda naplóival.

flowchart TB
    accTitle: A probléma előtti és utáni állapot egy idővonalon
    accDescr: Az átvitel előtt, közben és a leállítás után ugyanazt a műveletet és terhelést rögzítjük, és összehasonlítjuk a probléma és a munka kapcsolatát.
    A["Művelet, terhelés átvitel előtt"] --> B["Művelet, terhelés átvitel közben"]
    B --> C["Művelet, terhelés leállítás után"]
    C --> D["Egybeesik a probléma és a javulás?"]

12. ábra: Megnézzük, hogyan változik ugyanannak a műveletnek a lassúsága és a terhelés az átvitel előtt, közben és a leállítás után.

A várakozás helyének mérése

A helyi eszközről a kommunikáció oda-vissza útját és a TCP-kapcsolatot, a távoli gépen pedig a bemeneti sorban töltött várakozást és a képernyőfrissítést vizsgáljuk. Mivel minden érték csak egy korlátozott szakaszt mér, az eredményeket „A mérési eredmények érvényességi köre” táblázatával összevetve értelmezzük.

Az ICMP és a TCP-kapcsolat ellenőrzése

A végrehajtás helye a helyi Windows-eszköz. Csak azokra a konfigurációkra vonatkozik, amelyekben vállalati LAN-on vagy engedélyezett VPN-en keresztül közvetlenül csatlakozik egy szabványos TCP 3389-es portot használó RDP-gazdagéphez. RD Gatewayen vagy Azure Virtual Desktopon keresztüli, illetve egyedi portot használó konfigurációk esetén az ellenőrzés célpontját a rendszergazdával egyeztesse. Ne tegyen közzé portot, és ne módosítsa a tűzfalat.

1. Adja meg az engedélyezett célgépet, és jegyezze fel az ICMP-válasz és a TCP-kapcsolat eredményét.

   $target = Read-Host 'A vizsgálatra engedélyezett RDP-gazdagép neve vagy IP-címe'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Adja meg a célgépet.'
   }
       
   # Az ICMP válaszidejét többször megnézzük. A sikertelenség önmagában nem jelenti, hogy az RDP elérhetetlen.
   ping.exe -n 20 $target
       
   # Csak a szabványos TCP 3389-es portra közvetlenül csatlakozó konfigurációkra érvényes ellenőrzés.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. A lassú időszak és a normál időszak eredményeit vesse össze a tünet időpontjával és a tényleges kapcsolati útvonallal.

   A 20 kérésből álló ping rövid megfigyelés. Jegyezze fel az értékek ingadozását és a válasz elmaradását, de az ICMP blokkolva is lehet. A szakaszos megakadásokat ne zárja ki pusztán az átlagérték alapján, hanem használja a kapcsolati információkat és a rendszergazda hálózati naplóit. Lásd: Mit mér a ping.

A TcpTestSucceeded: True azt jelenti, hogy a megadott portra sikerült TCP-kapcsolatot létesíteni. A sávszélességet, az UDP-t, a hitelesítés utáni működést és a kép gördülékenységét nem méri. A Test-NetConnection parancsnak nincs olyan -UDP kapcsolója, amely az UDP-t vizsgálná. Lásd: A Test-NetConnection szintaxisa és eredményei.

Az értékelésnél szem előtt tartjuk az útvonal és a szolgáltatás eltéréseit. RD Gateway és hasonló megoldások esetén előfordulhat, hogy a gazdagép felé irányuló ICMP vagy közvetlen TCP-kapcsolat útvonala nem egyezik meg a tényleges RDP-útvonallal. Az Azure Virtual Desktopban kapcsolatonként elérhető az RTT és a becsült sávszélesség, ez a diagnosztikai funkció azonban ehhez a szolgáltatáshoz készült. A rövid megakadásokat nem zárjuk ki pusztán az átlagérték alapján. Lásd: Az Azure Virtual Desktop kapcsolatminőségi naplói.

flowchart TB
    accTitle: Az ellenőrzött útvonal és a tényleges RDP-útvonal
    accDescr: RD Gatewayt vagy hasonló megoldást használó konfigurációkban előfordulhat, hogy a helyi eszközről a gazdagép felé irányuló ICMP vagy közvetlen TCP-kapcsolat útvonala nem egyezik meg a tényleges RDP-útvonallal.
    A["Helyi eszköz"] -->|"ICMP, közvetlen TCP"| C["RDP-gazdagép"]
    A -->|"Tényleges RDP"| B["RD Gateway vagy hasonló"]
    B --> C

13. ábra: A gazdagép felé irányuló ICMP vagy közvetlen TCP-kapcsolat útvonala eltérhet a tényleges RDP-útvonaltól.

A bemeneti sorban töltött várakozás mérése

A User Input Delay azt a várakozást méri, amely a távoli gépen attól kezdve telik el, hogy a bevitel bekerül a sorba, addig, amíg egy folyamat kiveszi onnan. Ez nem a billentyű lenyomásától a karakter megjelenéséig eltelt teljes idő. Lásd: A User Input Delay definíciója.

A vizsgálatot a távoli gép távoli munkamenetén belül végezze. A Microsoft szerinti támogatási feltétel a Windows 10 1809-es vagy újabb verziója, illetve a Windows Server 2019 vagy újabb. Ezeken nincs szükség a funkció engedélyezéséhez beállításjegyzék-bejegyzés hozzáadására. Ellenőrizze a megjelenített nevet, a jogosultságokat és azt, hogy a számláló létezik-e, ha pedig nem érhető el, jegyezze fel ezt a tényt, és forduljon a rendszergazdához. Lásd: Támogatási feltételek és beállítás.

1. Ugyanabban a munkamenetben a PowerShellben jegyezze fel az időpontot és a munkamenet-azonosítót.

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

   Más felhasználók munkameneteinek lekérdezéséhez további jogosultságok szükségesek lehetnek. A vizsgált folyamat szabványos példányneve SessionID:ProcessID <Process Image>. Ügyeljen rá, hogy ne csak a munkamenet-azonosítóra hagyatkozva keveredjenek bele más felhasználók vagy azonos nevű folyamatok értékei. Lásd: A query session jogosultságai, A példányok azonosítása.

2. A perfmon.exe programban adja hozzá az elérhető User Input Delay per Process vagy User Input Delay per Session számlálót.

   Válassza ki a vizsgált folyamatot vagy munkamenetet, és először az alapértelmezett 1 másodperces időközzel figyeljen. Különböztesse meg a több munkamenetet összesítő példányt az egyes munkamenetek értékeitől.

3. Reprodukálja azt a műveletet, amelynél a bevitel lassú, és vesse össze a sorban töltött várakozást a tünet időpontjával.

   Az egyes mért objektumoknál a mérési időközön belüli legnagyobb várakozási időt látja. Alacsony érték mellett is megmaradhat az a feldolgozás, amely azután történik, hogy az alkalmazás kivette a bevitelt, illetve az a késés, amíg az eredmény visszaér a helyi eszközre.

Így megvizsgálható, hogy a bevitel a távoli gép bemeneti sorában várakozik-e. Ez más mutató, mint a hálózati oda-vissza utat és a helyi megjelenítést is magában foglaló érzékelt idő. Lásd: A maximum és a mérési időköz jelentése.

flowchart TB
    accTitle: A User Input Delay által mért szakasz
    accDescr: A mérési szakasz a távoli gép bemeneti sorától addig tart, amíg az alkalmazás kiveszi a bevitelt; az előtte és utána zajló kommunikációt és megjelenítést nem tartalmazza.
    A["Megérkezik a helyi bevitel"] --> B["Bekerül a távoli bemeneti sorba"]
    B -->|"Ezt méri"| C["Az alkalmazás kiveszi"]
    C --> D["Alkalmazásfeldolgozás, képátvitel"]
    D --> E["Megjelenik a helyi eszközön"]

14. ábra: A mért érték a távoli gép bemeneti sorában töltött várakozás. Ez eltér a helyi eredmény megjelenéséig eltelt teljes időtől.

A képernyőfrissítés és a képkocka-kihagyás okainak vizsgálata

Készítsen elő egy olyan műveletet, például görgetést, amely folyamatos képernyőfrissítéssel jár. A RemoteFX Graphics számlálók elérhetőségét és mérési helyét az operációs rendszer, a gazdagép konfigurációja és a jogosultságok függvényében ellenőrizni kell. Itt csak az elérhető számlálókat olvassuk le. Ez nem a régi RemoteFX funkció telepítésének vagy engedélyezésének leírása. Lásd: A Graphics számlálók alkalmazási feltételei.

1. A query session vagy a qwinsta paranccsal ellenőrizze a vizsgált munkamenet nevét, és válassza ki a hozzá tartozó számlálópéldányt.

2. Képernyőfrissítéssel járó művelet közben hasonlítsa össze az Input Frames/Second és az Output Frames/Second értékét.

   Ha a kimenet kevesebb a bemenetnél, a képkockák egy része útközben kimarad. Ellenőrizze a Frames Skipped/Second értékeit külön a távoli gép, a hálózat és az ügyfél erőforráshiánya szerint.

3. Vesse össze a kihagyás okait a két végpont és a hálózat terhelésével, és nézze meg az Average Encoding Time értékét is.

   Ha a kódolási idő hosszú, vizsgálja meg a távoli gép tömörítési feldolgozását. Ha már a bemeneti oldalon is kevés a képkocka, az is lehet, hogy az alkalmazás nem frissíti gyakran a képernyőt. Statikus képernyőn az alacsony képkockaszám önmagában nem rendellenes.

A frissítés közbeni bemeneti és kimeneti képkockák, a kihagyás okai és a kódolási idő alapján leszűkíthető a vizsgálandó terület. A számlálók szerinti besorolás csak támpont, a tényleges terheléssel és a kapcsolati konfigurációval együtt kell értékelni. Lásd: A képkockaszám és a kódolási idő értelmezése.

flowchart TB
    accTitle: A vizsgálandó terület szűkítése a képkocka-kihagyás alapján
    accDescr: Képernyőfrissítéssel járó művelet közben összehasonlítjuk a bemeneti és a kimeneti képkockaszámot, majd a kihagyás okait mutató számlálókból kiindulva összevetjük a feldolgozás, a kommunikáció és a megjelenítés terhelésével.
    A["Be- és kimenet görgetés közben"] --> B["Kevés kimenet: kihagyás?"]
    B --> C["Okok szerinti számlálók"]
    C --> D["Távoli, hálózati, helyi terhelés"]

15. ábra: Görgetés közben összehasonlítjuk a bemenetet és a kimenetet, majd a kihagyás okait összevetjük a távoli gép, a hálózat és a helyi eszköz terhelésével.

A képernyőátvitel elvi ábráit és a régi dokumentációt nem általánosítjuk minden konfigurációra. Vannak olyan konfigurációk is, amelyek a videót és a hangot külön mechanizmussal továbbítják. A Graphics számlálók dokumentációja régi konfigurációkat is leír, ezért az ott szereplő számokat nem értelmezzük úgy, mintha közös specifikáció volna, hogy „minden RDP legfeljebb 30 fps”. A funkciókat és a számokat érvényességi körük ellenőrzése után használjuk. Lásd: Képernyőátvitel és munkaterhelés, A Graphics számlálók dokumentációja.

A mérési eredmények érvényességi köre

Az alacsony érték nem azonos azzal, hogy a használat kényelmes. Az egyes mutatók érvényességi körét a lépéseknél megadott Microsoft-dokumentációkban ellenőrizheti.

Hálózati és GPU-beállítások

Az UDP- és GPU-beállításokat az összehasonlítás és a mérés során kiderült tényekhez igazítva válassza meg. Ha a kommunikáció gyanús, először a kapcsolódási módot és az útvonalat, ha a képfeldolgozás gyanús, először azt ellenőrizze, melyik szakaszban használják a GPU-t.

A TCP, az UDP és a kapcsolati útvonal ellenőrzése

Ha az összehasonlítás és a mérés alapján a kommunikáció gyanús, a rendszergazdával ellenőrizze a használt ügyfelet, az útvonalat és az érvényes házirendeket. Ha beállítást kell módosítani, azt is csak a jóváhagyott keretek között tegye, és jegyezze fel a módosítás előtti értéket és a helyreállítás módját. Ne kapcsolja ki a tűzfalat vagy a hitelesítést, és ne tegye közvetlenül elérhetővé az RDP-portot az internetről.

1. A kapcsolati információk, a termék diagnosztikai naplói és a rendszergazda hálózati naplói alapján ellenőrizze a ténylegesen használt TCP-t, UDP-t és útvonalat.

   Az RDP a konfigurációtól és a hálózati feltételektől függően TCP-t vagy UDP-t használ. A „Select RDP transport protocols” házirendben választhat az UDP-t vagy TCP-t használó beállítás és a csak TCP-t használó beállítás között. Mivel létezik olyan működés is, amely az UDP-kapcsolat sikertelensége esetén TCP-t használ, a sikeres kapcsolódásból még nem derül ki a mód. Lásd: Az RDP-átvitel kiválasztása és a visszaváltás.

2. Vesse össze a tünet időpontját az útvonallal és a móddal, és csak a szükséges beállításokat hasonlítsa össze, egyenként.

   Ne módosítson általánosságban abból kiindulva, hogy „ha kikapcsoljuk az UDP-t, gyorsabb lesz”. Azonos VPN- és átjárófeltételek, művelet és megjelenítési feltételek mellett hasonlítson össze, a szükségtelen módosításokat pedig vonja vissza.

A mód és az útvonal ismeretében feljegyezheti a módosítás és a tünet közötti összefüggést. A csak TCP-re való korlátozás nem mindig jár gyorsulással.

flowchart TB
    accTitle: A hálózati beállítások összehasonlítása a kapcsolódási mód ellenőrzése után
    accDescr: Megkülönböztetjük a szokásos közvetlen kapcsolatot és az átjárón vagy szolgáltatáson keresztüli kapcsolatot, és a tényleges útvonal és mód ellenőrzése után végezzük el az engedélyezett összehasonlítást.
    A["Használt ügyfél és kapcsolat"] --> B["Tényleges útvonal, TCP vagy UDP"]
    B --> C["Összevetés a tünet idejével"]
    C --> D["Csak a szükséges, egyenként"]

16. ábra: Ellenőrizzük a használt kapcsolódási módot és útvonalat, összevetjük a tünettel, és csak ezután hasonlítjuk össze a szükséges beállításokat.

Az RDP Shortpath az Azure Virtual Desktop mechanizmusa. A szolgáltatás UDP-útvonalát hozza létre, és a konfigurációtól függően közvetlen útvonalat vagy közvetítést használ. Ha az útvonal nem hozható létre, TCP-alapú kapcsolatra vált vissza. Nem kezelhető ugyanabban a beállítási táblázatban azzal az esettel, amikor egy vállalati számítógéphez közvetlenül az mstsc programmal csatlakozunk. Lásd: Az RDP Shortpath útvonalai és a visszaváltás.

flowchart TB
    accTitle: Az RDP Shortpath útvonalai és a visszaváltás
    accDescr: Az Azure Virtual Desktop RDP Shortpath funkciója megkísérli létrehozni az UDP-útvonalat; ha ez sikerül, a konfigurációtól függően közvetlen útvonalat vagy közvetítést használ, ha nem, TCP-alapú kapcsolatra vált vissza.
    A["RDP Shortpath"] --> B{"UDP-útvonal"}
    B -->|"Létrejön"| C["Közvetlen vagy közvetített"]
    B -->|"Nem jön létre"| D["Vissza TCP-alapúra"]

17. ábra: Az RDP Shortpath TCP-alapú kapcsolatra vált vissza, ha nem tudja létrehozni az UDP-útvonalat.

A GPU használatának ellenőrzése a képfeldolgozásban

Akkor ellenőrizze, ha az összehasonlítás és a mérés alapján a képfeldolgozás gyanús. Nézze át a képfeldolgozás mérési eredményeit, valamint a támogatott operációs rendszert, illesztőprogramot, házirendet és ügyfelet. Pusztán azért, mert van GPU a gépben, ne módosítsa a beállításokat. Először szerezze be a rendszergazda jóváhagyását, és készüljön fel a visszaállításra.

1. Különítse el a távoli gépen futó alkalmazás rajzolását, az RDP kódolását és a helyi dekódolást, és válassza ki a gyanús szakaszt.

   Ha van is GPU, nem biztos, hogy minden szakasz azt használja. A Microsoft Azure Virtual Desktophoz készült konfigurációs dokumentációja is külön kezeli a távoli munkamenet rajzolásának és a képkockák hardveres kódolásának beállítását és ellenőrzését. Lásd: A GPU konfigurálása és ellenőrzése rajzoláshoz és kódoláshoz.

2. A termék leírását követve ellenőrizze a tényleges használatot, és a szükséges módosítás előtt és után mérje meg ugyanazt a műveletet.

   Ha hosszú a tömörítési idő, vizsgálja meg, hogy a kódolás használ-e GPU-t. Ha egy bemeneti sorban váró alkalmazás esetén a kódolási beállítást módosítja, rossz helyre céloz. A szöveg olvashatósága és a videó gördülékenysége esetén a képminőség, a forgalom és a feldolgozási terhelés közötti választás is eltér. Lásd: A munkaterhelés szerinti különbségek.

Nemcsak a GPU meglétét, hanem azt is feljegyezheti, hogy a problémás szakaszban használják-e a GPU-t, és hogyan változott ugyanannak a műveletnek a terhelése és a válaszideje. A javulást nem hozó módosítást a rendszergazdával egyeztetve vonja vissza.

flowchart TB
    accTitle: A GPU használatának ellenőrzése szakaszonként
    accDescr: Különválasztjuk a távoli gépen futó alkalmazás rajzolását, az RDP kódolását és a helyi dekódolást, és mivel GPU jelenléte esetén sem biztos, hogy minden szakasz használja, a gyanús szakaszban ellenőrizzük a használatát.
    A["Rajzolás a távoli alkalmazásban"] --> B["RDP-kódolás"]
    B --> C["Helyi dekódolás"]
    C -.- D["GPU-használat szakaszonként"]

18. ábra: Ha van is GPU, nem biztos, hogy a rajzolás, a kódolás és a dekódolás mindegyike azt használja.

Újraellenőrzés és átadás

A javulást azzal igazolja, hogy a módosítás után ugyanaz a művelet zavartalanul elvégezhető, és emellett megmarad a szükséges képminőség, eszközhasználat és üzleti funkcionalitás. Vesse össze az eredeti feltételek visszaállításával kapott eredményt is. Ha csak pillanatnyi a javulás, ne tekintse megállapítottnak az okot, hanem a csúcsidőszakokat és az egyidejű folyamatokat is belefoglalva rögzítse az eredményt.

flowchart TB
    accTitle: A javulás ellenőrzésének sorrendje
    accDescr: A módosítás után ellenőrizzük, hogy ugyanaz a művelet zavartalanul elvégezhető-e, és megmarad-e a szükséges képminőség, eszközhasználat és üzleti funkcionalitás, összevetjük az eredeti feltételek visszaállításával kapott eredménnyel, és pillanatnyi javulás alapján nem tekintjük megállapítottnak az okot.
    A["Ugyanaz a művelet módosítás után"] --> B["Képminőség, eszközök, funkciók"]
    B --> C["Összevetés a visszaállítással"]
    C -.- D["Pillanatnyi javulás nem döntő"]

19. ábra: Ugyanannak a műveletnek az eredménye mellett a szükséges funkciókat és a visszaállítás eredményét is összevetjük.

Átadás megoldatlan probléma esetén

Az is hasznos eredmény, ha nincs javulás, a tünet nem reprodukálható, vagy a számlálók nem érhetők el. Különítse el az elvégzett összehasonlításokat és az el nem végezhető ellenőrzéseket, és az alábbi jegyzettel adja át a vizsgálatot a rendszergazdának vagy a fejlesztőnek. A megosztott naplókból távolítsa el a vizsgálathoz nem szükséges üzleti adatokat, például a felhasználóneveket és a célgépek nevét.

A tünet időpontja és időzónája:
A távoli gép operációs rendszere, a használt ügyfél és verziója:
Közvetlen kapcsolat / VPN / RD Gateway / Azure Virtual Desktop stb.:
A lassú művelet és alkalmazás, más alkalmazások reakciója ugyanabban a munkamenetben:
A távoli oldal felbontása és a monitorok száma:
Egyidejűleg futó másolás, nyomtatás stb.:
Az egyetlen módosított feltétel és a visszaállítás eredménye:
A távoli gépen és a helyi eszközön megfigyelt terhelés és számlálók:

Egészítse ki azzal is, hogy sikerült-e ellenőrizni a ténylegesen használt TCP-t és UDP-t, mely tételeket nem lehetett például jogosultsághiány miatt ellenőrizni, és milyen beállítások fogadhatók el üzleti szempontból. Ha a „lassú a hálózat” helyett azt jelzi, hogy „a Jegyzettömbben normálisan lehet gépelni, de a fényképek görgetésekor megakad”, a következő felelős ugyanazok mellett a feltételek mellett vizsgálhatja a problémát.

A felhasználó rögzíti a reprodukálható műveletet és az összehasonlítás eredményét, a rendszergazda pedig összeveti a kapcsolati útvonal, a megosztott gazdagép és a munkamenetek naplóit. Abból, hogy a várakozás RDP-n keresztül történik, még nem következik, hogy a várakozást okozó feldolgozás is az RDP. Lásd: A gazdagép és a háttérrendszer szerepmegosztása.

Az alkalmazás fejlesztője külön naplózza a bemeneti események fogadását, az adatbázis- és fájlműveletek kezdetét és végét, valamint a felhasználói felületen való megjelenítést. Érdemes olyan tervezést is megfontolni, amely nem hagyja, hogy nehéz munka foglalja le a UI-szálat. A távoli gép feldolgozás-befejezési naplója azonban nem a helyi megjelenítés befejezését rögzíti. Lásd: A felhasználói felület válaszkészségét megőrző feldolgozás-szétválasztás.

Kapcsolódó cikkek

• Hogyan értelmezzük a Windows munkamenet-elkülönítését?
• A Windows 100%-os lemezhasználatának biztonságos behatárolása
• Miért nem ér véget a „még 1 másodperc”?

Források

Az alábbiak a Microsoft Learn elsődleges forrásai. A hivatkozott tartalmat 2026. szeptember 17-én ellenőriztük. Olvasáskor különítse el a termékenkénti alkalmazási feltételeket, és tartsa szem előtt, hogy nem a cikk keretében elvégzett mérésekről van szó.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Az RTT, valamint a távoli gépen történő képrögzítéstől a helyi megjelenítésig tartó késés megkülönböztetése. Maga a diagnosztikai funkció az Azure Virtual Desktophoz készült.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. A képernyő tartalma, a felbontás, a képkocka-frissítés, a tömörítés, a gyorsítótárazás és a forgalom összefüggése.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. A képernyő bemeneti és kimeneti képkockáinak, a kihagyás okainak és a kódolási időnek az ellenőrzése. Mivel régi konfigurációk leírását is tartalmazza, a számszerű felső határokat nem általánosítjuk minden RDP-re.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. A megosztott gazdagép terhelése, a távoli gép és a háttérrendszer közötti kommunikáció, az eszközátirányítás hatása.
• Microsoft Learn, Threading model. A WPF UI-szála és a Dispatcher, a válaszkészség megőrzését szolgáló feldolgozás-szétválasztás.
• Microsoft Learn, mstsc. A távoli asztal szélességének és magasságának, valamint a több monitornak a megadása.
• Microsoft Learn, Supported RDP properties. Az asztali felbontás, a dinamikus felbontás és a smart sizing megkülönböztetése. Ellenőrizze a támogatott ügyfeleket és a termékenkénti alkalmazási feltételeket.
• Microsoft Learn, ping. A válasz ellenőrzése ICMP Echo segítségével, valamint a kapcsolók.
• Microsoft Learn, Test-NetConnection. A TCP-kapcsolat ellenőrzése és a kimenet jelentése.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. A User Input Delay mérési szakasza, a támogatott operációs rendszerek, a példányok és a maximum jelentése.
• Microsoft Learn, query session. Munkamenet-információk, valamint a más munkamenetek lekérdezéséhez szükséges jogosultságok.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Az RDP által használt TCP és UDP kiválasztása és a visszaváltás.
• Microsoft Learn, RDP Shortpath. Az Azure Virtual Desktop UDP-útvonala, és a működés, ha az útvonal nem hozható létre.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. A rajzolást és a képkocka-kódolást külön kezelő GPU-konfiguráció és -ellenőrzés.

Kapcsolódó cikkek

Azonos címkéket használó, legfrissebb cikkek. Mélyítse el ismereteit szorosan kapcsolódó témákban.

Kapcsolódó témák

Ehhez a témához közel álló témaoldalak. A cikkből kiindulva eljuthat a kapcsolódó szolgáltatásokhoz és további cikkekhez.

Mely szolgáltatásokhoz kapcsolódik ez a téma

Ez a cikk a következő szolgáltatási oldalakhoz kapcsolódik. Kezdje azzal, amelyik a leginkább illik az Ön helyzetéhez.

Gyakori kérdések

A cikk témájával kapcsolatban a konzultációk során gyakran felmerülő kérdések.

Miért lassú az RDP-ben a bevitel, ha a sebességmérés több száz Mbps-ot mutat?

A nagy adatmennyiség szállításának sebessége és a műveletre adott válasz megérkezéséig eltelt idő két külön dolog. Szerepet játszik a bevitel elküldése, a távoli gépen futó alkalmazás feldolgozása, a képernyő tömörítése, az átvitel és a helyi megjelenítés. Ráadásul a sebességmérés szervere és az RDP-kapcsolat célgépe felé vezető hálózati útvonal sem azonos.

Ha a gépelés rendben van, de csak a görgetés akadozik, akkor a hálózattal van baj?

Az ok nem szűkíthető le csak a hálózatra. Amikor megszaporodnak a képernyőfrissítések, előfordulhat, hogy a távoli gépen a rajzolás és a tömörítés, a kommunikáció, illetve a helyi dekódolás és megjelenítés valamelyike nem tud lépést tartani. Egyenként változtassa meg a távoli oldal felbontását vagy a monitorok számát, hasonlítsa össze az eredményt, és szükség esetén vizsgálja meg a rajzolással kapcsolatos számlálókat.

Ha a ping gyors, akkor rendben van az RDP kommunikációja?

Ez önmagában nem elég a megítéléshez. A ping az ICMP-re adott választ méri, az RDP képernyőátvitelét és az alkalmazás feldolgozását nem. RD Gatewayt vagy hasonló megoldást használó konfigurációkban az útvonal sem feltétlenül egyezik. Ha nem érkezik válasz, akkor is különböztesse meg az ICMP blokkolását attól, hogy maga az RDP elérhetetlen.

A User Input Delay az az idő, amely egy billentyű lenyomásától a karakter megjelenéséig telik el?

Nem. Ez a számláló azt a várakozási időt méri, amely a távoli gépen attól kezdve telik el, hogy a bevitel bekerül a sorba, addig, amíg egy folyamat kiveszi onnan. Nem az az érzékelt késleltetés, amely a hálózati oda-vissza utat, a kivétel utáni alkalmazásfeldolgozást, valamint a képernyő tömörítését, dekódolását és megjelenítését is magában foglalná.

Ki kell kapcsolni az UDP-t, ha lassú az RDP?

Általánosságban nem javasoljuk. Először ellenőrizze a tényleges kapcsolódási módot, az útvonalat és az érvényes házirendeket. Előfordulhat, hogy az UDP nem használható, és a kapcsolat TCP-re vált vissza, a csak TCP-re való korlátozás pedig nem mindig gyorsít. A rendszergazda engedélyével, azonos feltételek mellett hasonlítson össze, a szükségtelen módosításokat pedig vonja vissza.

A szerző bemutatása

A cikk szerzőjének bemutatkozó oldala.

Go Komura

A KomuraSoft LLC képviselője

Fő területei a Windows-szoftverfejlesztés, a műszaki konzultáció és a hibakeresés; különösen a meglévő megoldásokat érintő projektekben, valamint a nehezen felderíthető okú hibák kivizsgálásában erős.