Hvorfor er RDP treg når forbindelsen er rask? – undersøk inndata, skjermbehandling og nettverk hver for seg

Hastighetstesten viser flere hundre Mbps, men i Eksternt skrivebord dukker tegnene likevel opp litt forsinket. Når du ruller på en side med mange bilder, hakker skjermen. En forretningsapp står bare stille i noen sekunder når du trykker på søk. Hvor bør man begynne å undersøke en slik situasjon der «forbindelsen er rask, men RDP er treg»?

Hvor raskt RDP reagerer på handlingene dine, avgjøres ikke av forbindelsens overføringshastighet alene. Selv om hastighetstesten er rask, kan det oppstå venting et sted underveis: i nettverkets rundtur, mens inndataene venter på appen på den eksterne maskinen, i kodingen av skjermbildet eller i dekodingen og visningen lokalt. Finn først ut «hvilken handling som er treg», og sammenlign så den samme handlingen mens du endrer én betingelse om gangen. Snevre inn undersøkelsen med sammenligninger og målinger, og velg innstillinger for UDP og GPU ut fra resultatet. Se: måleintervaller for forbindelseskvalitet, ytelsesfaktorer på øktverter.

Når du har snevret inn hvor det skal undersøkes, er den grunnleggende årsaken likevel ikke fastslått. Selv om det blir bedre når du senker oppløsningen, endres ikke bare nettverkstrafikken, men også skjermbehandlingen i begge ender, så vi konkluderer ikke med at «forbindelsen var årsaken». Resultatene noteres slik at strekningene som er målt, holdes atskilt fra dem som ikke er målt.

Denne artikkelen avgrenser forsinkelser i inndata, rulling og appens respons etter at forbindelsen er opprettet. Selv om symptomene ligner hverandre, er det ikke nødvendigvis bare én årsak. Hvis «det tar lang tid før påloggingsskjermen vises» eller «det bare stopper opp ved godkjenningen», behandles det som et annet problem, som undersøkes ut fra loggene for oppretting av forbindelse og godkjenning.

Artikkelen er først og fremst skrevet for brukere og administratorer som kobler til Windows 11 eller Windows Server med «Tilkobling til eksternt skrivebord» (mstsc) i Windows. Kommandoeksemplene er for Windows PowerShell 5.1. Det forutsettes at du kan gjenskape den samme handlingen i en økt som allerede er tilkoblet.

Ved direkte tilkobling, VPN, RD Gateway og Azure Virtual Desktop er ruten, den tilgjengelige diagnoseinformasjonen og det innstillingene gjelder for, forskjellige. Eksempelet med kontroll av TCP 3389 gjelder bare en tillatt direkte tilkobling til en RDP-vert som bruker standardporten. Diagnosefunksjoner og GPU-innstillinger fra dokumentasjon for Azure Virtual Desktop overføres ikke uendret til vanlige PC-er i bedriften.

På bedriftens enheter undersøker du bare innenfor det administratoren har tillatt. På en delt vert må du identifisere din egen økt og prosessen det gjelder, og trenger du data om andre brukere, ber du administratoren om dem. Om ytelsestellerne er tilgjengelige, hva de heter, og hvilke rettigheter som kreves, kontrolleres i hvert miljø.

Kontrollmetodene her bygger på offisiell dokumentasjon. De er ikke en rapport om målinger der en feil ble gjenskapt og løst på en bestemt enhet. Talleksempler som er antakelser for forklaringens skyld, er tydelig merket som det.

Mekanismen kan leses i rekkefølge fra neste avsnitt, «Overføringshastighet og rundturstid». Vil du begynne ut fra symptomet, går du til «Den første sammenligningen ut fra symptomet». Framgangsmåtene står i «Sammenlign én betingelse om gangen» og «Mål hvor ventetiden oppstår».

I diagrammet markerer en heldekkende linje en relasjon som alltid gjelder, og en stiplet linje en betinget relasjon (vilkårene står for hver relasjon på detaljsiden). Den fullstendige listen over relasjoner (7 i alt, med belegg og sikkerhet) og definisjonene av de viktigste begrepene finner du på detaljsiden for kunnskapskartet (på japansk). Data: JSON-LD / Turtle

Overføringshastighet og rundturstid

RDP (Remote Desktop Protocol) er en protokoll som utveksler inndata, skjermdata og annet mellom den lokale enheten din og den eksterne maskinen. Den håndterer ikke bare skjerm og inndata, men også data for enhetsomdirigering, utskrift og lignende. Se: hvilke data RDP overfører.

Forbindelsens overføringshastighet angir hvor mye data som kan fraktes per sekund. «500 Mbps» i en hastighetstest er et tall for denne mengden. Det er ikke et tall for hvor lang tid det går fra du utfører en handling, til svaret kommer. Se: båndbreddekrav for RDP.

flowchart TB
    accTitle: Hva tallet fra hastighetstesten viser
    accDescr: Viser at 500 Mbps i en hastighetstest er et tall for datamengden som kan fraktes per sekund, og et annet tall enn tiden fra en handling utføres til svaret kommer.
    A["Hastighetstest: 500 Mbps"] --> B["Datamengde per sekund"]
    B -.->|"Et annet tall"| C["Tid til svaret kommer"]

Figur 1: Tallet fra hastighetstesten viser mengden som kan fraktes, ikke tiden til svaret kommer.

Rundturstiden (RTT) er tiden det tar for data å nå fram til motparten og tilbake igjen. Forskjellen mellom å øke overføringshastigheten og å korte ned rundturstiden ligner forskjellen mellom å gi en vei flere kjørefelt og å gjøre avstanden til målet kortere. Selv om kapasiteten til å frakte store mengder filer øker, blir ventetiden på svar på handlingene dine værende hvis rundturstiden er den samme. Se: RTT og forsinkelse i skjermvisningen.

flowchart TB
    accTitle: Overføringshastighet og rundturstid sammenlignet med en vei
    accDescr: Figuren sammenligner det å øke overføringshastigheten med å gi veien flere kjørefelt og det å korte ned rundturstiden med å gjøre avstanden til målet kortere.
    A["Øk overføringshastigheten"] -->|"På en vei"| B["Flere kjørefelt"]
    B ~~~ C["Kort ned rundturstiden"]
    C -->|"På en vei"| D["Kortere avstand"]

Figur 2: Flere kjørefelt gjør ikke avstanden til målet kortere.

Ett tegns vei fram og tilbake

Tenk deg at du skriver ett tegn i Notisblokk på den eksterne maskinen. Notisblokk kjører på den eksterne maskinen. Hvis vi for forklaringens skyld antar at det tar 50 millisekunder før handlingen når fram, og 50 millisekunder før de resulterende skjermdataene kommer tilbake, brukes det totalt 100 millisekunder, altså 0,1 sekund, på nettverket. Behandlingstiden i begge ender er holdt utenfor dette eksempelet.

flowchart TB
    accTitle: Eksempel på nettverkstid til resultatet av ett tegn kommer tilbake
    accDescr: Et eksempel der veien fram og veien tilbake for forklaringens skyld hver antas å ta 50 millisekunder. Behandlingstiden i begge ender er ikke tatt med, og figuren viser heller ikke antallet pakker per tast.
    A["Ett tegn skrives lokalt"] -->|"Fram: 50 ms"| B["Ekstern maskin mottar inndata"]
    B --> C["Skjerm med inndata sendes"]
    C -->|"Tilbake: 50 ms"| D["Resultatet når fram lokalt"]

Figur 3: Hvis veien fram antas å ta 50 millisekunder og veien tilbake 50 millisekunder, tar nettverket alene 0,1 sekund. Det er ikke en målt verdi.

Selv om forbindelsen kan frakte mer, blir disse 0,1 sekundene værende så lenge rundturstiden er uendret. Figur 3 er en prinsippskisse som skal gjøre forløpet forståelig. Den betyr ikke at det sendes en egen pakke fram og tilbake for hver tast. Ruten til motparten i hastighetstesten og ruten til den eksterne RDP-maskinen er også forskjellige, så VPN, gatewayer, opplastingskapasiteten på den eksterne maskinens side og trengsel underveis må tas med i vurderingen. Se: hvordan RTT skal forstås, nettverkets og vertens ytelse.

Oppbygging og levering av skjermbildet

Med forsinket respons på handlinger menes her ventetiden fra du utfører en handling lokalt, til du kan se resultatet. Ikke bare RTT, men også appens behandling og arbeidet med å bygge opp og levere skjermbildet spiller inn. Det må også holdes atskilt fra forsinkelsen på selve overføringsstrekningen for skjermbildet. Se: målestrekningen fra innhenting av skjermbildet til visning.

Når inndataene når fra den lokale enheten din til den eksterne maskinen, behandler appen på den eksterne maskinen dem og oppdaterer skjermen. De kodede skjermdataene fraktes over forbindelsen og blir dekodet og vist lokalt. Både før og etter nettverket finnes det arbeid som to forskjellige PC-er står for. Se: behandlingen fra innhenting av skjermbildet til visning.

flowchart TB
    accTitle: Det finnes også skjermbehandling før og etter forbindelsen
    accDescr: Forløpet der inndata fra den lokale enheten når den eksterne maskinen, appen der behandler dem, skjermbildet bygges opp og komprimeres, og skjermdataene som er fraktet over forbindelsen, gjøres klare til visning og vises lokalt.
    I["Lokalt: brukeren gir inndata"] --> J["Forbindelse: inndata fraktes"]
    J --> K["Ekstern maskin: appen behandler"]
    K --> A["Ekstern maskin: bilde bygges og komprimeres"]
    A --> B["Forbindelse: skjermdata fraktes"]
    B --> C["Lokalt: gjøres klart til visning"]
    C --> D["Vises på den lokale skjermen"]

Figur 4: Behandling og komprimering på den eksterne maskinen, frakt over forbindelsen og gjenoppretting for visning lokalt er oppgaver som utføres på forskjellige steder.

Med koding menes i denne artikkelen behandlingen der den eksterne maskinen konverterer og komprimerer skjermbildet til en form som er lett å sende. Den tar behandlingstid på den eksterne maskinen, uavhengig av overføringen over forbindelsen. Se: kodingstid på den eksterne maskinen.

Med dekoding menes i denne artikkelen behandlingen der de mottatte skjermdataene lokalt gjøres om til en form som kan vises. Det må holdes atskilt fra dekryptering i betydningen å oppheve kryptering. Se: dekoding og visningstid lokalt.

Tar komprimeringen på den eksterne maskinen tid, venter sendingen på å bli klar selv om forbindelsen er ledig. Selv når dataene har kommet fram, blir oppdateringen forsinket hvis dekodingen eller visningen lokalt ikke henger med. Det er ikke alltid slik at «PC-en på jobben er kraftig, så den lokale enheten spiller ingen rolle». Ledig kapasitet på forbindelsen og ledig kapasitet til behandlingen i begge ender er to forskjellige ting. Se: ytelsestellere for skjermbehandling.

flowchart TB
    accTitle: Forsinkelse når behandlingen i begge ender ikke henger med
    accDescr: Viser at sendingen venter selv om forbindelsen er ledig hvis komprimeringen på den eksterne maskinen tar tid, og at oppdateringen forsinkes selv om dataene har kommet fram hvis dekoding eller visning lokalt ikke henger med.
    A["Komprimering på ekstern maskin tar tid"] --> B["Sending venter trass i ledig forbindelse"]
    B ~~~ C["Lokal dekoding henger ikke med"]
    C --> D["Oppdatering forsinkes trass i mottatte data"]

Figur 5: Selv med ledig kapasitet på forbindelsen blir skjermoppdateringen forsinket hvis behandlingen i begge ender ikke henger med.

Forskjellen på tekstinntasting og rulling

Når du legger til ett tegn i Notisblokk, endres bare en liten del av skjermen. Når du ruller på en side med mange bilder, endres visningen over et stort område gang på gang. RDP begrenser datamengden ved å overføre de endrede delene og ved å bruke komprimering og hurtigbufring som passer til innholdet. Den sender ikke hele skjermen ukomprimert hver gang. Arbeidsmengden avhenger av skjermens innhold og av hvor ofte den oppdateres. Se: sammenhengen mellom skjerminnhold og båndbredde.

flowchart TB
    accTitle: Skjermarbeidet ved tekstinntasting og ved rulling
    accDescr: En liten endring av tekst og en vedvarende oppdatering av et stort område gir forskjellige typer arbeid med å bygge opp og sende skjermbildet.
    A{"Endring på skjermen"} -->|"Ett tegn legges til"| B["Lite område"]
    A -->|"Rulling"| D["Stort område, fortløpende"]
    B --> E["Komprimeres og overføres etter endringen"]
    D --> E

Figur 6: Selv på samme forbindelse er arbeidsmengden forskjellig når ett tegn legges til, og når et stort område fortsetter å bevege seg.

Selv om et dokument som står stille, er lett, kan skjermoverføringen gå tom for ledig kapasitet under rulling. Øker du oppløsningen eller antallet skjermer på den eksterne siden, blir skjermbildet som skal behandles, også større. En sammenligning med lavere oppløsning er et forsøk som viser om bevegelsen blir normal igjen når arbeidet med å bygge opp og sende skjermbildet reduseres. Det er ikke en beregning som fastsetter datamengden ut fra antallet piksler alene. Se: virkningen av oppløsning, skjermoppdateringer og komprimering.

Venting i appen

Hvis bare søket i forretningsappen står stille i noen sekunder mens du kan skrive normalt i Notisblokk i samme økt, bør du undersøke hva appen venter på. Appen på den eksterne maskinen kan sende et søk videre til en annen database eller lese en fil fra en delt mappe og vente på svaret. Det er en annen rute enn RDP-trafikken mellom den lokale enheten din og den eksterne maskinen. Se: trafikk fra den eksterne maskinen til backend.

flowchart TB
    accTitle: Det finnes også motparter bak RDP
    accDescr: Viser at appen på den eksterne maskinen, uavhengig av forbindelsen mellom den lokale enheten og den eksterne maskinen, kan vente på svar fra en forretningsserver.
    A["Lokal enhet"] -->|"RDP"| B["Forretningsapp på ekstern maskin"]
    B -->|"Søk, filforespørsel"| C["Database, delt mappe"]
    C -->|"Svar det ventes på"| B

Figur 7: Forretningsappen bak RDP kan selv vente på svar fra en annen server.

Når delen som står for skjerm og inndata, er opptatt med et langvarig arbeid, blir neste inndata og neste skjermoppdatering forsinket. I WPF svekkes for eksempel responsen hvis UI-tråden er opptatt lenge. Lav samlet CPU-bruk er ikke i seg selv nok til å utelukke venting i en bestemt UI-tråd. Se: Dispatcher og UI-tråden.

flowchart TB
    accTitle: Delen som står for skjerm og inndata, blir sittende fast
    accDescr: Viser at neste inndata og skjermoppdatering forsinkes når delen som står for skjerm og inndata, er opptatt med et langvarig arbeid, og at lav samlet CPU-bruk ikke alene kan utelukke den ventingen.
    A["Del som står for skjerm og inndata"] --> B["Opptatt med langt arbeid"]
    B --> C["Neste inndata og oppdatering forsinkes"]
    C -.- D["Lav samlet CPU utelukker det ikke"]

Figur 8: Venting i UI-tråden kan ikke utelukkes ut fra den samlede CPU-bruken alene.

Den første sammenligningen ut fra symptomet

Mengden som kan fraktes, tiden det ventes på svar, og tiden det tar å bygge opp og vise skjermbildet, er tre forskjellige ting. Holder du dem atskilt, kan du undersøke ut fra handlingen som er treg akkurat nå, i stedet for å forklare «RDP er treg» med én enkelt årsak.

flowchart TB
    accTitle: Skill de tre før du undersøker
    accDescr: Viser at man i stedet for å forklare «RDP er treg» med én årsak skiller mengden som kan fraktes, ventetiden på svar og tiden til å bygge opp og vise skjermbildet, og undersøker ut fra handlingen som er treg nå.
    A["«RDP er treg»"] --> S
    subgraph S["Ses hver for seg"]
    direction TB
    B["Mengde som kan fraktes"] ~~~ C["Ventetid på svar"]
    C ~~~ D["Tid til å bygge og vise bildet"]
    end
    S --> E["Undersøk handlingen som er treg nå"]

Figur 9: Når mengden som kan fraktes, ventetiden på svar og tiden til å bygge opp og vise skjermbildet holdes atskilt, kan du undersøke ut fra handlingen som er treg nå.

Målet med avgrensningen er å begrense hvor tregheten skal undersøkes. Målet er ikke å endre mange innstillinger på én gang og tilfeldigvis gjøre det raskere. Bruker du forskjeller som «Notisblokk fungerer, men bare søket står stille» eller «tekstinntasting er normal, men bare rulling er tung», kan du velge et utgangspunkt for undersøkelsen allerede før du endrer nettverksinnstillingene.

Tabellen nedenfor er et utgangspunkt for undersøkelsen. Den er ikke en tabell for å avgjøre årsaken. Sammenlign først handlinger i samme økt, og endre deretter den enheten, den ruten eller de visningsbetingelsene det er nødvendig å endre.

Tegn kommer forsinket i flere apper

Hvis tegnene kommer forsinket ett og ett i flere apper i samme økt, sammenligner du den samme handlingen fra en annen enhet eller via en annen tillatt rute. Hold rundturstiden, ventingen på inndata på den eksterne maskinen og den samlede belastningen på den eksterne maskinen opp mot hverandre, og ikke fastslå årsaken ut fra ett enkelt tall.

Bare rulling hakker

Selv om tekstinntastingen er normal, gir rulling på en side med mange bilder vedvarende skjermoppdateringer over et stort område. Endre oppløsningen eller antallet skjermer på den eksterne siden én ting om gangen, og sammenlign på den samme siden. Blir det bedre, er komprimeringen på den eksterne maskinen, skjermoverføringen og den lokale dekodingen de neste tingene å undersøke. Oppløsningen alene forteller ikke hvilken av de tre som er årsaken. Se: belastning avhengig av skjerminnhold og oppløsning.

Bare én app fryser

Hvis bare forretningsappen der du trykket på søk, står stille, sammenligner du om Notisblokk eller lignende i samme økt reagerer. Kjører andre apper, undersøker du først den aktuelle appens behandling, disken og forespørslene til databasen eller den delte mappen. At du jobber via RDP, er ikke det samme som at RDP-trafikken er årsaken til ventingen. Se: ytelsesfaktorer i apper og backend.

Alle er trege når det er mange brukere

Blir det tregt for flere brukere i samme tidsrom, spør du administratoren om situasjonen i de andre øktene. Belastningen på den delte vertens CPU, minne og lagring og på den delte forbindelsen holdes opp mot tidspunktet for symptomet. Ikke gå inn i andre brukeres data eller prosesser uten tillatelse, og ikke stopp jobbene deres. Se: den delte vertens ressurser og antall brukere.

Tregt under kopiering eller utskrift

Faller problemene sammen med tidspunktet da du selv startet en kopiering eller utskrift, setter du bare de overføringene du har tillatelse til å stoppe, på pause, og sammenligner. Noter om det blir normalt igjen etter pausen, og om det blir tregt når du gjenopptar, og undersøk konkurranse med andre overføringer enn skjermen og med enhetsomdirigering. Ikke gjør sammenligninger der enheter som trengs i arbeidet, deaktiveres samlet. Se: virkningen av enhetsomdirigering.

Sammenlign én betingelse om gangen

Det er ikke nødvendig å endre alle innstillingene etter tur. Lag først et grunnlag for sammenligningen, og velg bare kontrollene som passer til symptomet. Lagre arbeidet ditt før du endrer innstillinger eller kobler til på nytt, og noter de opprinnelige verdiene og hvordan de settes tilbake. Har du ikke de nødvendige rettighetene eller funksjonene, skal du ikke tvinge gjennom en aktivering, men overlate saken til administratoren.

Lokal betjening og betjening via RDP skjer ikke nødvendigvis under de samme betingelsene. At det går raskt på den eksterne maskinens fysiske skjerm, er nyttig informasjon, men økten og betingelsene for gjengivelse kan være annerledes. Gjør bruker, data og appens tilstand like, og ikke begrens årsaken til forbindelsen bare fordi «det går raskt på den fysiske skjermen».

Sammenlign samme handling

Forbered samme bruker, samme data og samme handling. På en delt vert kontrollerer du din egen økt, og du stopper ikke andre brukeres apper eller prosesser. Bruk av en annen enhet eller en annen rute er også begrenset til det administratoren har tillatt.

1. Gjenskap den trege handlingen med de opprinnelige innstillingene, og noter tidspunkt og symptom.

   Skriv omtrent like mye tekst i Notisblokk i den samme eksterne økten som den problematiske appen. Skill mellom om det bare gjelder én app eller hele økten.

2. Kontroller belastningen på den eksterne maskinen og lokalt i samme tidsrom.

   Se i Oppgavebehandling på den aktuelle appens CPU, minne og disk på den eksterne maskinen og på RDP-klientens belastning lokalt. Kontroller den aktuelle prosessen og ikke bare den samlede CPU-verdien. Se: hvor belastningen skal undersøkes.

3. Endre bare én av betingelsene – en annen enhet, en annen tillatt rute eller visningsbetingelsene – og gjenta den samme handlingen.

   Endres den eksterne maskinens eller appens tilstand samtidig i sammenligningen, noterer du også den forskjellen. Et resultat der flere betingelser er endret, regnes ikke som virkningen av én enkelt betingelse.

4. Sett betingelsen tilbake til den opprinnelige, og kontroller den samme handlingen på nytt.

   Er det fortsatt raskt etter tilbakestillingen, kan det for eksempel også skyldes en midlertidig endring i belastningen. Ikke gå ut fra at endringen virket, men noter under hvilke betingelser symptomet kan gjenskapes.

Du har nå resultater fra den opprinnelige tilstanden, etter endringen og etter tilbakestillingen og kan sammenligne hvilke betingelser som henger sammen med symptomet. En betingelse som ga en forbedring, er et spor i undersøkelsen og er ikke i seg selv et bevis på den grunnleggende årsaken.

flowchart TB
    accTitle: Begrens betingelsene som endres på én gang
    accDescr: Forløpet der man velger en handling som gjenskapes i den opprinnelige tilstanden, endrer bare én betingelse, sammenligner og også kontrollerer resultatet etter tilbakestilling.
    A["Samme handling med opprinnelige innstillinger"] --> B["Endre bare én betingelse"]
    B --> C["Gjenta samme handling"]
    C --> D["Sett tilbake og kontroller igjen"]
    D --> E["Noter betingelsen som hjalp"]

Figur 10: Gjenta den samme handlingen i den opprinnelige tilstanden, etter endringen og etter tilbakestillingen, og noter betingelsen som gjorde en forskjell.

Sammenlign oppløsningen på den eksterne siden

Denne sammenligningen brukes når skjermoppdateringer, for eksempel ved rulling, er tunge. Noter oppløsningen og antallet skjermer før endringen, og lagre arbeidet ditt før du kobler til på nytt. Ikke fortsett å bruke innstillinger som svekker den skjermplassen eller den lesbarheten av tekst som arbeidet krever.

1. Endre bare enten antallet skjermer eller oppløsningen.

   I mstsc kan du sammenligne med innstillingene under fanen «Skjerm» før tilkobling eller ved å angi bredde og høyde. Se: skjerminnstillinger i mstsc.

2. Kontroller at det eksterne skrivebordets faktiske størrelse er endret, og rull på den samme siden.

   Gjør du bare vinduet mindre lokalt, kan det være et stort skrivebord som bare vises forminsket. Skill mellom dynamisk oppløsning og smart sizing, og kontroller hva klienten du bruker, støtter. Se: skrivebordsoppløsning og skalering.

3. Sett innstillingen tilbake, gjenta den samme handlingen, og sammenlign belastningen i begge ender og skjermens bevegelse.

   Har du byttet til lav oppløsning og én skjerm samtidig, er det bare en grov sammenligning. Blir det bedre, setter du én ting tilbake om gangen for å skille virkningene fra hverandre.

Blir det bedre, finnes sporet innenfor skjermbehandling og skjermoverføring. 3840×2160 har fire ganger så mange piksler som 1920×1080, men datamengden blir ikke alltid fire ganger så stor. Den avhenger av de endrede delene og av komprimeringen, og en endret oppløsning påvirker også behandlingen i begge ender. Se: sammenhengen mellom antall piksler og datamengde, kontroll av skjermbehandlingen.

flowchart TB
    accTitle: Hva en sammenligning med lavere oppløsning kan vise
    accDescr: Når oppløsningen på den eksterne siden senkes, kan belastningen både i skjermbehandlingen og i overføringen endre seg, så en forbedring alene ikke kan begrense årsaken til forbindelsen.
    A["Senk oppløsningen på den eksterne siden"] --> S
    subgraph S["Behandling som endres"]
    direction TB
    B["Skjermbehandling på ekstern maskin"] ~~~ C["Mengde data som sendes"]
    C ~~~ D["Lokal visningsbehandling"]
    end

Figur 11: En endret oppløsning er en sammenligning som ikke bare påvirker forbindelsen, men også skjermbehandlingen på den eksterne maskinen og lokalt.

Hold kopiering og utskrift opp mot symptomet

Sett bare prosesser du har tillatelse til å stoppe, på pause, for eksempel overføringer du selv har startet. Bedriftens sikkerhetskopierings- og sikkerhetsprosesser og andre brukeres jobber stoppes ikke. Omdirigering av lyd- og inndataenheter som arbeidet krever, deaktiveres ikke samlet.

1. Noter den samme handlingen og belastningen før og mens kopiering, skysynkronisering eller utskrift pågår.

   I tillegg til skjermen går det også data for stasjoner, skrivere og lignende gjennom RDP. Omdirigering som gjør lokale enheter tilgjengelige på den eksterne maskinen, kan øke belastningen på nettverk og behandling mens den er i bruk. Se: virkningen av enhetsomdirigering.

2. Sett den aktuelle overføringen på pause innenfor det som er tillatt, og kontroller den samme handlingen på nytt.

   Kan du gjenoppta og sammenligne, noterer du også symptomet etter gjenopptakelsen. Prøver du endringer av unødvendig enhetsomdirigering, endrer du også dem én om gangen og sørger for at du kan gå tilbake til de opprinnelige innstillingene.

Du kan nå vurdere om starten på overføringen henger sammen med problemene, og pausen med bedringen. Ser du en sammenheng, holder du andre overføringer enn skjermen og belastningen på delte ressurser opp mot administratorens logger.

flowchart TB
    accTitle: Se på tiden før og etter problemet på samme tidsakse
    accDescr: Noter den samme handlingen og belastningen før overføringen, under den og etter pausen, og sammenlign forholdet mellom problemet og arbeidet.
    A["Handling og belastning før overføring"] --> B["Handling og belastning under overføring"]
    B --> C["Handling og belastning etter stopp"]
    C --> D["Henger problem og bedring sammen?"]

Figur 12: Se hvordan tregheten i den samme handlingen og belastningen endrer seg før overføringen, under den og etter stoppet.

Mål hvor ventetiden oppstår

Lokalt undersøker du nettverkets rundtur og TCP-tilkoblingen, og på den eksterne maskinen ventingen i inndatakøen og skjermoppdateringene. Hvert tall måler bare en begrenset strekning, så les resultatene sammen med tabellen i «Hva måleresultatene dekker».

Kontroller ICMP og TCP-tilkoblingen

Dette kjøres på den lokale Windows-enheten din. Det gjelder bare oppsett der du via bedriftens LAN eller et tillatt VPN kobler direkte til en RDP-vert som bruker standardporten TCP 3389. Ved tilkobling via RD Gateway eller Azure Virtual Desktop eller ved oppsett med en annen port må du avtale med administratoren hva som skal kontrolleres. Porter åpnes ikke, og brannmuren endres ikke.

1. Skriv inn den tillatte eksterne maskinen, og noter resultatene for ICMP-svar og TCP-tilkobling.

   $target = Read-Host 'Navn eller IP-adresse for RDP-verten du har tillatelse til å undersøke'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Angi maskinen du vil koble til.'
   }
       
   # Se på ICMP-svartiden over flere forsøk. En feil alene betyr ikke at RDP ikke kan nås.
   ping.exe -n 20 $target
       
   # Kontroll som bare gjelder oppsett med direkte tilkobling til standardporten TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Hold resultatene fra det trege tidsrommet og fra normal drift opp mot tidspunktet for symptomet og den faktiske tilkoblingsruten.

   20 kjøringer av ping er en kort observasjon. Noter variasjoner i verdiene og manglende svar, men vær oppmerksom på at ICMP kan være blokkert. Ikke utelukk periodiske stopp ut fra gjennomsnittsverdien alene, men bruk tilkoblingsinformasjon og administratorens nettverkslogger. Se: hva ping måler.

TcpTestSucceeded: True betyr at TCP-tilkoblingen til den angitte porten lyktes. Båndbredde, UDP, handlinger etter godkjenning og hvor jevnt skjermen beveger seg, er ikke målt. Test-NetConnection har ingen bryter -UDP som undersøker UDP. Se: syntaks og resultater for Test-NetConnection.

Vurder resultatene med forskjellene i rute og tjeneste for øye. Med RD Gateway og lignende er ruten for ICMP eller en direkte TCP-tilkobling til verten ikke alltid den samme som den faktiske RDP-ruten. I Azure Virtual Desktop kan du bruke RTT og estimert båndbredde for hver tilkobling, men den diagnosefunksjonen er beregnet på akkurat den tjenesten. Korte stopp utelukkes ikke ut fra gjennomsnittsverdier alene. Se: logger for tilkoblingskvalitet i Azure Virtual Desktop.

flowchart TB
    accTitle: Den kontrollerte ruten og den faktiske RDP-ruten
    accDescr: I oppsett med RD Gateway og lignende er ruten for ICMP eller en direkte TCP-tilkobling fra den lokale enheten til verten ikke alltid den samme som den faktiske RDP-ruten.
    A["Lokal enhet"] -->|"ICMP, direkte TCP"| C["RDP-vert"]
    A -->|"Faktisk RDP"| B["RD Gateway o.l."]
    B --> C

Figur 13: ICMP eller en direkte TCP-tilkobling til verten og den faktiske RDP-tilkoblingen følger ikke alltid samme rute.

Mål ventetiden i inndatakøen

User Input Delay måler ventetiden fra inndata kommer i kø på den eksterne maskinen, til prosessen henter dem. Det er ikke den samlede tiden fra du trykker på en tast, til tegnet kan ses. Se: definisjonen av User Input Delay.

Undersøkelsen gjøres i den eksterne økten på den eksterne maskinen. Ifølge Microsoft støttes Windows 10 versjon 1809 og nyere samt Windows Server 2019 og nyere. På disse versjonene er det ikke nødvendig å legge til en verdi i registeret for å aktivere telleren. Kontroller visningsnavn, rettigheter og om telleren finnes, og er den ikke tilgjengelig, noterer du det og kontakter administratoren. Se: støttede versjoner og innstillinger.

1. Noter tidspunktet og økt-ID-en i PowerShell i samme økt.

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

   Det kan kreve ekstra rettigheter å spørre etter andre brukeres økter. Standardnavnet på forekomsten for den aktuelle prosessen er SessionID:ProcessID <Process Image>. Unngå å blande sammen verdier fra andre brukere eller fra prosesser med samme navn ved bare å gå etter økt-ID-en. Se: rettigheter for query session, identifisering av forekomster.

2. Legg til den tilgjengelige User Input Delay per Process eller User Input Delay per Session i perfmon.exe.

   Velg den aktuelle prosessen eller økten, og observer i første omgang med standardintervallet på 1 sekund. Skill mellom den samlede forekomsten som samler flere økter, og verdiene for de enkelte øktene.

3. Gjenskap handlingen der inndata er tregt, og sammenlign ventetiden i køen med tidspunktet for symptomet.

   For de enkelte måleobjektene viser verdien den lengste ventetiden innenfor måleintervallet. Selv om verdien er lav, kan det fortsatt være forsinkelse i behandlingen etter at appen har hentet inndataene, og fram til resultatet når tilbake til den lokale enheten.

Du kan undersøke om det ventes i inndatakøen på den eksterne maskinen. Det er et annet mål enn den opplevde tiden, som omfatter nettverkets rundtur og visningen lokalt. Se: betydningen av maksimumsverdien og måleintervallet.

flowchart TB
    accTitle: Strekningen User Input Delay måler
    accDescr: Målestrekningen går fra inndatakøen på den eksterne maskinen til appen henter inndataene, og omfatter ikke nettverket eller skjermvisningen før og etter.
    A["Inndata kommer fra lokal enhet"] --> B["Inndata kommer i kø på ekstern maskin"]
    B -->|"Dette måles"| C["Appen henter inndataene"]
    C --> D["Appbehandling og skjermoverføring"]
    D --> E["Vises lokalt"]

Figur 14: Det som måles, er ventingen i inndatakøen på den eksterne maskinen. Det er ikke det samme som den samlede tiden til resultatet kan ses lokalt.

Undersøk skjermoppdateringer og årsaker til utelatte frames

Forbered en handling med vedvarende skjermoppdateringer, for eksempel rulling. Om RemoteFX Graphics-tellerne er tilgjengelige, og hvor det måles, må kontrolleres ut fra operativsystem, vertsoppsett og rettigheter. Her leser du bare tellerne som er tilgjengelige. Det er ikke en veiledning i å installere eller aktivere den gamle RemoteFX-funksjonen. Se: betingelser for Graphics-tellerne.

1. Finn navnet på den aktuelle økten med query session eller qwinsta, og velg den tilsvarende tellerforekomsten.

2. Sammenlign Input Frames/Second og Output Frames/Second under en handling med skjermoppdateringer.

   Er output lavere enn input, blir frames hoppet over underveis. Kontroller verdiene for Frames Skipped/Second fordelt på ressursmangel på den eksterne maskinen, i nettverket og i klienten.

3. Hold årsakene til de utelatte frames opp mot belastningen i begge ender og på nettverket, og kontroller også Average Encoding Time.

   Er kodingstiden lang, undersøker du komprimeringen på den eksterne maskinen. Er antallet frames lavt allerede på inputsiden, er det også mulig at appen ikke oppdaterer skjermen ofte. Et lavt antall frames på en skjerm som står stille, er ikke i seg selv unormalt.

Ut fra input og output under skjermoppdateringer, årsakene til utelatte frames og kodingstiden kan du snevre inn hvor det skal undersøkes. Tellernes inndeling er et spor som må vurderes sammen med den faktiske belastningen og tilkoblingsoppsettet. Se: slik leses antall frames og kodingstid.

flowchart TB
    accTitle: Snevre inn undersøkelsen ut fra utelatte frames
    accDescr: Under en handling med skjermoppdateringer sammenlignes antallet input- og outputframes, og med tellerne for årsaker til utelatte frames som spor holdes de opp mot belastningen i behandling, nettverk og visning.
    A["Sammenlign input og output under rulling"] --> B["Færre output: kontroller utelatelser"]
    B --> C["Se tellerne for hver årsak"]
    C --> D["Hold opp mot belastning: ekstern, nett, lokal"]

Figur 15: Sammenlign input og output under rulling, og hold årsakene til utelatte frames opp mot belastningen på den eksterne maskinen, forbindelsen og den lokale enheten.

Prinsippskisser av skjermoverføringen og eldre dokumentasjon generaliseres ikke til alle oppsett. Det finnes også oppsett der video og lyd overføres via en annen mekanisme. Dokumentasjonen for Graphics-tellerne beskriver også eldre oppsett, så tallene der tolkes ikke om til en felles spesifikasjon om at «all RDP kjører med høyst 30 fps». Kontroller hva funksjoner og tall gjelder for, før du bruker dem. Se: skjermoverføring og arbeidsbelastninger, dokumentasjonen for Graphics-tellerne.

Hva måleresultatene dekker

Et lavt tall er ikke det samme som at betjeningen føles behagelig. Hva hvert mål dekker, kan du kontrollere i Microsoft-dokumentasjonen det er vist til i framgangsmåtene.

Nettverks- og GPU-innstillinger

Innstillinger for UDP og GPU velges ut fra det sammenligningene og målingene har vist. Er nettverket mistenkt, kontrollerer du først transportprotokollen og ruten, og er skjermbehandlingen mistenkt, kontrollerer du først i hvilke trinn GPU-en brukes.

Kontroller TCP/UDP og tilkoblingsruten

Peker sammenligninger og målinger mot nettverket, går du sammen med administratoren gjennom klienten du bruker, ruten og policyene som gjelder. Er det nødvendig å endre innstillinger, skjer det bare innenfor det som er godkjent, og verdiene før endringen og metoden for gjenoppretting noteres. Brannmur og godkjenning deaktiveres ikke, og RDP-porten eksponeres ikke direkte mot internett.

1. Kontroller den faktiske bruken av TCP/UDP og ruten ut fra tilkoblingsinformasjon, produktets diagnoselogger og administratorens nettverkslogger.

   RDP bruker TCP eller UDP avhengig av oppsett og nettverksforhold. I «Select RDP transport protocols» kan du velge mellom en innstilling som bruker UDP eller TCP, og en innstilling som bare bruker TCP. Siden RDP også kan bruke TCP hvis en UDP-tilkobling ikke kan opprettes, forteller en vellykket tilkobling alene ikke hvilken protokoll som brukes. Se: valg av RDP-transport og fallback.

2. Hold tidspunktet for symptomet opp mot ruten og protokollen, og sammenlign bare de nødvendige innstillingene én om gangen.

   Ikke endre innstillingene generelt ut fra tanken om at «det blir raskere hvis UDP slås av». Sammenlign med like betingelser for VPN og gateway, handling og visning, og sett unødvendige endringer tilbake.

Når du kjenner protokollen og ruten, kan du notere sammenhengen mellom endringen og symptomet. En endring til bare TCP gjør ikke alltid forbindelsen raskere.

flowchart TB
    accTitle: Kontroller transportprotokollen før nettverksinnstillinger sammenlignes
    accDescr: Skill mellom vanlig direkte tilkobling og tilkobling via gateway eller tjeneste, og kontroller den faktiske ruten og protokollen før en tillatt sammenligning utføres.
    A["Klient og tilkoblingsoppsett"] --> B["Kontroller faktisk rute og TCP/UDP"]
    B --> C["Hold opp mot symptomets tidspunkt"]
    C --> D["Sammenlign bare nødvendige innstillinger én om gangen"]

Figur 16: Kontroller transportprotokollen og ruten som brukes, hold dem opp mot symptomet, og sammenlign først deretter bare de nødvendige innstillingene.

RDP Shortpath er en mekanisme i Azure Virtual Desktop. Den oppretter en UDP-rute for tjenesten og bruker avhengig av oppsettet en direkte rute eller et relé. Kan ruten ikke opprettes, faller den tilbake til en TCP-basert tilkobling. Den kan ikke behandles i samme innstillingstabell som en direkte tilkobling med mstsc til en PC i bedriften. Se: ruter og fallback for RDP Shortpath.

flowchart TB
    accTitle: Ruter og fallback for RDP Shortpath
    accDescr: RDP Shortpath i Azure Virtual Desktop prøver å opprette en UDP-rute. Lykkes det, brukes en direkte rute eller et relé avhengig av oppsettet, og lykkes det ikke, faller den tilbake til en TCP-basert tilkobling.
    A["RDP Shortpath"] --> B{"UDP-rute"}
    B -->|"Opprettet"| C["Direkte eller relé"]
    B -->|"Ikke opprettet"| D["Tilbake til TCP-basert"]

Figur 17: Kan RDP Shortpath ikke opprette en UDP-rute, faller den tilbake til en TCP-basert tilkobling.

Kontroller GPU-bruk i skjermbehandlingen

Denne kontrollen brukes når sammenligninger og målinger peker mot skjermbehandlingen. Gå gjennom måleresultatene for skjermbehandlingen og støttede operativsystemer, drivere, policyer og klienter. Innstillinger endres ikke bare fordi det finnes en GPU i maskinen. Innhent først administratorens godkjenning, og forbered hvordan du kan gå tilbake.

1. Skill mellom appens gjengivelse på den eksterne maskinen, RDPs koding og den lokale dekodingen, og velg trinnet som er mistenkt.

   Selv om det finnes en GPU, bruker ikke nødvendigvis alle trinn den. Også i Microsofts konfigurasjonsdokumentasjon for Azure Virtual Desktop konfigureres og kontrolleres gjengivelse i den eksterne økten og maskinvarekoding av frames hver for seg. Se: GPU-konfigurasjon og -kontroll av gjengivelse og koding.

2. Kontroller den faktiske bruken etter veiledningen for det aktuelle produktet, og mål den samme handlingen før og etter de nødvendige endringene.

   Er komprimeringstiden lang, undersøker du GPU-bruken til koding. Endrer du kodingsinnstillingene for en app som venter i inndatakøen, treffer du feil sted. Lesbar tekst og jevn video krever også forskjellige avveininger mellom bildekvalitet, datamengde og behandlingsbelastning. Se: forskjeller avhengig av arbeidsbelastning.

Du kan nå notere ikke bare om det finnes en GPU, men også om GPU-en brukes i det problematiske trinnet, og hvordan belastningen og responsen for den samme handlingen har endret seg. Endringer uten forbedring settes tilbake etter avtale med administratoren.

flowchart TB
    accTitle: Kontroller GPU-bruken trinn for trinn
    accDescr: Skill mellom appens gjengivelse på den eksterne maskinen, RDPs koding og den lokale dekodingen, og kontroller bruken i det mistenkte trinnet, fordi ikke alle trinn nødvendigvis bruker GPU-en selv om det finnes en.
    A["Appens gjengivelse på ekstern maskin"] --> B["RDP-koding"]
    B --> C["Lokal dekoding"]
    C -.- D["Kontroller GPU-bruk for hvert trinn"]

Figur 18: Selv om det finnes en GPU, bruker ikke nødvendigvis gjengivelse, koding og dekoding den alle sammen.

Ny kontroll og overlevering

En forbedring bekreftes ved at den samme handlingen kan utføres uten problemer etter endringen, og ved at den nødvendige bildekvaliteten, de nødvendige enhetene og forretningsfunksjonene beholdes. Sammenhold også med resultatet etter tilbakestilling til de opprinnelige betingelsene. Er det bare en kortvarig bedring, fastslås ikke årsaken, og travle tidsrom og samtidige prosesser noteres også.

flowchart TB
    accTitle: Rekkefølgen for å bekrefte en forbedring
    accDescr: Viser at man etter endringen kontrollerer om den samme handlingen kan utføres uten problemer, og om den nødvendige bildekvaliteten, enhetene og forretningsfunksjonene beholdes, holder det opp mot resultatet etter tilbakestilling og ikke fastslår årsaken ut fra en kortvarig bedring alene.
    A["Prøv samme handling etter endring"] --> B["Kontroller bildekvalitet, enheter, funksjoner"]
    B --> C["Hold opp mot resultat etter tilbakestilling"]
    C -.- D["Kortvarig bedring fastslår ingenting"]

Figur 19: I tillegg til resultatet av den samme handlingen holdes de nødvendige funksjonene og resultatet etter tilbakestilling også opp mot hverandre.

Overlevering når problemet ikke er løst

Også når det ikke blir noen forbedring, når feilen ikke kan gjenskapes, eller når tellerne ikke er tilgjengelige, er resultatet nyttig. Skill mellom sammenligningene du kunne utføre, og kontrollene du ikke kunne, og overlever til administratorer og utviklere med notatet nedenfor. Fjern forretningsinformasjon som brukernavn og eksterne maskiner som ikke er nødvendig for undersøkelsen, fra loggene du deler.

Tidspunkt og tidssone for symptomet:
Den eksterne maskinens OS, klient og versjon:
Direkte tilkobling/VPN/RD Gateway/Azure Virtual Desktop osv.:
Treg handling og app, reaksjon i andre apper i samme økt:
Oppløsning og antall skjermer på den eksterne siden:
Kopiering, utskrift osv. som kjørte samtidig:
Den ene endrede betingelsen og resultatet etter tilbakestilling:
Belastning og tellere observert på ekstern maskin og lokalt:

Legg også til om den faktiske bruken av TCP/UDP kunne bekreftes, hvilke punkter som ikke kunne kontrolleres, for eksempel på grunn av manglende rettigheter, og hvilke innstillinger som er akseptable for arbeidet. Skriver du «Notisblokk kan brukes normalt, men det stopper opp når jeg ruller gjennom bilder» i stedet for «forbindelsen er treg», kan neste ansvarlige undersøke under de samme betingelsene.

Brukeren noterer handlingen som gjenskaper problemet, og resultatene av sammenligningene, og administratoren holder loggene for tilkoblingsruten, den delte verten og øktene opp mot hverandre. At det ventes inne i RDP, betyr ikke i seg selv at det også er RDP som forårsaker ventingen. Se: arbeidsdelingen mellom vert og backend.

Apputviklere logger mottaket av inndatahendelser, start og slutt på database- og filbehandling og oppdateringen av brukergrensesnittet hver for seg. De vurderer også et design der tungt arbeid ikke blir hengende i UI-tråden. En logg over at behandlingen er fullført på den eksterne maskinen, registrerer likevel ikke at visningen er fullført lokalt. Se: atskillelse av behandling for å bevare brukergrensesnittets respons.

Relaterte artikler

• Slik forstår du øktisolasjon i Windows
• Trygg feilsøking av 100 % diskbruk i Windows
• Hvorfor tar «1 sekund igjen» aldri slutt?

Referanser

Det følgende er primærkilder fra Microsoft Learn. Innholdet ble kontrollert 17. september 2026. Les dem med tanke på hva som gjelder for hvert produkt, og på at de ikke er målinger som er utført i forbindelse med denne artikkelen.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. RTT og forskjellen på forsinkelsen fra innhenting av skjermbildet på den eksterne maskinen til visning lokalt. Selve diagnosefunksjonen er beregnet på Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Sammenhengen mellom skjerminnhold, oppløsning, frameoppdatering, komprimering, hurtigbufring og datamengde.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Slik kontrolleres skjermens input og output, årsaker til utelatte frames og kodingstid. Siden den også beskriver eldre oppsett, generaliseres ikke de numeriske grensene til all RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Belastning på delte verter, trafikk fra den eksterne maskinen til backend og virkningen av enhetsomdirigering.
• Microsoft Learn, Threading model. UI-tråden og Dispatcher i WPF samt atskillelse av behandling for å bevare responsen.
• Microsoft Learn, mstsc. Angivelse av bredde og høyde for det eksterne skrivebordet og av flere skjermer.
• Microsoft Learn, Supported RDP properties. Forskjellen mellom skrivebordsoppløsning, dynamisk oppløsning og smart sizing. Kontroller hvilke klienter som støtter dem, og hva som gjelder for hvert produkt.
• Microsoft Learn, ping. Kontroll av svar med ICMP Echo og kommandoens alternativer.
• Microsoft Learn, Test-NetConnection. Kontroll av TCP-tilkobling og betydningen av utdataene.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Målestrekningen for User Input Delay, støttede operativsystemer, forekomster og betydningen av maksimumsverdien.
• Microsoft Learn, query session. Øktinformasjon og rettighetene som kreves for å spørre etter andre økter.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Valg av TCP/UDP for RDP og fallback.
• Microsoft Learn, RDP Shortpath. UDP-ruter for Azure Virtual Desktop og hva som skjer når de ikke kan opprettes.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. GPU-konfigurasjon og -kontroll der gjengivelse og framekoding holdes atskilt.

Relaterte artikler

Nyere artikler med de samme taggene. Fordyp deg i beslektede emner.

Relaterte temaer

Dette er temasider som ligger nær temaet for artikkelen. Med artikkelen som utgangspunkt kan du gå videre til relaterte tjenester og andre artikler.

Tjenester knyttet til dette temaet

Denne artikkelen henger sammen med følgende tjenestesider. Se dem gjennom den inngangen som ligger nærmest.

Ofte stilte spørsmål

Vanlige spørsmål ved rådgivning om temaet for denne artikkelen.

Hvorfor er inndata i RDP tregt når hastighetstesten viser flere hundre Mbps?

Hastigheten som store datamengder fraktes med, og tiden det tar før en handling får respons, er to forskjellige ting. Sending av inndata, behandling i appen på den eksterne maskinen, komprimering av skjermbildet, overføring og visning lokalt spiller alle inn. I tillegg er nettverksruten til motparten i hastighetstesten og til den eksterne RDP-maskinen forskjellige.

Jeg kan skrive normalt, men bare rulling hakker. Er det forbindelsen som er problemet?

Det kan ikke snevres inn til forbindelsen alene. Når skjermoppdateringene blir flere, kan et av leddene henge etter: gjengivelse og komprimering på den eksterne maskinen, nettverket eller dekoding og visning lokalt. Endre oppløsningen eller antallet skjermer på den eksterne siden én om gangen, sammenlign, og undersøk ved behov tellerne som gjelder gjengivelsen.

Er RDP-forbindelsen i orden hvis ping er rask?

Det kan ikke avgjøres ut fra det alene. Ping måler svaret på ICMP og måler verken RDPs skjermoverføring eller appens behandling. I oppsett med RD Gateway og lignende er ruten heller ikke alltid den samme. Også når det ikke kommer noe svar, må du skille mellom blokkert ICMP og en RDP-forbindelse som faktisk ikke fungerer.

Er User Input Delay tiden fra jeg trykker på en tast til tegnet vises?

Nei. Det er en teller som måler ventetiden fra inndata kommer i kø på den eksterne maskinen, til prosessen henter dem. Det er ikke den opplevde forsinkelsen som omfatter nettverkets rundtur, appens behandling etter hentingen og komprimering, dekoding og visning av skjermbildet.

Bør jeg deaktivere UDP når RDP er treg?

Det anbefales ikke generelt. Kontroller først den faktiske transportprotokollen, ruten og hvilke policyer som gjelder. Noen ganger kan ikke UDP brukes, og forbindelsen har allerede falt tilbake til TCP, og en endring til bare TCP gjør det ikke alltid raskere. Sammenlign med like betingelser med administratorens tillatelse, og sett unødvendige endringer tilbake.

Om forfatteren

Profilside for artikkelens forfatter.

Go Komura

Representant for KomuraSoft LLC

Arbeider særlig med Windows-programvareutvikling, teknisk rådgivning og feilsøking, og har sin styrke i prosjekter med eksisterende systemer og i undersøkelse av feil der årsaken er vanskelig å se.