Varför är RDP trögt trots en snabb anslutning? – Undersök inmatning, rendering och kommunikation var för sig

En hastighetsmätning visar flera hundra Mbit/s, men i fjärrskrivbordet dyker tecknen upp med en liten fördröjning. När du rullar en sida med många foton hackar skärmen. Bara när du trycker på Sök i en verksamhetsapp stannar allt i flera sekunder. Var ska man börja undersöka ett sådant läge, där ”anslutningen är snabb men RDP är trögt”?

Hur snabbt RDP svarar på en åtgärd avgörs inte bara av anslutningens överföringshastighet. Även om hastighetsmätningen visar höga värden kan väntan uppstå någonstans i tur och retur-trafiken, i väntan på indata i appen på fjärrdatorn, i kodningen av skärmbilden eller i avkodningen och visningen lokalt. Skilj först på ”vilken åtgärd som är långsam” och jämför samma åtgärd ett villkor i taget. Ring in var du ska undersöka med jämförelser och mätningar, och välj UDP- och GPU-inställningar utifrån resultatet. Se: mätsträckor för anslutningskvalitet, prestandafaktorer för sessionsvärdar.

När du har ringat in var du ska undersöka är grundorsaken dock ännu inte fastställd. Även om det blir bättre när du sänker upplösningen ändras inte bara kommunikationen utan också skärmbearbetningen i båda ändar, så vi slår inte fast att ”det var anslutningen som var orsaken”. Håll isär de sträckor du har mätt och de du inte har mätt, och anteckna resultatet.

Den här artikeln ringar in responsen vid inmatning, rullning och i appar efter att anslutningen har upprättats. Även om symtomen liknar varandra behöver orsaken inte vara en enda. Fall där ”det tar lång tid innan inloggningsskärmen visas” eller ”det stannar redan vid autentiseringen” behandlas som ett separat problem som undersöks utifrån loggarna för anslutningsupprättande och autentisering.

Artikeln riktar sig främst till användare och administratörer som ansluter från Windows-appen ”Anslutning till fjärrskrivbord” (mstsc) till Windows 11 eller Windows Server. Kommandoexemplen är skrivna för Windows PowerShell 5.1. Vi förutsätter att samma åtgärd kan reproduceras i en redan ansluten session.

Direktanslutning, VPN, RD Gateway och Azure Virtual Desktop skiljer sig åt i fråga om väg, tillgänglig diagnostikinformation och var inställningar tillämpas. Exemplet med kontroll av TCP 3389 gäller bara tillåtna direktanslutningar till RDP-värdar som använder standardporten. Diagnostikfunktioner och GPU-inställningar från dokumentation för Azure Virtual Desktop tillämpas inte rakt av på vanliga datorer i företaget.

På företagets enheter undersöker du inom de ramar som administratören har godkänt. På en delad värd identifierar du din egen session och den aktuella processen, och om du behöver andra användares data ber du administratören om dem. Kontrollera för varje miljö om prestandaräknarna finns tillgängliga, vad de heter och vilka behörigheter som krävs.

Kontrollmetoderna som visas här bygger på officiell dokumentation. Det är ingen mätrapport om att ett fel reproducerades och åtgärdades på en viss enhet. Sifferexempel redovisas tydligt markerade som antaganden i förklarande syfte.

Mekanismen kan läsas i ordning med början i nästa avsnitt, ”Överföringshastighet och tur och retur-tid”. Om du vill börja undersöka utifrån symtomen går du till ”Första jämförelsen utifrån symtomet”. Stegen för undersökningen finns i ”Jämför ett villkor i taget” och ”Mät var väntan uppstår”.

I diagrammet markerar en heldragen linje en relation som alltid gäller och en streckad linje en villkorad relation (villkoren anges per relation på detaljsidan). Den fullständiga listan över relationer (totalt 7, med belägg och säkerhetsgrad) och definitionerna av huvudbegreppen finns samlade på detaljsidan för kunskapskartan (på japanska). Data: JSON-LD / Turtle

Överföringshastighet och tur och retur-tid

RDP (Remote Desktop Protocol) är ett protokoll som utväxlar indata, skärminformation med mera mellan den lokala enheten och fjärrdatorn. Det hanterar inte bara skärm och indata utan även information för enhetsomdirigering, utskrift med mera. Se: information som RDP överför.

Anslutningens överföringshastighet anger hur mycket data som kan transporteras per sekund. ”500 Mbit/s” i en hastighetsmätning är en siffra för den mängden. Den anger inte tiden från det att du gör något tills svaret kommer fram. Se: bandbreddskrav för RDP.

flowchart TB
    accTitle: Vad siffran i hastighetsmätningen anger
    accDescr: Visar att 500 Mbit/s i en hastighetsmätning anger hur mycket data som kan transporteras per sekund och är en annan siffra än tiden från en åtgärd tills svaret kommer fram.
    A["Hastighetsmätning: 500 Mbit/s"] --> B["Datamängd per sekund"]
    B -.->|"en annan siffra"| C["Tid tills svaret kommer"]

Figur 1: Siffran i hastighetsmätningen anger mängden som kan transporteras, inte tiden tills svaret kommer fram.

Tur och retur-tid (RTT) är tiden det tar för trafiken att nå motparten och komma tillbaka. Att höja överföringshastigheten och att korta tur och retur-tiden skiljer sig åt ungefär som att bygga fler körfält på en väg och att korta avståndet till målet. Även om förmågan att transportera stora mängder filer ökar finns väntan på svar vid varje åtgärd kvar om tur och retur-tiden är densamma. Se: RTT och fördröjning i skärmvisningen.

flowchart TB
    accTitle: Överföringshastighet och tur och retur-tid liknade vid en väg
    accDescr: Ett diagram som liknar en högre överföringshastighet vid fler körfält på en väg och en kortare tur och retur-tid vid ett kortare avstånd till målet.
    A["Höj överföringshastigheten"] -->|"på en väg"| B["Fler körfält"]
    B ~~~ C["Korta tur och retur-tiden"]
    C -->|"på en väg"| D["Kortare avstånd"]

Figur 2: Fler körfält gör inte avståndet till målet kortare.

Ett tecken tur och retur

Tänk dig att du skriver ett tecken i Anteckningar på fjärrdatorn. Anteckningar körs på fjärrdatorn. Om vi i förklarande syfte antar 50 millisekunder för att åtgärden ska komma fram och 50 millisekunder för att den resulterande skärminformationen ska komma tillbaka, blir tiden för kommunikationen totalt 100 millisekunder, alltså 0,1 sekunder. Bearbetningstiden i båda ändar är inte medräknad i det här exemplet.

flowchart TB
    accTitle: Exempel på kommunikationstiden tills resultatet av ett tecken kommer tillbaka
    accDescr: Ett exempel där vägen dit och vägen tillbaka i förklarande syfte antas ta 50 millisekunder vardera. Bearbetningstiden i båda ändar ingår inte, och diagrammet visar inte heller antalet paket per tangent.
    A["Skriv ett tecken lokalt"] -->|"Dit: 50 ms"| B["Fjärrdatorn tar emot indata"]
    B --> C["Skicka skärm med indatat"]
    C -->|"Tillbaka: 50 ms"| D["Resultatet når dig"]

Figur 3: Med antagna 50 millisekunder dit och 50 millisekunder tillbaka tar kommunikationen ensam 0,1 sekunder. Det är inga uppmätta värden.

Även om mängden som anslutningen kan transportera ökar finns dessa 0,1 sekunder kvar så länge tur och retur-tiden inte ändras. Figur 3 är ett konceptdiagram för att förstå förloppet. Det betyder inte att ett separat paket skickas fram och tillbaka för varje tangent. Hastighetsmätningens motpart och RDP-fjärrdatorn nås dessutom via olika vägar, så räkna även med VPN, gateway, uppströmskapaciteten på fjärrdatorns sida och trängsel längs vägen. Se: synen på RTT, nätverks- och värdprestanda.

Att skapa och leverera skärmbilden

Med fördröjd respons menar vi här väntan från det att du gör något lokalt tills du ser resultatet. Inte bara RTT utan också appens bearbetning och arbetet med att skapa och leverera skärmbilden spelar in. Vi skiljer det också från fördröjningen enbart i skärmöverföringen. Se: mätsträckan från skärmfångst till visning.

När indata når fjärrdatorn från den lokala enheten bearbetar appen på fjärrdatorn indatat och uppdaterar skärmen, den kodade skärminformationen transporteras över nätverket och avkodas och visas sedan lokalt. Även före och efter kommunikationen finns arbete som olika datorer ansvarar för. Se: bearbetningen från skärmfångst till visning.

flowchart TB
    accTitle: Skärmen bearbetas även före och efter nätverket
    accDescr: Förloppet där indata från den lokala enheten når fjärrdatorn, appen där bearbetar dem, skärmbilden skapas och komprimeras, och skärminformationen som transporterats över nätverket återställs lokalt till visningsbar form och visas.
    I["Lokalt: mata in åtgärd"] --> J["Nätverk: överför indata"]
    J --> K["Fjärrdator: appen bearbetar"]
    K --> A["Fjärrdator: skapa, komprimera"]
    A --> B["Nätverk: överför skärmdata"]
    B --> C["Lokalt: gör visningsbar"]
    C --> D["Visas på din skärm"]

Figur 4: Bearbetning och komprimering på fjärrdatorn, transport över nätverket och återställning för visning lokalt. Varje steg är arbete som utförs på en egen plats.

Med kodning menar vi i den här artikeln den bearbetning som på fjärrdatorn omvandlar och komprimerar skärmbilden till en form som är lätt att skicka. Utöver överföringen över nätverket tar den bearbetningstid på fjärrdatorn. Se: kodningstid på fjärrdatorn.

Med avkodning menar vi i den här artikeln den bearbetning som lokalt återställer mottagen skärminformation till en form som kan visas. Vi skiljer den från dekryptering i betydelsen att häva en kryptering. Se: avkodning och visningstid lokalt.

Om komprimeringen på fjärrdatorn tar tid får sändningen vänta på att förberedas, även om nätverket har ledig kapacitet. Även när informationen har kommit fram blir uppdateringen fördröjd om avkodningen eller visningen lokalt inte hinner med. Det stämmer inte nödvändigtvis att ”den lokala enheten spelar ingen roll eftersom företagets dator är kraftfull”. Marginalen i nätverket och marginalen i bearbetningen i dess båda ändar är olika saker. Se: prestandaräknare för skärmbearbetning.

flowchart TB
    accTitle: Fördröjning när bearbetningen i båda ändar inte hinner med
    accDescr: Visar att sändningen får vänta på att förberedas när komprimeringen på fjärrdatorn tar tid, även om nätverket har ledig kapacitet, och att uppdateringen fördröjs om avkodningen eller visningen lokalt inte hinner med, även om informationen har kommit fram.
    A["Fjärrkomprimeringen tar tid"] --> B["Sändning väntar trots ledigt nät"]
    B ~~~ C["Lokal avkodning hinner inte med"]
    C --> D["Framme men uppdateras sent"]

Figur 5: Även med marginal i nätverket blir skärmuppdateringen fördröjd om bearbetningen i båda ändar inte hinner med.

Textinmatning jämfört med rullning

När du lägger till ett tecken i Anteckningar är det bara en liten del av skärmen som ändras. När du rullar en sida med många foton ändras visningen över ett stort område i snabb följd. RDP håller nere datamängden genom att överföra ändrade delar och genom komprimering och cachelagring som passar innehållet. Det skickar inte hela skärmen okomprimerad varje gång. Arbetsmängden varierar med skärmens innehåll och hur ofta den uppdateras. Se: sambandet mellan skärminnehåll och bandbredd.

flowchart TB
    accTitle: Arbetsmängden för skärmen vid textinmatning och rullning
    accDescr: En liten ändring av ett tecken och en kontinuerlig uppdatering av ett stort område skiljer sig åt i hur arbetet med att skapa och skicka skärmbilden ser ut.
    A{"Ändring på skärmen"} -->|"Lägg till ett tecken"| B["Litet område"]
    A -->|"Rullning"| D["Stort område i följd"]
    B --> E["Komprimera och överför ändringen"]
    D --> E

Figur 6: Även i samma anslutning skiljer sig arbetsmängden mellan att lägga till ett tecken och att ett stort område rör sig hela tiden.

Även om ett stillastående dokument är lätt kan marginalen i skärmöverföringen ta slut under rullning. Om du ökar upplösningen eller antalet bildskärmar på fjärrsidan blir också skärmen som ska bearbetas större. Att jämföra med lägre upplösning är ett experiment för att se om rörelserna blir normala igen när arbetet med att skapa och skicka skärmbilden minskar. Det är ingen beräkning som bestämmer datamängden enbart utifrån antalet bildpunkter. Se: effekten av upplösning, skärmuppdatering och komprimering.

Väntan i appen

Om bara sökningen i en verksamhetsapp stannar i flera sekunder medan du kan skriva normalt i Anteckningar i samma session kontrollerar du vad appen väntar på. Appen på fjärrdatorn kan i sin tur skicka en sökning till en annan databas eller läsa filer från en delad mapp och vänta på svaret. Det är en annan väg än RDP-kommunikationen mellan den lokala enheten och fjärrdatorn. Se: kommunikation från fjärrdatorn till backend.

flowchart TB
    accTitle: Bortom RDP finns fler kommunikationsparter
    accDescr: Visar ett fall där appen på fjärrdatorn väntar på svar från en verksamhetsserver, skilt från kommunikationen mellan den lokala enheten och fjärrdatorn.
    A["Lokal enhet"] -->|"RDP"| B["Verksamhetsapp på fjärrdatorn"]
    B -->|"Sökning, filbegäran"| C["DB, delad mapp"]
    C -->|"Svaret som väntas"| B

Figur 7: Verksamhetsappen bortom RDP kan i sin tur vänta på svar från en annan server.

Om den bearbetning som ansvarar för skärm och indata har ett långt jobb att utföra fördröjs nästa indata och skärmuppdatering. I WPF försämras till exempel responsen när UI-tråden är upptagen länge. Att den totala CPU-användningen är låg räcker inte för att utesluta väntan i en viss UI-tråd. Se: Dispatcher och UI-tråden.

flowchart TB
    accTitle: Bearbetningen för skärm och indata blir blockerad
    accDescr: Visar att nästa indata och skärmuppdatering fördröjs när den bearbetning som ansvarar för skärm och indata har ett långt jobb, och att låg total CPU-användning inte räcker för att utesluta den väntan.
    A["Bearbetning för skärm och indata"] --> B["Har ett långt jobb"]
    B --> C["Nästa indata och uppdatering dröjer"]
    C -.- D["Låg total CPU utesluter inte"]

Figur 8: Väntan i UI-tråden kan inte uteslutas enbart utifrån den totala CPU-användningen.

Första jämförelsen utifrån symtomet

Mängden som kan transporteras, tiden man väntar på svar och tiden det tar att skapa och visa skärmbilden är olika saker. Om du håller isär dem kan du undersöka utifrån den åtgärd som är långsam just nu, i stället för att avfärda ”RDP är trögt” med en enda orsak.

flowchart TB
    accTitle: Skilj på tre saker innan du undersöker
    accDescr: Visar att man inte avfärdar ”RDP är trögt” med en enda orsak, utan skiljer på mängden som kan transporteras, tiden man väntar på svar och tiden det tar att skapa och visa skärmbilden, och undersöker utifrån den åtgärd som är långsam nu.
    A["”RDP är trögt”"] --> S
    subgraph S["Betrakta var för sig"]
    direction TB
    B["Mängd som kan överföras"] ~~~ C["Tid i väntan på svar"]
    C ~~~ D["Tid att skapa och visa skärmen"]
    end
    S --> E["Börja med det som är långsamt nu"]

Figur 9: Om du skiljer på mängden som kan transporteras, tiden i väntan på svar och tiden för att skapa och visa skärmbilden kan du undersöka utifrån den åtgärd som är långsam just nu.

Målet med att ringa in är att begränsa var långsamheten ska undersökas. Att ändra alla inställningar på en gång och råka göra det snabbare är inte målet. Genom att använda skillnader som ”Anteckningar fungerar men bara sökningen stannar” eller ”textinmatningen är normal men bara rullningen är trög” kan du välja var undersökningen ska börja redan innan du ändrar nätverksinställningar.

Följande tabell är en utgångspunkt för undersökningen. Den är ingen tabell för att avgöra orsaken. Jämför först åtgärderna i samma session och ändra sedan enhet, väg och visningsvillkor efter behov.

Tecken fördröjs i flera appar

Om tecknen dyker upp ett i taget med fördröjning i flera appar i samma session jämför du samma åtgärd även från en annan enhet eller via en annan tillåten väg. Stäm av tur och retur-tiden, väntan på indata på fjärrdatorn och belastningen på hela fjärrdatorn, och avgör inte orsaken utifrån ett enda värde.

Bara rullningen hackar

Även om textinmatningen är normal leder rullning på en sida med många foton till att stora områden av skärmen uppdateras i följd. Ändra upplösningen eller antalet bildskärmar på fjärrsidan ett i taget och jämför på samma sida. Om det blir bättre är komprimeringen på fjärrdatorn, skärmöverföringen och avkodningen lokalt nästa sak att undersöka. Upplösningen ensam visar inte vilken av de tre som är orsaken. Se: belastning beroende på skärminnehåll och upplösning.

Bara en app fryser

Om bara verksamhetsappen där du tryckte på Sök stannar jämför du om Anteckningar eller liknande i samma session svarar. Om andra appar fungerar undersöker du först den aktuella appens bearbetning, disken och begäranden till databaser eller delade mappar. Att du arbetar via RDP och att RDP-kommunikationen är orsaken till väntan är två olika saker. Se: prestandafaktorer för appar och backend.

Alla är långsamma när användarna blir fler

Om det blir långsamt för flera användare under samma tidsperiod frågar du administratören om läget i de andra sessionerna. Stäm av belastningen på den delade värdens CPU, minne och lagring och på den delade anslutningen mot tidpunkten för symtomen. Gå inte in i andra användares data eller processer utan tillstånd, och stoppa inte deras jobb. Se: resurser och antal användare på delade värdar.

Långsamt under kopiering eller utskrift

Om tidpunkten då du startade en egen kopiering eller utskrift sammanfaller med problemet pausar du bara de överföringar som du har tillstånd att stoppa och jämför. Anteckna om det blir normalt efter pausen och om det blir långsamt igen när du återupptar, och undersök konkurrensen med andra överföringar än skärmen och med enhetsomdirigering. Gör inga jämförelser där enheter som behövs i arbetet stängs av allihop på en gång. Se: effekten av enhetsomdirigering.

Jämför ett villkor i taget

Du behöver inte ändra alla inställningar i tur och ordning. Skapa först en referenspunkt för jämförelsen och välj bara de kontroller som passar symtomet. Spara ditt arbete innan du ändrar inställningar eller ansluter igen, och anteckna de ursprungliga värdena och hur de återställs. Om du saknar nödvändiga behörigheter eller funktioner tvingar du inte fram en aktivering utan lämnar över till administratören.

Lokal användning och användning via RDP har inte nödvändigtvis samma villkor. Att det går snabbt på fjärrdatorns fysiska skärm är en ledtråd, men sessionen och renderingsvillkoren kan skilja sig. Se till att användare, data och appens tillstånd är desamma, och begränsa inte orsaken till anslutningen bara för att ”det går snabbt på den fysiska skärmen”.

Jämför samma åtgärd

Förbered samma användare, data och åtgärd. På en delad värd kontrollerar du vilken session som är din och stoppar inte andra användares appar eller processer. Användning av en annan enhet eller en annan väg begränsas också till det som administratören har godkänt.

1. Reproducera den långsamma åtgärden med de ursprungliga inställningarna och anteckna tidpunkt och symtom.

   Skriv ungefär lika mycket text i Anteckningar, i samma fjärrsession som den problematiska appen. Skilj på om det gäller en enda app eller hela sessionen.

2. Kontrollera belastningen på fjärrdatorn och lokalt under samma tidsperiod.

   I Aktivitetshanteraren tittar du på CPU, minne och disk för den aktuella appen på fjärrdatorn och på belastningen från RDP-klienten lokalt. Kontrollera den aktuella processen och inte bara det totala CPU-värdet. Se: vad belastningen ska kontrolleras för.

3. Ändra bara ett av villkoren – annan enhet, annan tillåten väg eller visningsvillkor – och upprepa samma åtgärd.

   Om även fjärrdatorns eller appens tillstånd ändras samtidigt i jämförelsen antecknar du även den skillnaden. Betrakta inte ett resultat där flera villkor har ändrats som effekten av ett enda villkor.

4. Återställ de ursprungliga villkoren och kontrollera samma åtgärd igen.

   Om det fortfarande går snabbt efter återställningen kan till exempel en tillfällig förändring i belastningen ligga bakom. Dra inte slutsatsen att ändringen hjälpte, utan anteckna under vilka villkor symtomet återkommer.

När resultaten för ursprungligt tillstånd, efter ändringen och efter återställningen finns på plats kan du jämföra vilka villkor som hänger ihop med symtomet. Ett villkor som gav förbättring är en ledtråd i undersökningen och bevisar inte ensamt grundorsaken.

flowchart TB
    accTitle: Begränsa vad som ändras åt gången
    accDescr: Förloppet där du bestämmer en åtgärd som reproduceras i ursprungligt tillstånd, jämför genom att ändra bara ett villkor och även kontrollerar resultatet efter återställning.
    A["Samma åtgärd, ursprunglig inställning"] --> B["Ändra bara ett villkor"]
    B --> C["Upprepa samma åtgärd"]
    C --> D["Återställ och kontrollera igen"]
    D --> E["Anteckna villkoret som hjälpte"]

Figur 10: Upprepa samma åtgärd i ursprungligt tillstånd, efter ändringen och efter återställningen, och anteckna det villkor som gjorde skillnad.

Jämför upplösningen på fjärrsidan

Jämför detta när skärmuppdateringen är trög, till exempel vid rullning. Anteckna upplösning och antal bildskärmar före ändringen, spara ditt arbete och anslut sedan igen. Behåll inte inställningar som försämrar skärmar som behövs i arbetet eller textens läsbarhet för daglig användning.

1. Ändra bara antingen antalet bildskärmar eller upplösningen.

   I mstsc kan du jämföra med inställningarna på fliken ”Bildskärm” före anslutningen eller genom att ange bredd och höjd. Se: skärminställningar i mstsc.

2. Kontrollera att fjärrskrivbordets faktiska storlek har ändrats och rulla på samma sida.

   Om du bara gör det lokala fönstret mindre kan ett stort skrivbord visas nedskalat. Skilj på dynamisk upplösning och smart sizing, och kontrollera vilka villkor klienten du använder har stöd för. Se: skrivbordsupplösning och visningsskala.

3. Återställ de ursprungliga inställningarna, upprepa samma åtgärd och jämför belastningen i båda ändar och hur skärmen rör sig.

   Om du ändrade till låg upplösning och en enda bildskärm samtidigt blir jämförelsen bara grov. Om det blir bättre återställer du en sak i taget för att skilja effekterna åt.

Om det blir bättre finns det ledtrådar inom skärmbearbetning och skärmöverföring. 3840×2160 har fyra gånger så många bildpunkter som 1920×1080, men datamängden blir inte alltid fyra gånger så stor. Den varierar med ändrade delar och komprimering, och en ändrad upplösning påverkar också bearbetningen i båda ändar. Se: sambandet mellan antal bildpunkter och datamängd, kontroll av skärmbearbetningen.

flowchart TB
    accTitle: Vad en jämförelse med lägre upplösning visar
    accDescr: När upplösningen på fjärrsidan sänks kan belastningen ändras både i skärmbearbetningen och i överföringen, så en förbättring räcker inte för att begränsa orsaken till anslutningen.
    A["Sänk upplösningen på fjärrsidan"] --> S
    subgraph S["Det som ändras"]
    direction TB
    B["Skärmbearbetning på fjärrdatorn"] ~~~ C["Mängd data som skickas"]
    C ~~~ D["Lokal visningsbearbetning"]
    end

Figur 11: En ändrad upplösning är en jämförelse som påverkar inte bara anslutningen utan också skärmbearbetningen på fjärrdatorn och lokalt.

Stäm av kopiering och utskrift mot symtomen

Pausa bara sådant som du har tillstånd att stoppa, till exempel överföringar som du själv har startat. Stoppa inte företagets säkerhetskopiering eller säkerhetsprocesser eller andra användares jobb. Stäng inte av omdirigering av ljud- och inmatningsenheter som behövs i arbetet allihop på en gång.

1. Anteckna samma åtgärd och belastning före och under kopiering, molnsynkronisering och utskrift.

   Utöver skärmen flödar även information från diskenheter, skrivare med mera genom RDP. Omdirigering, där lokala enheter används på fjärrdatorn, kan öka belastningen på kommunikation och bearbetning medan den används. Se: effekten av enhetsomdirigering.

2. Pausa den aktuella överföringen inom tillåtna ramar och kontrollera samma åtgärd igen.

   Om du kan återuppta och jämföra antecknar du även symtomet efter återupptagandet. Även när du provar att ta bort onödig enhetsomdirigering ändrar du en i taget så att du kan återställa de ursprungliga inställningarna.

Du kan avgöra om överföringsstart och problem respektive paus och återhämtning hänger ihop. Om ett samband syns stämmer du av andra överföringar än skärmen och belastningen på delade resurser mot administratörens loggar.

flowchart TB
    accTitle: Se före och efter problemet på samma tidslinje
    accDescr: Anteckna samma åtgärd och belastning före överföringen, under överföringen och efter stoppet, och jämför sambandet mellan problemet och arbetet.
    A["Åtgärd och last före"] --> B["Åtgärd och last under"]
    B --> C["Åtgärd och last efter stopp"]
    C --> D["Hänger problem och återhämtning ihop?"]

Figur 12: Se hur långsamheten i samma åtgärd och belastningen förändras före överföringen, under överföringen och efter stoppet.

Mät var väntan uppstår

Lokalt undersöker du tur och retur-trafiken och TCP-anslutningen, och på fjärrdatorn väntan i indatakön och skärmuppdateringarna. Varje värde mäter bara en begränsad sträcka, så läs resultaten mot tabellen i ”Vad mätresultaten täcker”.

Kontrollera ICMP och TCP-anslutning

Kommandona körs på den lokala Windows-enheten. Endast konfigurationer där du ansluter direkt via företagets LAN eller ett tillåtet VPN till en RDP-värd som använder standardporten TCP 3389 omfattas. För konfigurationer via RD Gateway eller Azure Virtual Desktop, eller med en egen port, bestämmer du tillsammans med administratören vad som ska kontrolleras. Öppna inga portar och ändra inte brandväggen.

1. Ange den tillåtna fjärrdatorn och anteckna resultaten för ICMP-svar och TCP-anslutning.

   $target = Read-Host 'Namn eller IP-adress till RDP-värden som du har tillstånd att undersöka'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Ange ett anslutningsmål.'
   }
       
   # Titta på ICMP-svarstiden flera gånger. Ett misslyckande ensamt visar inte att RDP inte går att nå.
   ping.exe -n 20 $target
       
   # Kontroll som bara gäller konfigurationer med direktanslutning till standardporten TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Stäm av resultaten från den långsamma tidsperioden och från normala förhållanden mot tidpunkten för symtomen och den faktiska anslutningsvägen.

   20 körningar av ping är en kort observation. Anteckna variationer och uteblivna svar, men ICMP kan också vara blockerat. Uteslut inte sporadiska avbrott enbart utifrån medelvärdet, utan använd anslutningsinformation och administratörens nätverksloggar. Se: vad ping mäter.

TcpTestSucceeded: True betyder att TCP-anslutningen till den angivna porten lyckades. Bandbredd, UDP, åtgärder efter autentisering och hur jämnt skärmen rör sig har inte mätts. Test-NetConnection har ingen växel -UDP för att undersöka UDP. Se: syntax och resultat för Test-NetConnection.

Vi bedömer resultaten med skillnaderna i väg och tjänst i åtanke. Med RD Gateway och liknande kan vägen för ICMP eller direkt TCP-anslutning till värden skilja sig från den faktiska RDP-vägen. I Azure Virtual Desktop finns RTT och uppskattad bandbredd per anslutning tillgängliga, men den diagnostikfunktionen är avsedd för just den tjänsten. Korta avbrott utesluts inte enbart utifrån medelvärden. Se: loggar för anslutningskvalitet i Azure Virtual Desktop.

flowchart TB
    accTitle: Den kontrollerade vägen och den faktiska RDP-vägen
    accDescr: I konfigurationer med RD Gateway och liknande kan vägen för ICMP eller direkt TCP-anslutning från den lokala enheten till värden skilja sig från den faktiska RDP-vägen.
    A["Lokal enhet"] -->|"ICMP, direkt TCP"| C["RDP-värd"]
    A -->|"Faktisk RDP"| B["RD Gateway m.fl."]
    B --> C

Figur 13: Vägen kan skilja sig mellan ICMP eller direkt TCP-anslutning till värden och den faktiska RDP-trafiken.

Mät väntan i indatakön

User Input Delay mäter väntan från det att indata hamnar i kön på fjärrdatorn tills processen hämtar ut dem. Det är inte den totala tiden från tangenttryckning tills tecknet syns. Se: definitionen av User Input Delay.

Undersökningen görs i fjärrsessionen på fjärrdatorn. Microsofts villkor för stöd är Windows 10 version 1809 eller senare och Windows Server 2019 eller senare. För dessa system behöver du inte lägga till något i registret för att aktivera räknaren. Kontrollera visningsnamn, behörigheter och om räknaren finns, och om den inte kan användas antecknar du det och rådfrågar administratören. Se: villkor för stöd och inställningar.

1. Anteckna tidpunkt och sessions-ID i PowerShell i samma session.

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

   Det kan krävas ytterligare behörigheter för att fråga efter andra användares sessioner. Standardnamnet på instansen för en process är SessionID:ProcessID <Process Image>. Blanda inte ihop värden från andra användare eller processer med samma namn genom att gå enbart efter sessions-ID. Se: behörigheter för query session, identifiering av instanser.

2. Lägg till User Input Delay per Process eller User Input Delay per Session, beroende på vilken som finns, i perfmon.exe.

   Välj den aktuella processen eller sessionen och observera till att börja med med standardintervallet 1 sekund. Skilj på aggregerade instanser som slår ihop flera sessioner och värden för enskilda sessioner.

3. Reproducera åtgärden där inmatningen är långsam och jämför väntan i kön med tidpunkten för symtomen.

   För enskilda mätobjekt visar värdet den längsta väntetiden inom mätintervallet. Även om värdet är lågt kan fördröjning finnas kvar i bearbetningen efter att appen har hämtat indatat och i tiden tills resultatet kommer tillbaka till den lokala datorn.

Du kan undersöka om det väntas i indatakön på fjärrdatorn. Det är ett annat mått än den upplevda tiden, som omfattar tur och retur-trafiken och visningen lokalt. Se: betydelsen av maxvärde och mätintervall.

flowchart TB
    accTitle: Sträckan som User Input Delay mäter
    accDescr: Mätsträckan går från indatakön på fjärrdatorn tills appen hämtar indatat, och kommunikationen och skärmvisningen före och efter ingår inte.
    A["Indata kommer från lokal enhet"] --> B["Hamnar i indatakön"]
    B -->|"Detta mäts"| C["Appen hämtar indatat"]
    C --> D["Appbearbetning och skärmöverföring"]
    D --> E["Visas lokalt"]

Figur 14: Det som mäts är väntan i indatakön på fjärrdatorn. Det är inte samma sak som den totala tiden tills du ser resultatet lokalt.

Undersök skärmuppdateringar och överhoppade bildrutor

Förbered en åtgärd där skärmen uppdateras kontinuerligt, till exempel rullning. Om räknarna i RemoteFX Graphics finns tillgängliga och var de mäts behöver kontrolleras utifrån OS, värdkonfiguration och behörigheter. Här läser vi bara de räknare som finns tillgängliga. Det är ingen anvisning för att installera eller aktivera den gamla RemoteFX-funktionen. Se: villkor för Graphics-räknarna.

1. Kontrollera namnet på den aktuella sessionen med query session eller qwinsta och välj motsvarande räknarinstans.

2. Jämför Input Frames/Second och Output Frames/Second under en åtgärd med skärmuppdateringar.

   Om utdata är färre än indata hoppas bildrutor över på vägen. Kontrollera värdena för Frames Skipped/Second uppdelade på resursbrist på fjärrdatorn, i nätverket och i klienten.

3. Stäm av orsakerna till överhoppade bildrutor mot belastningen i båda ändar och i nätverket, och kontrollera även Average Encoding Time.

   Om kodningstiden är lång undersöker du komprimeringen på fjärrdatorn. Om antalet bildrutor redan är lågt på indatasidan kan det också bero på att appen inte uppdaterar skärmen särskilt ofta. Ett lågt antal bildrutor på en stillastående skärm är i sig inget fel.

Utifrån indata och utdata under skärmuppdatering, orsakerna till överhoppade bildrutor och kodningstiden kan du ringa in var du ska undersöka. Räknarnas kategorier är ledtrådar och bedöms tillsammans med den faktiska belastningen och anslutningskonfigurationen. Se: så läser du antal bildrutor och kodningstid.

flowchart TB
    accTitle: Ringa in utifrån överhoppade bildrutor
    accDescr: Jämför antalet bildrutor in och ut under en åtgärd med skärmuppdateringar och använd räknarna för orsaker till överhoppade bildrutor som ledtråd för att stämma av mot belastningen i bearbetning, nätverk och visning.
    A["Jämför in och ut vid rullning"] --> B["Färre ut: kontrollera överhopp"]
    B --> C["Titta på räknare per orsak"]
    C --> D["Stäm av mot fjärr-, nät- och lokal last"]

Figur 15: Jämför in- och utdata under rullning och stäm av orsakerna till överhoppade bildrutor mot belastningen på fjärrdatorn, i nätverket och lokalt.

Vi generaliserar inte konceptdiagram över skärmöverföring eller äldre dokumentation till alla konfigurationer. Det finns också konfigurationer där video och ljud överförs med en annan mekanism. Dokumentationen för Graphics-räknarna innehåller även beskrivningar av äldre konfigurationer, så vi tolkar inte siffrorna där som en gemensam specifikation om att ”all RDP har högst 30 fps”. Kontrollera vad funktionerna och siffrorna gäller för innan du använder dem. Se: skärmöverföring och arbetsbelastning, dokumentationen för Graphics-räknarna.

Vad mätresultaten täcker

Att ett värde är lågt likställs inte med att åtgärderna känns smidiga. Omfattningen för varje mått kan kontrolleras i den Microsoft-dokumentation som anges i stegen.

Nätverks- och GPU-inställningar

UDP- och GPU-inställningar väljer du utifrån det som jämförelser och mätningar har visat. Om kommunikationen verkar misstänkt kontrollerar du först anslutningsmetod och väg, och om skärmbearbetningen verkar misstänkt kontrollerar du först i vilka steg GPU:n används.

Kontrollera TCP/UDP och anslutningsvägen

Om jämförelser och mätningar pekar mot kommunikationen kontrollerar du tillsammans med administratören vilken klient, vilken väg och vilka tillämpade principer som används. Även när en inställningsändring behövs håller du dig inom godkända ramar och antecknar värdet före ändringen och hur det återställs. Stäng inte av brandväggen eller autentiseringen, och exponera inte RDP-porten direkt mot internet.

1. Kontrollera faktisk TCP/UDP och väg med anslutningsinformation, produktens diagnostikloggar och administratörens nätverksloggar.

   RDP använder TCP eller UDP beroende på konfiguration och nätverksförhållanden. I ”Select RDP transport protocols” kan du välja mellan en inställning som använder UDP eller TCP och en inställning med enbart TCP. Eftersom TCP också kan användas när en UDP-anslutning inte kan upprättas visar en lyckad anslutning ensam inte vilken metod som används. Se: val av RDP-transport och fallback.

2. Stäm av väg och metod mot tidpunkten för symtomen och jämför bara de inställningar som behövs, en i taget.

   Gör inga generella ändringar utifrån tanken att ”det blir snabbare om man stänger av UDP”. Se till att villkoren för VPN och gateway, åtgärden och visningsvillkoren är desamma när du jämför, och återställ onödiga ändringar.

När du känner till metod och väg kan du anteckna sambandet mellan ändringar och symtom. En ändring till enbart TCP gör inte alltid anslutningen snabbare.

flowchart TB
    accTitle: Kontrollera anslutningsmetoden innan nätverksinställningar jämförs
    accDescr: Skilj på vanliga direktanslutningar och anslutningar via gateway eller tjänst, kontrollera den faktiska vägen och metoden och gör sedan tillåtna jämförelser.
    A["Klient och anslutningskonfiguration"] --> B["Kontrollera väg och TCP/UDP"]
    B --> C["Stäm av mot symtomens tid"]
    C --> D["Jämför bara det nödvändiga, ett i taget"]

Figur 16: Kontrollera anslutningsmetoden och vägen som används, stäm av mot symtomen och jämför sedan bara de inställningar som behövs.

RDP Shortpath är en mekanism i Azure Virtual Desktop. Den upprättar en UDP-väg för tjänsten och använder beroende på konfiguration en direkt väg eller ett relä. Om vägen inte kan upprättas återgår den till en TCP-baserad anslutning. Den kan inte behandlas i samma inställningstabell som när du ansluter direkt till en dator i företaget med mstsc. Se: väg och fallback för RDP Shortpath.

flowchart TB
    accTitle: Väg och fallback för RDP Shortpath
    accDescr: RDP Shortpath i Azure Virtual Desktop försöker upprätta en UDP-väg. Om det lyckas används en direkt väg eller ett relä beroende på konfiguration, och om det inte lyckas återgår anslutningen till en TCP-baserad anslutning.
    A["RDP Shortpath"] --> B{"UDP-väg"}
    B -->|"Upprättad"| C["Direkt eller relä"]
    B -->|"Misslyckas"| D["Tillbaka till TCP-baserad"]

Figur 17: RDP Shortpath återgår till en TCP-baserad anslutning om UDP-vägen inte kan upprättas.

Kontrollera GPU-användningen i skärmbearbetningen

Kontrollera detta när jämförelser och mätningar pekar mot skärmbearbetningen. Gå igenom mätresultaten för skärmbearbetningen och vilka OS, drivrutiner, principer och klienter som stöds. Ändra inte inställningar bara för att det finns en GPU. Skaffa först administratörens godkännande och förbered återställningen.

1. Skilj på renderingen i appen på fjärrdatorn, RDP-kodningen och avkodningen lokalt, och välj det steg som verkar misstänkt.

   Även om det finns en GPU är det inte säkert att alla steg använder den. Även i Microsofts konfigurationsdokumentation för Azure Virtual Desktop konfigureras och kontrolleras rendering i fjärrsessionen och hårdvarukodning av bildrutor separat. Se: GPU-konfiguration och verifiering för rendering och kodning.

2. Kontrollera den faktiska användningen enligt anvisningarna för produkten och mät samma åtgärd före och efter nödvändiga ändringar.

   Om komprimeringstiden är lång undersöker du GPU-användningen för kodningen. Att ändra kodningsinställningar för en app som väntar i indatakön siktar på fel ställe. För textens läsbarhet respektive jämn video skiljer sig också valet mellan bildkvalitet, datamängd och bearbetningsbelastning. Se: skillnader beroende på arbetsbelastning.

Du kan anteckna inte bara om det finns en GPU, utan också om GPU:n används i det aktuella steget och hur belastning och respons för samma åtgärd förändrades. Ändringar som inte ger förbättring återställer du efter avstämning med administratören.

flowchart TB
    accTitle: Kontrollera GPU-användningen steg för steg
    accDescr: Skilj på renderingen i appen på fjärrdatorn, RDP-kodningen och avkodningen lokalt, och kontrollera användningen i det misstänkta steget, eftersom inte alla steg nödvändigtvis använder GPU:n även om det finns en.
    A["Rendering i appen på fjärrdatorn"] --> B["RDP-kodning"]
    B --> C["Lokal avkodning"]
    C -.- D["Kontrollera GPU per steg"]

Figur 18: Även om det finns en GPU är det inte säkert att rendering, kodning och avkodning alla använder den.

Omverifiering och överlämning

En förbättring bekräftas genom att samma åtgärd fungerar utan problem efter ändringen och att nödvändig bildkvalitet, nödvändiga enheter och verksamhetsfunktioner bevaras. Stäm också av mot resultatet efter återställning till de ursprungliga villkoren. Om det bara rör sig om en tillfällig återhämtning fastställer du inte orsaken, utan antecknar även tider med hög belastning och samtidiga processer.

flowchart TB
    accTitle: Ordningen för att bekräfta en förbättring
    accDescr: Visar att man efter ändringen kontrollerar att samma åtgärd fungerar utan problem och att nödvändig bildkvalitet, enheter och verksamhetsfunktioner bevaras, stämmer av mot resultatet efter återställning och inte fastställer orsaken utifrån en tillfällig återhämtning.
    A["Prova samma åtgärd efter ändring"] --> B["Kontrollera bild, enheter, funktioner"]
    B --> C["Jämför med återställt läge"]
    C -.- D["Tillfällig återhämtning räcker inte"]

Figur 19: Stäm av inte bara resultatet för samma åtgärd utan även nödvändiga funktioner och resultatet efter återställning.

Överlämning när problemet kvarstår

Även när det inte blir bättre, när problemet inte går att reproducera eller när räknarna inte är tillgängliga är det användbara resultat. Skilj på de jämförelser du kunde göra och de kontroller du inte kunde göra, och lämna över till administratörer och utvecklare med följande anteckning. Ta bort verksamhetsinformation som inte behövs för undersökningen, till exempel användarnamn och anslutningsmål, från loggar som delas.

Tidpunkt och tidszon när symtomet uppstod:
Fjärrdatorns OS, klient och version som används:
Direktanslutning/VPN/RD Gateway/Azure Virtual Desktop m.m.:
Långsam åtgärd och app, svar från andra appar i samma session:
Upplösning och antal bildskärmar på fjärrsidan:
Kopiering, utskrift m.m. som pågick samtidigt:
Det enda villkor som ändrades och resultatet efter återställning:
Belastning och räknare som observerades på fjärrdatorn och lokalt:

Komplettera även med om faktisk TCP/UDP kunde bekräftas, vilka punkter som inte kunde kontrolleras på grund av exempelvis otillräckliga behörigheter och vilka inställningar som är acceptabla i verksamheten. Att säga ”Anteckningar går att skriva i som vanligt, men det stannar när jag rullar bland foton” i stället för ”anslutningen är långsam” gör att nästa person kan undersöka under samma villkor.

Användaren sparar den åtgärd som reproducerar problemet och jämförelseresultaten, och administratören stämmer av loggarna för anslutningsväg, delad värd och sessioner. Att det väntas ovanpå RDP betyder inte i sig att det som orsakar väntan också är RDP. Se: ansvarsfördelning mellan värd och backend.

Appens utvecklare loggar mottagandet av indatahändelser, start och slut för databas- och filbearbetning och uppdateringen av UI:t var för sig. Överväg också en design där tungt arbete inte blir kvar i UI-tråden. Observera dock att en logg om att bearbetningen har slutförts på fjärrdatorn inte registrerar att visningen har slutförts lokalt. Se: att separera bearbetning för att hålla UI:t responsivt.

Relaterade artiklar

• Så förstår du sessionsisolering i Windows
• Felsök 100 % diskanvändning i Windows på ett säkert sätt
• Varför tar ”1 sekund kvar” aldrig slut?

Referenser

Det här är primärkällor från Microsoft Learn. Det refererade innehållet kontrollerades den 17 september 2026. Läs dem med villkoren för varje produkt i åtanke, och kom ihåg att det inte rör sig om mätningar som har utförts i den här artikeln.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Skillnaden mellan RTT och fördröjningen från skärmfångst på fjärrdatorn till visning lokalt. Själva diagnostikfunktionen är avsedd för Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Sambandet mellan skärminnehåll, upplösning, bilduppdatering, komprimering, cachelagring och datamängd.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Hur in- och utdata för skärmen, orsaker till överhoppade bildrutor och kodningstid kontrolleras. Dokumentet beskriver även äldre konfigurationer, så numeriska övre gränser generaliseras inte till all RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Belastningen på delade värdar, kommunikationen från fjärrdatorn till backend och effekten av enhetsomdirigering.
• Microsoft Learn, Threading model. UI-tråden och Dispatcher i WPF samt separering av bearbetning för att behålla responsen.
• Microsoft Learn, mstsc. Att ange bredd och höjd för fjärrskrivbordet och flera bildskärmar.
• Microsoft Learn, Supported RDP properties. Skillnaden mellan skrivbordsupplösning, dynamisk upplösning och smart sizing. Kontrollera vilka klienter som stöds och villkoren för varje produkt.
• Microsoft Learn, ping. Kontroll av svar med ICMP Echo och tillgängliga alternativ.
• Microsoft Learn, Test-NetConnection. Kontroll av TCP-anslutning och vad utdata betyder.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Mätsträckan för User Input Delay, OS som stöds, instanser och betydelsen av maxvärdet.
• Microsoft Learn, query session. Sessionsinformation och de behörigheter som krävs för att fråga efter andra sessioner.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Valet mellan TCP och UDP för RDP samt fallback.
• Microsoft Learn, RDP Shortpath. UDP-vägen för Azure Virtual Desktop och beteendet när den inte kan upprättas.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. GPU-konfiguration och verifiering separat för rendering och bildrutekodning.

Relaterade artiklar

De senaste artiklarna med samma taggar. Fördjupa dig i närliggande ämnen.

Relaterade ämnen

Ämnessidor som ligger nära det här temat. Utgå från artikeln och gå vidare till relaterade tjänster och andra artiklar.

Tjänster som hänger ihop med det här ämnet

Den här artikeln hör ihop med följande tjänstesidor. Välj den ingång som ligger närmast.

Vanliga frågor

Vanliga frågor om artikelns ämne som brukar komma upp när man rådfrågar oss.

Varför är inmatningen i RDP långsam när hastighetsmätningen visar flera hundra Mbit/s?

Hur snabbt stora datamängder kan transporteras och hur lång tid det tar innan en åtgärd ger svar är olika saker. Överföringen av indata, bearbetningen i appen på fjärrdatorn, komprimeringen av skärmbilden, överföringen och visningen lokalt spelar alla in. Dessutom skiljer sig vägen till hastighetsmätningens motpart från vägen till RDP-fjärrdatorn.

Det går att skriva som vanligt, men bara rullningen hackar. Är det ett problem med anslutningen?

Det går inte att begränsa till enbart anslutningen. När skärmuppdateringarna ökar kan det vara rendering och komprimering på fjärrdatorn, kommunikationen eller avkodning och visning lokalt som inte hinner med. Ändra upplösningen eller antalet bildskärmar på fjärrsidan ett i taget och jämför, och undersök vid behov de renderingsrelaterade räknarna.

Om ping är snabbt, fungerar RDP-kommunikationen då normalt?

Det räcker inte för att avgöra det. Ping mäter svar på ICMP och mäter inte RDP:s skärmöverföring eller appens bearbetning. I konfigurationer med RD Gateway och liknande stämmer vägen inte heller alltid överens. Om svar uteblir ska du också skilja på blockerad ICMP och att RDP i sig inte går att nå.

Är User Input Delay tiden från tangenttryckning tills tecknet syns?

Nej. Det är en räknare som mäter väntetiden från det att indata hamnar i kön på fjärrdatorn tills processen hämtar ut dem. Den är inte den upplevda fördröjningen som omfattar tur och retur-trafiken, appens bearbetning efter uthämtningen och komprimering, avkodning och visning av skärmbilden.

Ska jag inaktivera UDP när RDP är trögt?

Vi rekommenderar det inte generellt. Kontrollera först den faktiska anslutningsmetoden, vägen och de principer som tillämpas. Anslutningen kan ha fallit tillbaka till TCP eftersom UDP inte kan användas, och en ändring till enbart TCP gör den inte alltid snabbare. Jämför under samma villkor med administratörens tillstånd och återställ onödiga ändringar.

Författarprofil

Profilsidan för artikelns författare.

Go Komura

Företrädare för KomuraSoft LLC

Arbetar med Windows-programvaruutveckling, teknisk rådgivning och felsökning, med särskild styrka i projekt med befintliga tillgångar och i utredning av fel vars orsak är svår att se.