Hvorfor er RDP langsom, når forbindelsen er hurtig? – undersøg input, skærmbehandling og netværk hver for sig

Hastighedstesten viser flere hundrede Mbps, men i Fjernskrivebord dukker tegnene alligevel lidt forsinket op. Når du ruller på en side med mange billeder, hakker skærmen. En forretningsapp står kun stille i nogle sekunder, når du trykker på søg. Hvor skal man begynde at undersøge sådan en situation, hvor »forbindelsen er hurtig, men RDP er langsom«?

Hvor hurtigt RDP reagerer på dine handlinger, afgøres ikke af forbindelsens overførselshastighed alene. Selv om hastighedstesten er hurtig, kan der opstå ventetid et sted undervejs: i netværkets rundtur, mens inputtet venter på appen på fjerncomputeren, i kodningen af skærmbilledet eller i afkodningen og visningen lokalt. Afgør først, »hvilken handling der er langsom«, og sammenlign så den samme handling, mens du ændrer én betingelse ad gangen. Indsnævr undersøgelsen med sammenligninger og målinger, og vælg indstillinger for UDP og GPU ud fra resultatet. Se: måleintervaller for forbindelseskvalitet, ydelsesfaktorer på sessionsværter.

Når du har indsnævret, hvor der skal undersøges, er den grundlæggende årsag dog stadig ikke fastslået. Selv hvis det bliver bedre, når du sænker opløsningen, ændres ikke kun netværkstrafikken, men også skærmbehandlingen i begge ender, så vi konkluderer ikke, at »forbindelsen var årsagen«. Resultaterne noteres, så de strækninger, der er målt, holdes adskilt fra dem, der ikke er målt.

Denne artikel afgrænser forsinkelser i input, rulning og appens respons, efter at forbindelsen er oprettet. Selv om symptomerne ligner hinanden, er der ikke nødvendigvis kun én årsag. Hvis »der går lang tid, før logonskærmen vises«, eller »det kun går i stå ved godkendelsen«, behandles det som et andet problem, der undersøges ud fra logfilerne for oprettelse af forbindelse og godkendelse.

Artiklen henvender sig primært til brugere og administratorer, der opretter forbindelse til Windows 11 eller Windows Server med »Forbindelse til Fjernskrivebord« (mstsc) i Windows. Kommandoeksemplerne er til Windows PowerShell 5.1. Det forudsættes, at du kan genskabe den samme handling i en session, der allerede er forbundet.

Ved direkte forbindelse, VPN, RD Gateway og Azure Virtual Desktop er ruten, de tilgængelige diagnoseoplysninger og det, indstillingerne gælder for, forskellige. Eksemplet med kontrol af TCP 3389 gælder kun en tilladt direkte forbindelse til en RDP-vært, der bruger standardporten. Diagnosefunktioner og GPU-indstillinger fra dokumentation til Azure Virtual Desktop overføres ikke uændret til almindelige pc’er i virksomheden.

På virksomhedens enheder undersøger du kun inden for det, administratoren har tilladt. På en delt vært skal du identificere din egen session og den proces, det drejer sig om, og har du brug for data om andre brugere, så bed administratoren om dem. Om ydelsestællerne er tilgængelige, hvad de hedder, og hvilke rettigheder der kræves, kontrolleres i hvert miljø.

Kontrolmetoderne her bygger på officiel dokumentation. De er ikke en rapport om målinger, hvor en fejl blev genskabt og løst på en bestemt enhed. Taleksempler, der er antagelser til forklaringen, angives tydeligt som sådanne.

Mekanismen kan læses i rækkefølge fra det næste afsnit, »Overførselshastighed og rundturstid«. Vil du begynde ud fra symptomet, så gå til »Den første sammenligning ud fra symptomet«. Fremgangsmåderne står i »Sammenlign én betingelse ad gangen« og »Mål, hvor ventetiden opstår«.

I diagrammet markerer en fuldt optrukket linje en relation, der altid gælder, og en stiplet linje en betinget relation (betingelserne står for hver relation på detaljesiden). Den fulde liste over relationer (7 i alt, med belæg og sikkerhed) og definitionerne af de vigtigste begreber er samlet på detaljesiden for vidensoversigten (på japansk). Data: JSON-LD / Turtle

Overførselshastighed og rundturstid

RDP (Remote Desktop Protocol) er en protokol, der udveksler input, skærmdata og andet mellem din lokale enhed og fjerncomputeren. Den håndterer ikke kun skærm og input, men også data til enhedsomdirigering, udskrivning og lignende. Se: hvilke data RDP overfører.

Forbindelsens overførselshastighed angiver, hvor meget data der kan transporteres pr. sekund. »500 Mbps« i en hastighedstest er et tal for denne mængde. Det er ikke et tal for, hvor lang tid der går, fra du udfører en handling, til svaret kommer. Se: båndbreddekrav til RDP.

flowchart TB
    accTitle: Hvad tallet fra hastighedstesten viser
    accDescr: Viser, at 500 Mbps i en hastighedstest er et tal for den datamængde, der kan transporteres pr. sekund, og et andet tal end tiden, fra en handling udføres, til svaret kommer.
    A["Hastighedstest: 500 Mbps"] --> B["Datamængde pr. sekund"]
    B -.->|"Et andet tal"| C["Tid, til svaret kommer"]

Figur 1: Tallet fra hastighedstesten viser den mængde, der kan transporteres, ikke tiden, til svaret kommer.

Rundturstiden (RTT) er den tid, det tager for data at nå frem til modparten og tilbage igen. Forskellen mellem at øge overførselshastigheden og at forkorte rundturstiden svarer til forskellen mellem at give en vej flere vognbaner og at gøre afstanden til målet kortere. Selv om kapaciteten til at transportere store mængder filer vokser, består ventetiden på svar på dine handlinger, hvis rundturstiden er den samme. Se: RTT og forsinkelse i skærmvisningen.

flowchart TB
    accTitle: Overførselshastighed og rundturstid sammenlignet med en vej
    accDescr: Figuren sammenligner det at øge overførselshastigheden med at give vejen flere vognbaner og det at forkorte rundturstiden med at gøre afstanden til målet kortere.
    A["Øg overførselshastigheden"] -->|"På en vej"| B["Flere vognbaner"]
    B ~~~ C["Forkort rundturstiden"]
    C -->|"På en vej"| D["Kortere afstand"]

Figur 2: Flere vognbaner gør ikke afstanden til målet kortere.

Ét tegns vej frem og tilbage

Forestil dig, at du skriver ét tegn i Notesblok på fjerncomputeren. Notesblok kører på fjerncomputeren. Hvis vi til forklaringen antager, at det tager 50 millisekunder for handlingen at nå frem og 50 millisekunder for de resulterende skærmdata at komme tilbage, bruges der i alt 100 millisekunder, altså 0,1 sekund, på netværket. Behandlingstiden i begge ender er udeladt i dette eksempel.

flowchart TB
    accTitle: Eksempel på netværkstid, til resultatet af ét tegn kommer tilbage
    accDescr: Et eksempel, hvor vejen frem og vejen tilbage til forklaringen hver antages at tage 50 millisekunder. Behandlingstiden i begge ender er ikke medregnet, og figuren viser heller ikke antallet af pakker pr. tast.
    A["Ét tegn skrives lokalt"] -->|"Frem: 50 ms"| B["Fjerncomputeren modtager input"]
    B --> C["Skærm med input sendes"]
    C -->|"Tilbage: 50 ms"| D["Resultatet når frem lokalt"]

Figur 3: Hvis vejen frem antages at tage 50 millisekunder og vejen tilbage 50 millisekunder, tager netværket alene 0,1 sekund. Det er ikke en målt værdi.

Selv om forbindelsen kan transportere mere, består disse 0,1 sekund, så længe rundturstiden er uændret. Figur 3 er en principskitse, der skal gøre forløbet forståeligt. Den betyder ikke, at der sendes en selvstændig pakke frem og tilbage for hver tast. Ruten til hastighedstestens modpart og ruten til RDP-fjerncomputeren er også forskellige, så VPN, gateways, uploadkapaciteten på fjerncomputerens side og trængsel undervejs skal med i overvejelserne. Se: sådan skal RTT forstås, netværkets og værtens ydeevne.

Dannelse og levering af skærmbilledet

Med forsinket respons på handlinger menes her ventetiden, fra du udfører en handling lokalt, til du kan se resultatet. Ikke kun RTT, men også appens behandling og arbejdet med at danne og levere skærmbilledet spiller ind. Det skal også holdes adskilt fra forsinkelsen på selve overførselsstrækningen for skærmbilledet. Se: målestrækningen fra indfangning af skærmbilledet til visning.

Når inputtet når fra din lokale enhed til fjerncomputeren, behandler appen på fjerncomputeren det og opdaterer skærmen. De kodede skærmdata transporteres over forbindelsen og bliver afkodet og vist lokalt. Både før og efter netværket er der arbejde, som to forskellige pc’er står for. Se: behandlingen fra indfangning af skærmbilledet til visning.

flowchart TB
    accTitle: Der er også skærmbehandling før og efter forbindelsen
    accDescr: Forløbet, hvor input fra den lokale enhed når fjerncomputeren, appen på fjerncomputeren behandler det, skærmbilledet dannes og komprimeres, og de skærmdata, der er transporteret over forbindelsen, gøres klar til visning og vises lokalt.
    I["Lokalt: brugeren giver input"] --> J["Forbindelse: input transporteres"]
    J --> K["Fjerncomputer: appen behandler"]
    K --> A["Fjerncomputer: billede dannes og komprimeres"]
    A --> B["Forbindelse: skærmdata transporteres"]
    B --> C["Lokalt: gøres klar til visning"]
    C --> D["Vises på den lokale skærm"]

Figur 4: Behandling og komprimering på fjerncomputeren, transport over forbindelsen og gendannelse til visning lokalt er opgaver, der udføres forskellige steder.

Med kodning menes i denne artikel den behandling, hvor fjerncomputeren konverterer og komprimerer skærmbilledet til en form, der er nem at sende. Den tager behandlingstid på fjerncomputeren, uafhængigt af overførslen over forbindelsen. Se: kodningstid på fjerncomputeren.

Med afkodning menes i denne artikel den behandling, hvor de modtagne skærmdata lokalt gendannes til en form, der kan vises. Det skal holdes adskilt fra dekryptering i betydningen ophævelse af kryptering. Se: afkodning og visningstid lokalt.

Tager komprimeringen på fjerncomputeren tid, venter afsendelsen på at blive klar, selv om forbindelsen er ledig. Selv når dataene er nået frem, bliver opdateringen forsinket, hvis afkodningen eller visningen lokalt ikke kan følge med. Det er ikke altid sådan, at »pc’en i firmaet er kraftig, så den lokale enhed er ligegyldig«. Ledig kapacitet på forbindelsen og ledig kapacitet til behandlingen i begge ender er to forskellige ting. Se: ydelsestællere for skærmbehandling.

flowchart TB
    accTitle: Forsinkelse, når behandlingen i begge ender ikke kan følge med
    accDescr: Viser, at afsendelsen venter, selv om forbindelsen er ledig, hvis komprimeringen på fjerncomputeren tager tid, og at opdateringen forsinkes, selv om dataene er nået frem, hvis afkodning eller visning lokalt ikke kan følge med.
    A["Komprimering på fjerncomputer tager tid"] --> B["Afsendelse venter trods ledig forbindelse"]
    B ~~~ C["Lokal afkodning kan ikke følge med"]
    C --> D["Opdatering forsinkes trods modtagne data"]

Figur 5: Selv med ledig kapacitet på forbindelsen bliver skærmopdateringen forsinket, hvis behandlingen i begge ender ikke kan følge med.

Forskellen på tekstinput og rulning

Når du tilføjer ét tegn i Notesblok, ændres kun en lille del af skærmen. Når du ruller på en side med mange billeder, ændres visningen over et stort område igen og igen. RDP begrænser datamængden ved at overføre de ændrede dele og ved at bruge komprimering og caching, der passer til indholdet. Den sender ikke hele skærmen ukomprimeret hver gang. Arbejdsmængden afhænger af skærmens indhold og af, hvor ofte den opdateres. Se: sammenhængen mellem skærmindhold og båndbredde.

flowchart TB
    accTitle: Skærmarbejdet ved tekstinput og ved rulning
    accDescr: En lille ændring af tekst og en vedvarende opdatering af et stort område giver forskellige typer arbejde med at danne og sende skærmbilledet.
    A{"Ændring på skærmen"} -->|"Ét tegn tilføjes"| B["Lille område"]
    A -->|"Rulning"| D["Stort område, løbende"]
    B --> E["Komprimeres og overføres efter ændringen"]
    D --> E

Figur 6: Selv på samme forbindelse er arbejdsmængden forskellig, når ét tegn tilføjes, og når et stort område bliver ved med at bevæge sig.

Selv om et stillestående dokument er let, kan skærmoverførslen løbe tør for ledig kapacitet under rulning. Øger du opløsningen eller antallet af skærme på fjernsiden, bliver det skærmbillede, der skal behandles, også større. En sammenligning med lavere opløsning er et forsøg, der viser, om bevægelsen bliver normal igen, når arbejdet med at danne og sende skærmbilledet mindskes. Det er ikke en beregning, der fastlægger datamængden ud fra antallet af pixels alene. Se: virkningen af opløsning, skærmopdateringer og komprimering.

Ventetid i appen

Hvis kun søgningen i forretningsappen står stille i nogle sekunder, mens du kan skrive normalt i Notesblok i samme session, så undersøg, hvad appen venter på. Appen på fjerncomputeren kan sende en søgning videre til en anden database eller læse en fil fra en delt mappe og vente på svaret. Det er en anden rute end RDP-trafikken mellem din lokale enhed og fjerncomputeren. Se: trafik fra fjerncomputeren til backend.

flowchart TB
    accTitle: Der er også modparter bag RDP
    accDescr: Viser, at appen på fjerncomputeren, uafhængigt af forbindelsen mellem den lokale enhed og fjerncomputeren, kan vente på svar fra en forretningsserver.
    A["Lokal enhed"] -->|"RDP"| B["Forretningsapp på fjerncomputer"]
    B -->|"Søgning, filanmodning"| C["Database, delt mappe"]
    C -->|"Svar, der ventes på"| B

Figur 7: Forretningsappen bag RDP kan selv vente på svar fra en anden server.

Når den del, der står for skærm og input, er optaget af et langvarigt stykke arbejde, bliver næste input og næste skærmopdatering forsinket. I WPF forringes responsen for eksempel, hvis UI-tråden er optaget i lang tid. Et lavt samlet CPU-forbrug er ikke i sig selv nok til at udelukke ventetid i en bestemt UI-tråd. Se: Dispatcher og UI-tråden.

flowchart TB
    accTitle: Den del, der står for skærm og input, sætter sig fast
    accDescr: Viser, at næste input og skærmopdatering forsinkes, når den del, der står for skærm og input, er optaget af et langvarigt arbejde, og at et lavt samlet CPU-forbrug ikke alene kan udelukke den ventetid.
    A["Del, der står for skærm og input"] --> B["Optaget af langt arbejde"]
    B --> C["Næste input og opdatering forsinkes"]
    C -.- D["Lavt samlet CPU udelukker det ikke"]

Figur 8: Ventetid i UI-tråden kan ikke udelukkes ud fra det samlede CPU-forbrug alene.

Den første sammenligning ud fra symptomet

Den mængde, der kan transporteres, tiden, der ventes på svar, og tiden, det tager at danne og vise skærmbilledet, er tre forskellige ting. Holder du dem adskilt, kan du undersøge ud fra den handling, der er langsom lige nu, i stedet for at forklare »RDP er langsom« med én enkelt årsag.

flowchart TB
    accTitle: Adskil de tre, før du undersøger
    accDescr: Viser, at man i stedet for at forklare »RDP er langsom« med én årsag adskiller mængden, der kan transporteres, ventetiden på svar og tiden til at danne og vise skærmbilledet og undersøger ud fra den handling, der er langsom nu.
    A["»RDP er langsom«"] --> S
    subgraph S["Ses hver for sig"]
    direction TB
    B["Mængde, der kan transporteres"] ~~~ C["Ventetid på svar"]
    C ~~~ D["Tid til at danne og vise billedet"]
    end
    S --> E["Undersøg den handling, der er langsom nu"]

Figur 9: Når mængden, der kan transporteres, ventetiden på svar og tiden til at danne og vise skærmbilledet holdes adskilt, kan du undersøge ud fra den handling, der er langsom nu.

Målet med afgrænsningen er at begrænse, hvor langsomheden skal undersøges. Målet er ikke at ændre mange indstillinger på én gang og tilfældigvis gøre det hurtigere. Bruger du forskelle som »Notesblok virker, men kun søgningen står stille« eller »tekstinput er normalt, men kun rulning er tung«, kan du vælge et udgangspunkt for undersøgelsen, allerede før du ændrer netværksindstillingerne.

Tabellen nedenfor er et udgangspunkt for undersøgelsen. Den er ikke en tabel til at afgøre årsagen. Sammenlign først handlinger i samme session, og ændr derefter den enhed, den rute eller de visningsbetingelser, det er nødvendigt at ændre.

Tegn kommer forsinket i flere apps

Hvis tegnene kommer forsinket ét ad gangen i flere apps i samme session, så sammenlign den samme handling fra en anden enhed eller via en anden tilladt rute. Hold rundturstiden, ventetiden på input på fjerncomputeren og den samlede belastning på fjerncomputeren op mod hinanden, og fastslå ikke årsagen ud fra ét enkelt tal.

Kun rulning hakker

Selv om tekstinput er normalt, giver rulning på en side med mange billeder vedvarende skærmopdateringer over et stort område. Ændr opløsningen eller antallet af skærme på fjernsiden én ting ad gangen, og sammenlign på den samme side. Bliver det bedre, er komprimeringen på fjerncomputeren, skærmoverførslen og den lokale afkodning de næste ting at undersøge. Opløsningen alene fortæller ikke, hvilken af de tre der er årsagen. Se: belastning afhængigt af skærmindhold og opløsning.

Kun én app fryser

Hvis kun den forretningsapp, hvor du trykkede på søg, står stille, så sammenlign, om Notesblok eller lignende i samme session reagerer. Kører andre apps, undersøger du først den pågældende apps behandling, disken og anmodningerne til databasen eller den delte mappe. At du arbejder via RDP, er ikke det samme som, at RDP-trafikken er årsagen til ventetiden. Se: ydelsesfaktorer i apps og backend.

Alle er langsomme, når der er mange brugere

Bliver det langsomt for flere brugere i samme tidsrum, så spørg administratoren om situationen i de andre sessioner. Belastningen på den delte værts CPU, hukommelse og lager og på den delte forbindelse holdes op mod tidspunktet for symptomet. Tilgå ikke andre brugeres data eller processer uden tilladelse, og stop ikke deres job. Se: den delte værts ressourcer og antal brugere.

Langsomt under kopiering eller udskrivning

Falder problemerne sammen med det tidspunkt, hvor du selv startede en kopiering eller udskrivning, så sæt kun de overførsler, du har tilladelse til at stoppe, på pause, og sammenlign. Notér, om det bliver normalt igen efter pausen, og om det bliver langsomt, når du genoptager, og undersøg konkurrence med andre overførsler end skærmen og med enhedsomdirigering. Lav ikke sammenligninger, hvor enheder, der er nødvendige i arbejdet, deaktiveres samlet. Se: virkningen af enhedsomdirigering.

Sammenlign én betingelse ad gangen

Det er ikke nødvendigt at ændre alle indstillinger efter tur. Lav først et grundlag for sammenligningen, og vælg kun de kontroller, der passer til symptomet. Gem dit arbejde, før du ændrer indstillinger eller genopretter forbindelsen, og notér de oprindelige værdier, og hvordan de sættes tilbage. Har du ikke de nødvendige rettigheder eller funktioner, så gennemtving ikke en aktivering, men overdrag sagen til administratoren.

Lokal betjening og betjening via RDP foregår ikke nødvendigvis under de samme betingelser. At det er hurtigt på fjerncomputerens fysiske skærm, er nyttig information, men sessionen og betingelserne for gengivelse kan være anderledes. Gør bruger, data og appens tilstand ens, og begræns ikke årsagen til forbindelsen alene, fordi »det er hurtigt på den fysiske skærm«.

Sammenlign den samme handling

Forbered den samme bruger, de samme data og den samme handling. På en delt vært kontrollerer du din egen session, og du stopper ikke andre brugeres apps eller processer. Brug af en anden enhed eller en anden rute er også begrænset til det, administratoren har tilladt.

1. Genskab den langsomme handling med de oprindelige indstillinger, og notér tidspunkt og symptom.

   Skriv omtrent den samme mængde tekst i Notesblok i den samme fjernsession som den problematiske app. Skeln mellem, om det kun gælder én app eller hele sessionen.

2. Kontrollér belastningen på fjerncomputeren og lokalt i samme tidsrum.

   Se i Jobliste på den pågældende apps CPU, hukommelse og disk på fjerncomputeren og på RDP-klientens belastning lokalt. Kontrollér den pågældende proces og ikke kun den samlede CPU-værdi. Se: hvor belastningen skal undersøges.

3. Ændr kun én af betingelserne – en anden enhed, en anden tilladt rute eller visningsbetingelserne – og gentag den samme handling.

   Ændres fjerncomputerens eller appens tilstand samtidig i sammenligningen, så notér også den forskel. Et resultat, hvor flere betingelser er ændret, betragtes ikke som virkningen af én enkelt betingelse.

4. Sæt betingelsen tilbage til den oprindelige, og kontrollér den samme handling igen.

   Er det stadig hurtigt efter tilbagestillingen, kan det for eksempel også skyldes en midlertidig ændring i belastningen. Gå ikke ud fra, at ændringen virkede, men notér, under hvilke betingelser symptomet kan genskabes.

Du har nu resultater fra den oprindelige tilstand, efter ændringen og efter tilbagestillingen og kan sammenligne, hvilke betingelser der hænger sammen med symptomet. En betingelse, der gav en forbedring, er et spor i undersøgelsen og er ikke i sig selv et bevis på den grundlæggende årsag.

flowchart TB
    accTitle: Begræns de betingelser, der ændres på én gang
    accDescr: Forløbet, hvor man vælger en handling, der genskabes i den oprindelige tilstand, ændrer kun én betingelse, sammenligner og også kontrollerer resultatet efter tilbagestilling.
    A["Samme handling med oprindelige indstillinger"] --> B["Ændr kun én betingelse"]
    B --> C["Gentag samme handling"]
    C --> D["Sæt tilbage og kontrollér igen"]
    D --> E["Notér betingelsen, der hjalp"]

Figur 10: Gentag den samme handling i den oprindelige tilstand, efter ændringen og efter tilbagestillingen, og notér den betingelse, der gjorde en forskel.

Sammenlign opløsningen på fjernsiden

Denne sammenligning bruges, når skærmopdateringer, for eksempel ved rulning, er tunge. Notér opløsningen og antallet af skærme før ændringen, og gem dit arbejde, før du genopretter forbindelsen. Bliv ikke ved med at bruge indstillinger, der forringer den skærmplads eller den læsbarhed af tekst, som arbejdet kræver.

1. Ændr kun enten antallet af skærme eller opløsningen.

   I mstsc kan du sammenligne med indstillingerne under fanen »Skærm« før tilslutning eller ved at angive bredde og højde. Se: skærmindstillinger i mstsc.

2. Kontrollér, at fjernskrivebordets faktiske størrelse er ændret, og rul på den samme side.

   Gør du kun vinduet mindre lokalt, kan det være et stort skrivebord, der bare vises formindsket. Skeln mellem dynamisk opløsning og smart sizing, og kontrollér, hvad den klient, du bruger, understøtter. Se: skrivebordsopløsning og skalering.

3. Sæt indstillingen tilbage, gentag den samme handling, og sammenlign belastningen i begge ender og skærmens bevægelse.

   Har du skiftet til lav opløsning og én skærm på samme tid, er det kun en grov sammenligning. Bliver det bedre, så sæt én ting tilbage ad gangen for at adskille virkningerne.

Bliver det bedre, findes sporet inden for skærmbehandling og skærmoverførsel. 3840×2160 har fire gange så mange pixels som 1920×1080, men datamængden bliver ikke altid fire gange så stor. Den afhænger af de ændrede dele og af komprimeringen, og en ændret opløsning påvirker også behandlingen i begge ender. Se: sammenhængen mellem antal pixels og datamængde, kontrol af skærmbehandlingen.

flowchart TB
    accTitle: Hvad en sammenligning med lavere opløsning kan vise
    accDescr: Når opløsningen på fjernsiden sænkes, kan belastningen både i skærmbehandlingen og i overførslen ændre sig, så en forbedring alene ikke kan begrænse årsagen til forbindelsen.
    A["Sænk opløsningen på fjernsiden"] --> S
    subgraph S["Behandling, der ændres"]
    direction TB
    B["Skærmbehandling på fjerncomputer"] ~~~ C["Mængde data, der sendes"]
    C ~~~ D["Lokal visningsbehandling"]
    end

Figur 11: En ændret opløsning er en sammenligning, der ikke kun påvirker forbindelsen, men også skærmbehandlingen på fjerncomputeren og lokalt.

Hold kopiering og udskrivning op mod symptomet

Sæt kun processer, du har tilladelse til at stoppe, på pause, for eksempel overførsler, du selv har startet. Virksomhedens backup- og sikkerhedsprocesser og andre brugeres job stoppes ikke. Omdirigering af lyd- og inputenheder, som arbejdet kræver, deaktiveres ikke samlet.

1. Notér den samme handling og belastningen, før og mens kopiering, cloudsynkronisering eller udskrivning kører.

   Ud over skærmen går der også data for drev, printere og lignende gennem RDP. Omdirigering, der gør lokale enheder tilgængelige på fjerncomputeren, kan øge belastningen på netværk og behandling, mens den er i brug. Se: virkningen af enhedsomdirigering.

2. Sæt den pågældende overførsel på pause inden for det tilladte, og kontrollér den samme handling igen.

   Kan du genoptage og sammenligne, så notér også symptomet efter genoptagelsen. Afprøver du ændringer af unødvendig enhedsomdirigering, så ændr også dem én ad gangen, og sørg for, at du kan vende tilbage til de oprindelige indstillinger.

Du kan nu vurdere, om starten på overførslen hænger sammen med problemerne, og pausen med bedringen. Ser du en sammenhæng, så hold andre overførsler end skærmen og belastningen på delte ressourcer op mod administratorens logfiler.

flowchart TB
    accTitle: Se på tiden før og efter problemet på samme tidsakse
    accDescr: Notér den samme handling og belastning før overførslen, under den og efter pausen, og sammenlign forholdet mellem problemet og arbejdet.
    A["Handling og belastning før overførsel"] --> B["Handling og belastning under overførsel"]
    B --> C["Handling og belastning efter stop"]
    C --> D["Hænger problem og bedring sammen?"]

Figur 12: Se, hvordan den samme handlings langsomhed og belastningen ændrer sig før overførslen, under den og efter stoppet.

Mål, hvor ventetiden opstår

Lokalt undersøger du netværkets rundtur og TCP-forbindelsen, og på fjerncomputeren ventetiden i inputkøen og skærmopdateringerne. Hvert tal måler kun en begrænset strækning, så læs resultaterne sammen med tabellen i »Hvad måleresultaterne dækker«.

Kontrollér ICMP og TCP-forbindelsen

Det køres på din lokale Windows-enhed. Det gælder kun opsætninger, hvor du via virksomhedens LAN eller et tilladt VPN forbinder direkte til en RDP-vært, der bruger standardporten TCP 3389. Ved forbindelse via RD Gateway eller Azure Virtual Desktop eller ved opsætninger med en anden port skal du aftale med administratoren, hvad der skal kontrolleres. Porte åbnes ikke, og firewallen ændres ikke.

1. Indtast den tilladte fjerncomputer, og notér resultaterne for ICMP-svar og TCP-forbindelse.

   $target = Read-Host 'Navn eller IP-adresse på den RDP-vært, du har tilladelse til at undersøge'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Angiv den computer, der skal forbindes til.'
   }
       
   # Se ICMP-svartiden over flere forsøg. En fejl alene betyder ikke, at RDP ikke kan nås.
   ping.exe -n 20 $target
       
   # Kontrol, der kun gælder opsætninger med direkte forbindelse til standardporten TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Hold resultaterne fra det langsomme tidsrum og fra normal drift op mod tidspunktet for symptomet og den faktiske forbindelsesrute.

   20 kørsler af ping er en kort observation. Notér udsving i værdierne og manglende svar, men vær opmærksom på, at ICMP kan være blokeret. Udelukk ikke periodiske stop ud fra gennemsnitsværdien alene, men brug forbindelsesoplysninger og administratorens netværkslogfiler. Se: hvad ping måler.

TcpTestSucceeded: True betyder, at TCP-forbindelsen til den angivne port lykkedes. Båndbredde, UDP, handlinger efter godkendelse og hvor flydende skærmbilledet er, er ikke målt. Test-NetConnection har ingen switch -UDP, der undersøger UDP. Se: syntaks og resultater for Test-NetConnection.

Vurder resultaterne med forskellene i rute og tjeneste for øje. Med RD Gateway og lignende er ruten for ICMP eller en direkte TCP-forbindelse til værten ikke altid den samme som den faktiske RDP-rute. I Azure Virtual Desktop kan du bruge RTT og estimeret båndbredde for hver forbindelse, men den diagnosefunktion er beregnet til netop den tjeneste. Korte stop udelukkes ikke ud fra gennemsnitsværdier alene. Se: logfiler for forbindelseskvalitet i Azure Virtual Desktop.

flowchart TB
    accTitle: Den kontrollerede rute og den faktiske RDP-rute
    accDescr: I opsætninger med RD Gateway og lignende er ruten for ICMP eller en direkte TCP-forbindelse fra den lokale enhed til værten ikke altid den samme som den faktiske RDP-rute.
    A["Lokal enhed"] -->|"ICMP, direkte TCP"| C["RDP-vært"]
    A -->|"Faktisk RDP"| B["RD Gateway m.fl."]
    B --> C

Figur 13: ICMP eller en direkte TCP-forbindelse til værten og den faktiske RDP-forbindelse følger ikke altid samme rute.

Mål ventetiden i inputkøen

User Input Delay måler ventetiden, fra et input kommer i kø på fjerncomputeren, til processen henter det. Det er ikke den samlede tid, fra du trykker på en tast, til tegnet kan ses. Se: definitionen af User Input Delay.

Undersøgelsen foregår i fjernsessionen på fjerncomputeren. Ifølge Microsoft understøttes Windows 10 version 1809 og nyere samt Windows Server 2019 og nyere. På disse versioner er det ikke nødvendigt at tilføje en værdi i registreringsdatabasen for at aktivere tælleren. Kontrollér visningsnavn, rettigheder og om tælleren findes, og er den ikke tilgængelig, så notér det, og kontakt administratoren. Se: understøttede versioner og indstillinger.

1. Notér tidspunktet og sessions-id’et i PowerShell i samme session.

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

   Det kan kræve ekstra rettigheder at forespørge andre brugeres sessioner. Standardnavnet på instansen for den pågældende proces er SessionID:ProcessID <Process Image>. Undgå at blande værdier fra andre brugere eller fra processer med samme navn sammen ved kun at gå efter sessions-id’et. Se: rettigheder til query session, identifikation af instanser.

2. Tilføj den tilgængelige User Input Delay per Process eller User Input Delay per Session i perfmon.exe.

   Vælg den pågældende proces eller session, og observer i første omgang med standardintervallet på 1 sekund. Skeln mellem den samlede instans, der samler flere sessioner, og værdierne for de enkelte sessioner.

3. Genskab den handling, hvor input er langsomt, og sammenlign ventetiden i køen med tidspunktet for symptomet.

   For de enkelte måleobjekter viser værdien den længste ventetid inden for måleintervallet. Selv om værdien er lav, kan der stadig være forsinkelse i behandlingen, efter at appen har hentet inputtet, og indtil resultatet når tilbage til den lokale enhed.

Du kan undersøge, om der ventes i inputkøen på fjerncomputeren. Det er et andet mål end den oplevede tid, der omfatter netværkets rundtur og visningen lokalt. Se: betydningen af maksimumværdien og måleintervallet.

flowchart TB
    accTitle: Den strækning, User Input Delay måler
    accDescr: Målestrækningen går fra inputkøen på fjerncomputeren, til appen henter inputtet, og omfatter ikke netværket eller skærmvisningen før og efter.
    A["Input ankommer fra lokal enhed"] --> B["Input kommer i kø på fjerncomputer"]
    B -->|"Dette måles"| C["Appen henter inputtet"]
    C --> D["Appbehandling og skærmoverførsel"]
    D --> E["Vises lokalt"]

Figur 14: Det, der måles, er ventetiden i inputkøen på fjerncomputeren. Det er ikke det samme som den samlede tid, til resultatet kan ses lokalt.

Undersøg skærmopdateringer og årsager til udeladte frames

Forbered en handling med vedvarende skærmopdateringer, for eksempel rulning. Om RemoteFX Graphics-tællerne er tilgængelige, og hvor der måles, skal kontrolleres ud fra operativsystem, værtsopsætning og rettigheder. Her læser du kun de tællere, der er tilgængelige. Det er ikke en vejledning i at installere eller aktivere den gamle RemoteFX-funktion. Se: betingelser for Graphics-tællerne.

1. Find navnet på den pågældende session med query session eller qwinsta, og vælg den tilsvarende tællerinstans.

2. Sammenlign Input Frames/Second og Output Frames/Second under en handling med skærmopdateringer.

   Er output lavere end input, bliver frames sprunget over undervejs. Kontrollér værdierne for Frames Skipped/Second opdelt efter ressourcemangel på fjerncomputeren, i netværket og i klienten.

3. Hold årsagerne til de udeladte frames op mod belastningen i begge ender og på netværket, og kontrollér også Average Encoding Time.

   Er kodningstiden lang, så undersøg komprimeringen på fjerncomputeren. Er antallet af frames lavt allerede på inputsiden, er det også muligt, at appen ikke opdaterer skærmen ofte. Et lavt antal frames på en stillestående skærm er ikke i sig selv unormalt.

Ud fra input og output under skærmopdateringer, årsagerne til udeladte frames og kodningstiden kan du indsnævre, hvor der skal undersøges. Tællernes opdeling er et spor, som skal vurderes sammen med den faktiske belastning og forbindelsesopsætningen. Se: sådan læses antal frames og kodningstid.

flowchart TB
    accTitle: Indsnævr undersøgelsen ud fra udeladte frames
    accDescr: Under en handling med skærmopdateringer sammenlignes antallet af input- og outputframes, og med tællerne for årsager til udeladte frames som spor holdes de op mod belastningen i behandling, netværk og visning.
    A["Sammenlign input og output under rulning"] --> B["Færre output: kontrollér udeladelser"]
    B --> C["Se tællerne for hver årsag"]
    C --> D["Sammenhold med belastning: fjern, net, lokal"]

Figur 15: Sammenlign input og output under rulning, og hold årsagerne til udeladte frames op mod belastningen på fjerncomputeren, forbindelsen og den lokale enhed.

Principskitser af skærmoverførslen og ældre dokumentation generaliseres ikke til alle opsætninger. Der findes også opsætninger, hvor video og lyd overføres via en anden mekanisme. Dokumentationen til Graphics-tællerne beskriver også ældre opsætninger, så tallene i den omtolkes ikke til en fælles specifikation om, at »al RDP kører med højst 30 fps«. Kontrollér, hvad funktioner og tal gælder for, før du bruger dem. Se: skærmoverførsel og arbejdsbelastninger, dokumentationen til Graphics-tællerne.

Hvad måleresultaterne dækker

Et lavt tal er ikke det samme som, at betjeningen føles behagelig. Hvad hvert mål dækker, kan du kontrollere i den Microsoft-dokumentation, der er henvist til i fremgangsmåderne.

Netværks- og GPU-indstillinger

Indstillinger for UDP og GPU vælges ud fra det, sammenligningerne og målingerne har vist. Er netværket mistænkt, kontrollerer du først transportprotokollen og ruten, og er skærmbehandlingen mistænkt, kontrollerer du først, i hvilke trin GPU’en bruges.

Kontrollér TCP/UDP og forbindelsesruten

Peger sammenligninger og målinger på netværket, så gennemgå sammen med administratoren den klient, du bruger, ruten og de politikker, der gælder. Er det nødvendigt at ændre indstillinger, sker det kun inden for det godkendte, og værdierne før ændringen samt metoden til gendannelse noteres. Firewall og godkendelse deaktiveres ikke, og RDP-porten eksponeres ikke direkte mod internettet.

1. Kontrollér den faktiske brug af TCP/UDP og ruten ud fra forbindelsesoplysninger, produktets diagnoselogfiler og administratorens netværkslogfiler.

   RDP bruger TCP eller UDP afhængigt af opsætning og netværksforhold. I »Select RDP transport protocols« kan du vælge mellem en indstilling, der bruger UDP eller TCP, og en indstilling, der kun bruger TCP. Da RDP også kan bruge TCP, hvis en UDP-forbindelse ikke kan oprettes, fortæller en vellykket forbindelse alene ikke, hvilken protokol der bruges. Se: valg af RDP-transport og fallback.

2. Hold tidspunktet for symptomet op mod ruten og protokollen, og sammenlign kun de nødvendige indstillinger én ad gangen.

   Ændr ikke indstillingerne generelt ud fra tanken om, at »det bliver hurtigere, hvis UDP slås fra«. Sammenlign med ens betingelser for VPN og gateway, handling og visning, og sæt unødvendige ændringer tilbage.

Når du kender protokollen og ruten, kan du notere sammenhængen mellem ændringen og symptomet. En ændring til kun TCP gør ikke altid forbindelsen hurtigere.

flowchart TB
    accTitle: Kontrollér transportprotokollen, før netværksindstillinger sammenlignes
    accDescr: Skeln mellem almindelig direkte forbindelse og forbindelse via gateway eller tjeneste, og kontrollér den faktiske rute og protokol, før en tilladt sammenligning udføres.
    A["Klient og forbindelsesopsætning"] --> B["Kontrollér faktisk rute og TCP/UDP"]
    B --> C["Hold op mod symptomets tidspunkt"]
    C --> D["Sammenlign kun nødvendige indstillinger én ad gangen"]

Figur 16: Kontrollér den aktuelle transportprotokol og rute, hold dem op mod symptomet, og sammenlign først derefter kun de nødvendige indstillinger.

RDP Shortpath er en mekanisme i Azure Virtual Desktop. Den opretter en UDP-rute for tjenesten og bruger afhængigt af opsætningen en direkte rute eller et relæ. Kan ruten ikke oprettes, falder den tilbage til en TCP-baseret forbindelse. Den kan ikke behandles i samme indstillingstabel som en direkte forbindelse med mstsc til en pc i virksomheden. Se: ruter og fallback for RDP Shortpath.

flowchart TB
    accTitle: Ruter og fallback for RDP Shortpath
    accDescr: RDP Shortpath i Azure Virtual Desktop forsøger at oprette en UDP-rute. Lykkes det, bruges en direkte rute eller et relæ afhængigt af opsætningen, og lykkes det ikke, falder den tilbage til en TCP-baseret forbindelse.
    A["RDP Shortpath"] --> B{"UDP-rute"}
    B -->|"Oprettet"| C["Direkte eller relæ"]
    B -->|"Ikke oprettet"| D["Tilbage til TCP-baseret"]

Figur 17: Kan RDP Shortpath ikke oprette en UDP-rute, falder den tilbage til en TCP-baseret forbindelse.

Kontrollér GPU-brug i skærmbehandlingen

Denne kontrol bruges, når sammenligninger og målinger peger på skærmbehandlingen. Gennemgå måleresultaterne for skærmbehandlingen og de understøttede operativsystemer, drivere, politikker og klienter. Indstillinger ændres ikke, blot fordi der er en GPU i maskinen. Indhent først administratorens godkendelse, og forbered, hvordan der kan vendes tilbage.

1. Skeln mellem appens gengivelse på fjerncomputeren, RDP’s kodning og den lokale afkodning, og vælg det trin, der er mistænkt.

   Selv om der er en GPU, bruger ikke nødvendigvis alle trin den. Også i Microsofts konfigurationsdokumentation til Azure Virtual Desktop konfigureres og kontrolleres gengivelse i fjernsessionen og hardwarekodning af frames hver for sig. Se: GPU-konfiguration og -kontrol af gengivelse og kodning.

2. Kontrollér den faktiske brug efter vejledningen til det pågældende produkt, og mål den samme handling før og efter de nødvendige ændringer.

   Er komprimeringstiden lang, så undersøg GPU-brugen til kodning. Ændrer du kodningsindstillingerne for en app, der venter i inputkøen, rammer du det forkerte sted. Læsbar tekst og glat video kræver også forskellige afvejninger mellem billedkvalitet, datamængde og behandlingsbelastning. Se: forskelle afhængigt af arbejdsbelastning.

Du kan nu notere ikke kun, om der er en GPU, men også om GPU’en bruges i det problematiske trin, og hvordan belastningen og responsen for den samme handling har ændret sig. Ændringer uden forbedring sættes tilbage efter aftale med administratoren.

flowchart TB
    accTitle: Kontrollér GPU-brugen trin for trin
    accDescr: Skeln mellem appens gengivelse på fjerncomputeren, RDP's kodning og den lokale afkodning, og kontrollér brugen i det mistænkte trin, fordi ikke alle trin nødvendigvis bruger GPU'en, selv om der er en.
    A["Appens gengivelse på fjerncomputer"] --> B["RDP-kodning"]
    B --> C["Lokal afkodning"]
    C -.- D["Kontrollér GPU-brug for hvert trin"]

Figur 18: Selv om der er en GPU, bruger gengivelse, kodning og afkodning den ikke nødvendigvis alle sammen.

Ny kontrol og overdragelse

En forbedring bekræftes ved, at den samme handling kan udføres uden problemer efter ændringen, og ved, at den nødvendige billedkvalitet, de nødvendige enheder og forretningsfunktioner bevares. Sammenhold også med resultatet efter tilbagestilling til de oprindelige betingelser. Er det kun en kortvarig bedring, fastslås årsagen ikke, og travle tidsrum og samtidige processer noteres også.

flowchart TB
    accTitle: Rækkefølgen for at bekræfte en forbedring
    accDescr: Viser, at man efter ændringen kontrollerer, om den samme handling kan udføres uden problemer, og om den nødvendige billedkvalitet, enheder og forretningsfunktioner bevares, holder det op mod resultatet efter tilbagestilling og ikke fastslår årsagen ud fra en kortvarig bedring alene.
    A["Prøv samme handling efter ændring"] --> B["Kontrollér billedkvalitet, enheder, funktioner"]
    B --> C["Hold op mod resultat efter tilbagestilling"]
    C -.- D["Kortvarig bedring fastslår intet"]

Figur 19: Ud over resultatet af den samme handling holdes de nødvendige funktioner og resultatet efter tilbagestilling også op mod hinanden.

Overdragelse, når problemet ikke er løst

Også når der ikke er nogen forbedring, når fejlen ikke kan genskabes, eller når tællerne ikke er tilgængelige, er resultatet nyttigt. Skeln mellem de sammenligninger, du kunne udføre, og de kontroller, du ikke kunne, og overdrag til administratorer og udviklere med notatet nedenfor. Fjern forretningsoplysninger som brugernavne og fjerncomputere, der ikke er nødvendige for undersøgelsen, fra de logfiler, du deler.

Tidspunkt og tidszone for symptomet:
Fjerncomputerens OS, klient og version:
Direkte forbindelse/VPN/RD Gateway/Azure Virtual Desktop osv.:
Langsom handling og app, reaktion i andre apps i samme session:
Opløsning og antal skærme på fjernsiden:
Kopiering, udskrivning osv., der kørte samtidig:
Den ene ændrede betingelse og resultatet efter tilbagestilling:
Belastning og tællere observeret på fjerncomputer og lokalt:

Tilføj også, om den faktiske brug af TCP/UDP kunne bekræftes, hvilke punkter der ikke kunne kontrolleres, for eksempel på grund af manglende rettigheder, og hvilke indstillinger der er acceptable for arbejdet. Skriver du »Notesblok kan bruges normalt, men det går i stå, når jeg ruller gennem billeder« i stedet for »forbindelsen er langsom«, kan den næste ansvarlige undersøge under de samme betingelser.

Brugeren noterer den handling, der genskaber problemet, og resultaterne af sammenligningerne, og administratoren holder logfilerne for forbindelsesruten, den delte vært og sessionerne op mod hinanden. At der ventes inde i RDP, betyder ikke i sig selv, at det også er RDP, der forårsager ventetiden. Se: arbejdsdelingen mellem vært og backend.

Appudviklere logger modtagelsen af inputhændelser, start og slut på database- og filbehandling og opdateringen af brugerfladen hver for sig. De overvejer også et design, hvor tungt arbejde ikke bliver hængende i UI-tråden. En log over, at behandlingen er afsluttet på fjerncomputeren, registrerer dog ikke, at visningen er afsluttet lokalt. Se: adskillelse af behandling for at bevare brugerfladens responsivitet.

Relaterede artikler

• Sådan forstår du sessionsisolering i Windows
• Sikker fejlfinding af 100 % diskforbrug i Windows
• Hvorfor slutter »1 sekund tilbage« aldrig?

Referencer

Det følgende er primærkilder fra Microsoft Learn. Indholdet blev kontrolleret den 17. september 2026. Læs dem med for øje, hvad der gælder for hvert produkt, og at de ikke er målinger, der er udført i forbindelse med denne artikel.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. RTT og forskellen på forsinkelsen fra indfangning af skærmbilledet på fjerncomputeren til visning lokalt. Selve diagnosefunktionen er beregnet til Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Sammenhængen mellem skærmindhold, opløsning, frameopdatering, komprimering, caching og datamængde.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Sådan kontrolleres skærmens input og output, årsager til udeladte frames og kodningstid. Da den også beskriver ældre opsætninger, generaliseres de numeriske grænser ikke til al RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Belastning på delte værter, trafik fra fjerncomputeren til backend og virkningen af enhedsomdirigering.
• Microsoft Learn, Threading model. UI-tråden og Dispatcher i WPF samt adskillelse af behandling for at bevare responsiviteten.
• Microsoft Learn, mstsc. Angivelse af bredde og højde for fjernskrivebordet og af flere skærme.
• Microsoft Learn, Supported RDP properties. Forskellen mellem skrivebordsopløsning, dynamisk opløsning og smart sizing. Kontrollér, hvilke klienter der understøtter dem, og hvad der gælder for hvert produkt.
• Microsoft Learn, ping. Kontrol af svar med ICMP Echo og kommandoens indstillinger.
• Microsoft Learn, Test-NetConnection. Kontrol af TCP-forbindelse og betydningen af outputtet.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Målestrækningen for User Input Delay, understøttede operativsystemer, instanser og betydningen af maksimumværdien.
• Microsoft Learn, query session. Sessionsoplysninger og de rettigheder, der kræves for at forespørge andre sessioner.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Valg af TCP/UDP for RDP og fallback.
• Microsoft Learn, RDP Shortpath. UDP-ruter til Azure Virtual Desktop og hvad der sker, når de ikke kan oprettes.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. GPU-konfiguration og -kontrol, hvor gengivelse og framekodning holdes adskilt.

Relaterede artikler

De nyeste artikler med de samme tags. Gå dybere ind i emnet med nært beslægtede artikler.

Relaterede emner

Emnesider, der ligger tæt på dette tema. Med artiklen som udgangspunkt kan du gå videre til relaterede ydelser og andre artikler.

Ydelser, der hænger sammen med emnet

Denne artikel er knyttet til følgende ydelsessider. Vælg den indgang, der ligger tættest på din sag.

Ofte stillede spørgsmål

Her er de spørgsmål, der ofte kommer op ved rådgivning om artiklens emne.

Hvorfor er input i RDP langsomt, når hastighedstesten viser flere hundrede Mbps?

Hastigheden, hvormed store datamængder transporteres, og tiden, til en handling får respons, er to forskellige ting. Afsendelse af input, behandling i appen på fjerncomputeren, komprimering af skærmbilledet, overførsel og visning lokalt spiller alle ind. Desuden er netværksruten til hastighedstestens modpart og til RDP-fjerncomputeren forskellige.

Jeg kan skrive normalt, men kun rulning hakker. Er det forbindelsen, der er problemet?

Det kan ikke indsnævres til forbindelsen alene. Når skærmopdateringerne bliver flere, kan et af leddene ikke følge med: gengivelse og komprimering på fjerncomputeren, netværket eller afkodning og visning lokalt. Ændr opløsningen eller antallet af skærme på fjernsiden én ad gangen, sammenlign, og undersøg om nødvendigt de tællere, der vedrører gengivelsen.

Er RDP-forbindelsen i orden, hvis ping er hurtig?

Det kan ikke afgøres ud fra det alene. Ping måler svaret på ICMP og måler hverken RDP's skærmoverførsel eller appens behandling. I opsætninger med RD Gateway og lignende er ruten heller ikke altid den samme. Også når der ikke kommer noget svar, skal du skelne mellem blokeret ICMP og en RDP-forbindelse, der faktisk ikke virker.

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

Nej. Det er en tæller, der måler ventetiden, fra et input kommer i kø på fjerncomputeren, til processen henter det. Det er ikke den oplevede forsinkelse, der omfatter netværkets rundtur, appens behandling efter hentningen og komprimering, afkodning og visning af skærmbilledet.

Bør jeg deaktivere UDP, når RDP er langsom?

Det anbefales ikke generelt. Kontrollér først den faktiske transportprotokol, ruten og de politikker, der gælder. Nogle gange kan UDP ikke bruges, og forbindelsen er allerede faldet tilbage til TCP, og en ændring til kun TCP gør det ikke altid hurtigere. Sammenlign med ens betingelser med administratorens tilladelse, og sæt unødvendige ændringer tilbage.

Forfatterprofil

Profilsiden for artiklens forfatter.

Go Komura

Repræsentant for KomuraSoft LLC

Fokus på udvikling af Windows-software, teknisk rådgivning og fejlfinding, med særlig erfaring i projekter, hvor eksisterende løsninger skal bevares, og i undersøgelse af fejl, hvor årsagen er svær at spore.