Waarom is RDP traag terwijl de verbinding snel is? — Invoer, beeldopbouw en netwerk apart onderzoeken

De snelheidstest haalt honderden Mbit/s, maar in extern bureaublad verschijnen tekens met een kleine vertraging. Als u door een pagina met veel foto’s scrolt, hapert het beeld. Alleen wanneer u in een bedrijfsapplicatie op zoeken drukt, blijft de applicatie een paar seconden hangen. Waar begint u met het onderzoek bij zo’n situatie: “de verbinding is snel, maar RDP is traag”?

De reactie op bediening in RDP wordt niet alleen bepaald door de overdrachtssnelheid van de verbinding. Ook als de snelheidstest snel is, kan er ergens gewacht worden: bij de netwerkretour, bij het wachten op invoer in de applicatie op de host, bij het coderen van het beeld of bij het decoderen en weergeven op uw eigen computer. Splits eerst op “welke handeling is traag?” en vergelijk dezelfde handeling door telkens maar één voorwaarde te wijzigen. Baken met vergelijkingen en metingen af waar u moet zoeken, en kies UDP- en GPU-instellingen op basis van die resultaten. Zie: Meettrajecten van de verbindingskwaliteit, Prestatiefactoren van sessiehosts.

In het stadium waarin u hebt afgebakend waar u moet zoeken, staat de grondoorzaak echter nog niet vast. Ook als een lagere resolutie verbetering brengt, verandert niet alleen de overdracht maar ook de beeldverwerking aan beide kanten; daarom wordt niet geconcludeerd dat “de verbinding de oorzaak was”. Leg de resultaten vast en maak daarbij onderscheid tussen gemeten en niet-gemeten trajecten.

Dit artikel bakent invoer, scrollen en de reactie van applicaties na het verbinden af. Ook bij vergelijkbare symptomen is er niet per se één oorzaak. Gevallen als “het duurt lang voordat het aanmeldscherm verschijnt” of “het blijft alleen hangen bij de verificatie” worden behandeld als een apart probleem, dat u onderzoekt aan de hand van de logboeken van het opzetten van de verbinding en van de verificatie.

De doelgroep bestaat vooral uit gebruikers en beheerders die met de Windows-app “Verbinding met extern bureaublad” (mstsc) verbinding maken met Windows 11 of Windows Server. De opdrachtvoorbeelden zijn bedoeld voor Windows PowerShell 5.1. Er wordt van uitgegaan dat u dezelfde handeling in een bestaande sessie kunt reproduceren.

Bij een directe verbinding, VPN, RD Gateway en Azure Virtual Desktop verschillen de route, de beschikbare diagnostische informatie en waarop instellingen van toepassing zijn. Het controlevoorbeeld voor TCP 3389 geldt alleen voor een toegestane directe verbinding met een RDP-host die de standaardpoort gebruikt. Diagnosefuncties en GPU-instellingen uit documentatie voor Azure Virtual Desktop worden niet zonder meer toegepast op gewone pc’s binnen het bedrijf.

Op bedrijfsapparaten onderzoekt u alleen binnen de grenzen die de beheerder heeft toegestaan. Identificeer op een gedeelde host uw eigen sessie en het betreffende proces, en vraag het de beheerder als u gegevens van andere gebruikers nodig hebt. Of prestatiemeteritems beschikbaar zijn, hoe ze worden weergegeven en welke rechten nodig zijn, controleert u per omgeving.

De hier getoonde controlemethoden zijn gebaseerd op officiële documentatie. Het is geen meetverslag waarin een storing op een bepaald apparaat is gereproduceerd en verholpen. Getallen in voorbeelden worden duidelijk als aannames ter uitleg aangeduid.

Het mechanisme kunt u op volgorde lezen, te beginnen met de volgende sectie “Overdrachtssnelheid en retourtijd”. Wilt u vanuit de symptomen beginnen, ga dan naar “Eerste vergelijking per symptoom”. De stappen staan in “Voorwaarden één voor één vergelijken” en “Meten waar gewacht wordt”.

In het diagram geeft een doorgetrokken lijn een relatie aan die altijd geldt en een stippellijn een voorwaardelijke relatie (de voorwaarden staan per relatie op de detailpagina). Het volledige overzicht van de relaties (7 in totaal, met onderbouwing en zekerheid) en de definities van de belangrijkste concepten vindt u op de detailpagina van de kennisgrafiek (in het Japans). Gegevens: JSON-LD / Turtle

Overdrachtssnelheid en retourtijd

RDP (Remote Desktop Protocol) is een protocol waarmee invoer, beeldinformatie en dergelijke worden uitgewisseld tussen uw eigen apparaat en de host. Het verwerkt niet alleen beeld en invoer, maar ook informatie voor apparaatomleiding, afdrukken en dergelijke. Zie: Informatie die RDP overdraagt.

De overdrachtssnelheid van een verbinding geeft aan hoeveel data er per seconde kan worden vervoerd. De “500 Mbit/s” van een snelheidstest is een getal voor die hoeveelheid. Het is geen getal dat aangeeft hoe lang het duurt van een handeling tot het antwoord binnenkomt. Zie: Bandbreedtevereisten van RDP.

flowchart TB
    accTitle: Wat het getal van een snelheidstest aangeeft
    accDescr: De 500 Mbit/s van een snelheidstest geeft aan hoeveel data er per seconde kan worden vervoerd; dat is een ander getal dan de tijd van een handeling tot het antwoord binnenkomt.
    A["Snelheidstest: 500 Mbit/s"] --> B["Data per seconde"]
    B -.->|"ander getal"| C["Tijd tot het antwoord"]

Afbeelding 1: Het getal van de snelheidstest geeft de hoeveelheid aan die kan worden vervoerd, niet de tijd tot er een antwoord binnenkomt.

De retourtijd (RTT) is de tijd die verkeer nodig heeft om de andere kant te bereiken en weer terug te komen. Het verschil tussen een hogere overdrachtssnelheid en een kortere retourtijd lijkt op het verschil tussen meer rijstroken op een weg en een kortere afstand tot de bestemming. Ook als de capaciteit om grote hoeveelheden bestanden te vervoeren toeneemt, blijft het wachten op een reactie op een handeling bestaan zolang de retourtijd gelijk blijft. Zie: RTT en vertraging van de beeldweergave.

flowchart TB
    accTitle: Overdrachtssnelheid en retourtijd vergeleken met een weg
    accDescr: De afbeelding vergelijkt een hogere overdrachtssnelheid met meer rijstroken op een weg en een kortere retourtijd met een kortere afstand tot de bestemming.
    A["Overdrachtssnelheid verhogen"] -->|"als weg"| B["Meer rijstroken"]
    B ~~~ C["Retourtijd verkorten"]
    C -->|"als weg"| D["Kortere afstand"]

Afbeelding 2: Meer rijstroken maken de afstand tot de bestemming niet korter.

Tot het resultaat van één teken terugkomt

Stel dat u één teken typt in Kladblok op de externe computer. Kladblok draait op de host. Als we ter uitleg aannemen dat de handeling 50 milliseconden nodig heeft om aan te komen en de beeldinformatie met het resultaat 50 milliseconden om terug te komen, dan kost de overdracht in totaal 100 milliseconden, oftewel 0,1 seconde. De verwerkingstijd aan beide kanten is in dit voorbeeld buiten beschouwing gelaten.

flowchart TB
    accTitle: Voorbeeld van de overdrachtstijd tot het resultaat van één teken terugkomt
    accDescr: Een voorbeeld dat ter uitleg voor heen en terug elk 50 milliseconden aanneemt. De verwerkingstijd aan beide kanten is niet meegerekend, en het geeft ook niet het aantal pakketten per toets weer.
    A["Lokaal één teken typen"] -->|"heen: 50 ms"| B["Host ontvangt de invoer"]
    B --> C["Beeld met invoer versturen"]
    C -->|"terug: 50 ms"| D["Resultaat komt lokaal aan"]

Afbeelding 3: Bij aangenomen 50 milliseconden heen en 50 milliseconden terug kost alleen de overdracht al 0,1 seconde. Dit is geen meetwaarde.

Ook als de verbinding meer data kan vervoeren, blijft deze 0,1 seconde bestaan zolang de retourtijd niet verandert. Afbeelding 3 is een conceptdiagram om de verwerking te begrijpen. Het betekent niet dat er voor elke toets een afzonderlijk pakket heen en terug wordt gestuurd. Ook de routes naar de server van de snelheidstest en naar de RDP-host verschillen; houd daarbij rekening met VPN, gateways, de upload aan de kant van de host en congestie onderweg. Zie: Hoe RTT te begrijpen, Netwerk- en hostprestaties.

Beeld opbouwen en overbrengen

Met vertraagde reactie op bediening bedoelen we hier het wachten vanaf een handeling op uw eigen computer tot het resultaat zichtbaar is. Behalve de RTT spelen ook de verwerking in de applicatie en het opbouwen en overbrengen van het beeld een rol. Dit wordt ook onderscheiden van de vertraging in alleen het overdrachtstraject van het beeld. Zie: Meettraject van schermopname tot weergave.

Komt invoer van uw computer bij de host aan, dan verwerkt de applicatie op de host de invoer en werkt het beeld bij; de gecodeerde beeldinformatie wordt over de lijn vervoerd en op uw computer gedecodeerd en weergegeven. Ook vóór en na de overdracht is er werk dat door verschillende pc’s wordt gedaan. Zie: Verwerking van schermopname tot weergave.

flowchart TB
    accTitle: Ook vóór en na de lijn wordt het beeld verwerkt
    accDescr: De stroom waarin lokale invoer de host bereikt, de applicatie op de host die verwerkt, het beeld opbouwt en comprimeert, en de over de lijn vervoerde beeldinformatie lokaal wordt teruggezet naar een vorm die kan worden weergegeven, en wordt getoond.
    I["Lokaal: handeling invoeren"] --> J["Lijn: invoer vervoeren"]
    J --> K["Host: applicatie verwerkt"]
    K --> A["Host: beeld maken, comprimeren"]
    A --> B["Lijn: beeldinformatie vervoeren"]
    B --> C["Lokaal: terug naar weergavevorm"]
    C --> D["Lokaal: op het scherm tonen"]

Afbeelding 4: Op de host verwerken en comprimeren, over de lijn vervoeren, lokaal terugzetten voor weergave. Elk van deze taken gebeurt op een andere plek.

Coderen betekent in dit artikel de verwerking waarbij de host het beeld omzet en comprimeert naar een vorm die gemakkelijk te versturen is. Los van de overdracht over de lijn kost dit verwerkingstijd op de host. Zie: Coderingstijd op de host.

Decoderen betekent in dit artikel de verwerking waarbij de ontvangen beeldinformatie op uw computer wordt teruggezet naar een vorm die kan worden weergegeven. Dit wordt onderscheiden van ontsleutelen in de zin van het opheffen van versleuteling. Zie: Lokale decoderings- en weergavetijd.

Duurt de compressie op de host lang, dan wacht het versturen op de voorbereiding, ook als de lijn vrij is. Ook als de informatie is aangekomen, loopt het bijwerken vertraging op als het decoderen of weergeven op uw computer het niet bijbeent. “De bedrijfs-pc is krachtig, dus het lokale apparaat maakt niet uit” klopt niet per se. Ruimte op de lijn en ruimte in de verwerking aan beide uiteinden ervan zijn twee verschillende dingen. Zie: Prestatiemeteritems voor beeldverwerking.

flowchart TB
    accTitle: Vertraging als de verwerking aan beide kanten het niet bijbeent
    accDescr: Duurt de compressie op de host lang, dan wacht het versturen op de voorbereiding, ook als de lijn vrij is; beent het lokale decoderen of weergeven het niet bij, dan loopt het bijwerken vertraging op, ook al is de informatie aangekomen.
    A["Compressie op host duurt lang"] --> B["Versturen wacht, lijn vrij"]
    B ~~~ C["Lokaal decoderen beent niet bij"]
    C --> D["Aangekomen, toch vertraagd"]

Afbeelding 5: Ook als de lijn ruimte heeft, loopt het bijwerken van het beeld vertraging op als de verwerking aan beide kanten het niet bijbeent.

Verschil tussen typen en scrollen

Voegt u in Kladblok één teken toe, dan verandert alleen een klein deel van het scherm. Scrolt u door een pagina met veel foto’s, dan verandert de weergave in een groot gebied in snel tempo. RDP beperkt de hoeveelheid data door gewijzigde delen over te dragen en compressie en caching te gebruiken die bij de inhoud passen. Het verstuurt niet elke keer het hele scherm ongecomprimeerd. De hoeveelheid werk hangt af van de inhoud van het scherm en van hoe vaak het wordt bijgewerkt. Zie: Verband tussen scherminhoud en bandbreedte.

flowchart TB
    accTitle: Werk aan het beeld bij typen en scrollen
    accDescr: Een kleine wijziging door één teken en doorlopende updates in een groot gebied verschillen in de aard van het werk om het beeld op te bouwen en te versturen.
    A{"Wijziging in beeld"} -->|"Eén teken toevoegen"| B["Klein gebied"]
    A -->|"Scrollen"| D["Groot gebied, doorlopend"]
    B --> E["Naar wijziging comprimeren, versturen"]
    D --> E

Afbeelding 6: Ook bij dezelfde verbinding verschilt de hoeveelheid werk tussen het toevoegen van één teken en een groot gebied dat voortdurend beweegt.

Ook al is een stilstaand document licht, tijdens het scrollen kan de marge van de beeldoverdracht opraken. Verhoogt u de resolutie of het aantal monitoren aan de externe kant, dan wordt ook het te verwerken beeld groter. De vergelijking met een lagere resolutie is een experiment om te zien of de beweging weer soepel wordt als het werk voor het opbouwen en versturen van het beeld afneemt. Het is geen berekening die de hoeveelheid data alleen uit het aantal pixels bepaalt. Zie: Invloed van resolutie, schermupdates en compressie.

Wachten in de applicatie

Als alleen het zoeken in een bedrijfsapplicatie een paar seconden blijft hangen terwijl u in Kladblok in dezelfde sessie gewoon kunt typen, controleer dan waarop die applicatie wacht. De applicatie op de host stuurt mogelijk zelf weer een zoekopdracht naar een andere database of leest een bestand uit een gedeelde map, en wacht op dat antwoord. Dat is een andere route dan de RDP-verbinding tussen uw computer en de host. Zie: Communicatie van de host naar de back-end.

flowchart TB
    accTitle: Ook achter RDP zijn er communicatiepartners
    accDescr: Toont het geval waarin de applicatie op de host, los van de verbinding tussen het lokale apparaat en de host, wacht op het antwoord van een bedrijfsserver.
    A["Lokaal apparaat"] -->|"RDP"| B["Bedrijfsapplicatie op host"]
    B -->|"Zoeken, bestandsverzoek"| C["DB, gedeelde map"]
    C -->|"verwacht antwoord"| B

Afbeelding 7: De bedrijfsapplicatie achter RDP wacht soms zelf weer op het antwoord van een andere server.

Krijgt de verwerking die verantwoordelijk is voor beeld en invoer een langdurige taak, dan lopen de volgende invoer en de volgende schermupdate vertraging op. In WPF bijvoorbeeld lijdt de reactiesnelheid eronder als de UI-thread lange tijd bezet is. Een laag totaal CPU-gebruik alleen sluit niet uit dat een bepaalde UI-thread wacht. Zie: Dispatcher en UI-thread.

flowchart TB
    accTitle: De verwerking voor beeld en invoer loopt vast
    accDescr: Krijgt de verwerking voor beeld en invoer een lange taak, dan lopen de volgende invoer en schermupdate vertraging op; een laag totaal CPU-gebruik alleen sluit dat wachten niet uit.
    A["Verwerking voor beeld en invoer"] --> B["Krijgt een lange taak"]
    B --> C["Volgende invoer en update vertraagd"]
    C -.- D["Lage totale CPU sluit het niet uit"]

Afbeelding 8: Wachten van de UI-thread is niet uit te sluiten op basis van alleen het totale CPU-gebruik.

Eerste vergelijking per symptoom

De hoeveelheid die kan worden vervoerd, de tijd die u op een antwoord wacht en de tijd om het beeld op te bouwen en weer te geven, zijn drie verschillende dingen. Houdt u dat onderscheid vast, dan schuift u “RDP is traag” niet af op één oorzaak, maar kunt u beginnen bij de handeling die nu traag is.

flowchart TB
    accTitle: Eerst de drie scheiden, dan onderzoeken
    accDescr: Toont dat “RDP is traag” niet op één oorzaak wordt afgeschoven, maar dat de vervoerbare hoeveelheid, de wachttijd op een antwoord en de tijd om het beeld op te bouwen en weer te geven worden gescheiden, en dat wordt begonnen bij de handeling die nu traag is.
    A["“RDP is traag”"] --> S
    subgraph S["Apart bekijken"]
    direction TB
    B["Vervoerbare hoeveelheid"] ~~~ C["Wachttijd op antwoord"]
    C ~~~ D["Beeld opbouwen en tonen"]
    end
    S --> E["Begin bij de trage handeling"]

Afbeelding 9: Als u de vervoerbare hoeveelheid, de wachttijd op een antwoord en de tijd om het beeld op te bouwen en weer te geven scheidt, kunt u beginnen bij de handeling die nu traag is.

Bij het afbakenen gaat het erom de plek te beperken waar u de traagheid onderzoekt. Het doel is niet om instellingen in één keer te wijzigen en het daardoor toevallig sneller te maken. Gebruikt u verschillen als “Kladblok reageert, alleen zoeken blijft hangen” of “typen gaat normaal, alleen scrollen is traag”, dan kunt u al een startpunt voor het onderzoek kiezen voordat u netwerkinstellingen wijzigt.

De volgende tabel is een vertrekpunt voor het onderzoek. Het is geen tabel om de oorzaak vast te stellen. Vergelijk eerst handelingen in dezelfde sessie en wijzig daarna zo nodig het apparaat, de route of de weergave-instellingen.

Vertraagde tekens in meerdere applicaties

Verschijnen tekens in meerdere applicaties in dezelfde sessie één voor één vertraagd, vergelijk dan dezelfde handeling ook vanaf een ander apparaat of via een andere toegestane route. Leg de retourtijd, het wachten op invoer op de host en de totale belasting van de host naast elkaar; de oorzaak wordt niet op basis van één enkele waarde vastgesteld.

Alleen scrollen hapert

Ook als typen normaal gaat, volgen bij het scrollen door een pagina met veel foto’s doorlopend schermupdates in een groot gebied. Wijzig de resolutie of het aantal monitoren aan de externe kant één voor één en vergelijk op dezelfde pagina. Treedt er verbetering op, dan zijn de compressie op de host, de beeldoverdracht en de lokale decodering de volgende onderzoeksonderwerpen. Alleen op basis van de resolutie kunt u niet zeggen welke van deze drie de oorzaak is. Zie: Belasting door scherminhoud en resolutie.

Alleen één applicatie loopt vast

Loopt alleen de bedrijfsapplicatie vast waarin u op zoeken hebt gedrukt, vergelijk dan of Kladblok of iets dergelijks in dezelfde sessie reageert. Werken andere applicaties wel, onderzoek dan eerst de verwerking van de betreffende applicatie, de schijf en de verzoeken aan de database en gedeelde mappen. Dat u via RDP werkt, betekent niet dat de RDP-communicatie de oorzaak van het wachten is. Zie: Prestatiefactoren van applicatie en back-end.

Traag voor iedereen als er veel gebruikers zijn

Wordt het in hetzelfde tijdvak voor meerdere gebruikers traag, vraag de beheerder dan naar de toestand van de andere sessies. Leg de belasting van CPU, geheugen en opslag van de gedeelde host en van de gedeelde lijn naast het tijdstip van de symptomen. Benader gegevens of processen van andere gebruikers niet zonder toestemming en stop hun taken niet. Zie: Resources van gedeelde hosts en aantal gebruikers.

Traag tijdens kopiëren of afdrukken

Valt het probleem samen met het moment waarop u zelf een kopieer- of afdruktaak startte, pauzeer dan ter vergelijking alleen overdrachten die u mag stoppen. Noteer of het na het pauzeren herstelt en of het weer traag wordt bij het hervatten, en onderzoek de concurrentie met andere overdrachten dan het beeld en met apparaatomleiding. Er worden geen vergelijkingen gedaan waarbij apparaten die voor het werk nodig zijn in één keer worden uitgeschakeld. Zie: Gevolgen van apparaatomleiding.

Voorwaarden één voor één vergelijken

U hoeft niet alle instellingen achter elkaar te wijzigen. Leg eerst een basis voor de vergelijking vast en kies alleen de controles die bij het symptoom passen. Sla uw werk op voordat u instellingen wijzigt of opnieuw verbinding maakt, en noteer de oorspronkelijke waarden en hoe u ze terugzet. Ontbreken de benodigde rechten of functies, forceer dan geen activering maar draag het over aan de beheerder.

Bediening direct op de host en bediening via RDP vinden niet per se onder dezelfde omstandigheden plaats. Dat het op het fysieke scherm van de host snel is, is een nuttige aanwijzing, maar de sessie en de renderomstandigheden kunnen verschillen. Breng gebruiker, data en de toestand van de applicatie op één lijn, en beperk de oorzaak niet tot de verbinding alleen omdat het “op het fysieke scherm snel is”.

Dezelfde handeling vergelijken

Zorg voor dezelfde gebruiker, dezelfde data en dezelfde handeling. Controleer op een gedeelde host uw eigen sessie; applicaties en processen van andere gebruikers worden niet gestopt. Ook het gebruik van een ander apparaat of een andere route blijft beperkt tot wat de beheerder heeft toegestaan.

1. Reproduceer de trage handeling met de oorspronkelijke instellingen en noteer het tijdstip en het symptoom.

   Typ in Kladblok in dezelfde externe sessie als de betreffende applicatie ongeveer evenveel tekens. Maak onderscheid tussen alleen één applicatie en de hele sessie.

2. Controleer in hetzelfde tijdvak de belasting op de host en op uw eigen computer.

   Bekijk in Taakbeheer op de host de CPU, het geheugen en de schijf van de betreffende applicatie, en op uw eigen computer de belasting van de RDP-client. Controleer niet alleen de totale CPU-waarde, maar het betreffende proces. Zie: Wat u bij belasting onderzoekt.

3. Wijzig maar één voorwaarde (een ander apparaat, een andere toegestane route of de weergave-instellingen) en herhaal dezelfde handeling.

   Verandert bij een vergelijking tegelijk ook de toestand van de host of de applicatie, noteer dan ook dat verschil. Een resultaat waarbij meerdere voorwaarden zijn veranderd, wordt niet beschouwd als het effect van één voorwaarde.

4. Zet de oorspronkelijke voorwaarden terug en controleer dezelfde handeling opnieuw.

   Blijft het ook na het terugzetten snel, dan kan het ook gaan om een tijdelijke verandering in belasting of iets dergelijks. Ga er niet bij voorbaat van uit dat de wijziging heeft gewerkt, maar noteer onder welke voorwaarden het symptoom optreedt.

Zo hebt u de resultaten van de oorspronkelijke toestand, na de wijziging en na het terugzetten, en kunt u vergelijken welke voorwaarde bij welk symptoom hoort. Een voorwaarde die verbetering bracht, is een aanwijzing voor het onderzoek en op zichzelf geen bewijs van de grondoorzaak.

flowchart TB
    accTitle: Het aantal tegelijk gewijzigde voorwaarden beperken
    accDescr: De werkwijze om in de oorspronkelijke toestand een reproduceerbare handeling te kiezen, maar één voorwaarde te wijzigen en te vergelijken, en ook het resultaat na het terugzetten te controleren.
    A["Zelfde handeling, oorspronkelijk"] --> B["Maar één voorwaarde wijzigen"]
    B --> C["Zelfde handeling herhalen"]
    C --> D["Terugzetten en opnieuw controleren"]
    D --> E["Voorwaarde met verbetering noteren"]

Afbeelding 10: Herhaal dezelfde handeling in de oorspronkelijke toestand, na de wijziging en na het terugzetten, en noteer de voorwaarde waarbij iets veranderde.

Resolutie aan de externe kant vergelijken

Deze vergelijking doet u als schermupdates zwaar zijn, bijvoorbeeld bij scrollen. Noteer de resolutie en het aantal monitoren vóór de wijziging, sla uw werk op en maak daarna opnieuw verbinding. Instellingen die de voor het werk benodigde schermruimte of de leesbaarheid van tekst aantasten, worden niet zonder meer blijvend gebruikt.

1. Wijzig alleen het aantal monitoren of alleen de resolutie.

   In mstsc kunt u vergelijken via de instellingen op het tabblad “Beeldscherm” vóór het verbinden of door breedte en hoogte op te geven. Zie: Beeldinstellingen voor mstsc.

2. Controleer of de werkelijke grootte van het bureaublad op de host is veranderd en scrol door dezelfde pagina.

   Als u alleen het venster op uw computer verkleint, wordt mogelijk een groot bureaublad verkleind weergegeven. Maak onderscheid tussen dynamische resolutie en smart sizing, en controleer welke voorwaarden de gebruikte client ondersteunt. Zie: Bureaubladresolutie en weergaveschaal.

3. Zet de oorspronkelijke instelling terug, herhaal dezelfde handeling en vergelijk de belasting aan beide kanten en de beweging op het scherm.

   Hebt u tegelijk overgeschakeld naar een lage resolutie en één monitor, dan blijft het bij een grove vergelijking. Treedt er verbetering op, zet ze dan één voor één terug om hun invloed te scheiden.

Treedt er verbetering op, dan ligt er een aanwijzing op het gebied van beeldverwerking en beeldoverdracht. 3840×2160 heeft vier keer zoveel pixels als 1920×1080, maar de hoeveelheid data wordt niet altijd vier keer zo groot. Die hangt af van de gewijzigde delen en de compressie, en een andere resolutie beïnvloedt ook de verwerking aan beide kanten. Zie: Verband tussen aantal pixels en hoeveelheid data, Beeldverwerking controleren.

flowchart TB
    accTitle: Wat de vergelijking met een lagere resolutie laat zien
    accDescr: Een lagere resolutie aan de externe kant kan zowel de belasting van de beeldverwerking als die van de overdracht veranderen; verbetering alleen beperkt de oorzaak dus niet tot de verbinding.
    A["Resolutie externe kant verlagen"] --> S
    subgraph S["Wat verandert"]
    direction TB
    B["Beeldverwerking op host"] ~~~ C["Verstuurde hoeveelheid data"]
    C ~~~ D["Lokale weergaveverwerking"]
    end

Afbeelding 11: Het wijzigen van de resolutie is een vergelijking die niet alleen de verbinding raakt, maar ook de beeldverwerking op de host en op uw eigen computer.

Kopiëren en afdrukken naast het symptoom leggen

U pauzeert alleen processen die u mag stoppen, zoals een overdracht die u zelf hebt gestart. Back-up- en beveiligingsprocessen van het bedrijf en taken van andere gebruikers worden niet gestopt. De omleiding van audio- en invoerapparaten die voor het werk nodig zijn, wordt niet in één keer uitgeschakeld.

1. Noteer vóór de start en tijdens het kopiëren, de cloudsynchronisatie of het afdrukken dezelfde handeling en de belasting.

   Via RDP stroomt naast het beeld ook informatie voor stations, printers en dergelijke. Omleiding waarmee apparaten van uw computer op de host worden gebruikt, kan tijdens het gebruik de netwerk- en verwerkingsbelasting verhogen. Zie: Gevolgen van apparaatomleiding.

2. Pauzeer de betreffende overdracht binnen de toegestane grenzen en controleer dezelfde handeling opnieuw.

   Als u kunt vergelijken door te hervatten, noteer dan ook het symptoom na het hervatten. Ook als u het uitschakelen van overbodige apparaatomleidingen uitprobeert, wijzigt u ze één voor één en zorgt u ervoor dat u kunt terugkeren naar de oorspronkelijke instelling.

Zo kunt u beoordelen of het begin van de overdracht en het probleem, en het pauzeren en het herstel, met elkaar samenvallen. Ziet u een verband, leg dan andere overdrachten dan het beeld en de belasting van gedeelde resources naast de gegevens van de beheerder.

flowchart TB
    accTitle: Vóór en na het probleem op dezelfde tijdlijn bekijken
    accDescr: Vóór, tijdens en na het pauzeren van een overdracht worden dezelfde handeling en de belasting genoteerd, en wordt het verband tussen het probleem en de taak vergeleken.
    A["Handeling en belasting vóór overdracht"] --> B["Handeling en belasting tijdens overdracht"]
    B --> C["Handeling en belasting na pauzeren"]
    C --> D["Vallen probleem en herstel samen?"]

Afbeelding 12: Bekijk hoe de traagheid en de belasting van dezelfde handeling veranderen vóór, tijdens en na het pauzeren van de overdracht.

Meten waar gewacht wordt

Vanaf uw eigen computer onderzoekt u de netwerkretour en de TCP-verbinding, op de host het wachten in de invoerwachtrij en de schermupdates. Omdat elke waarde maar een beperkt traject meet, leest u de resultaten naast de tabel in “Reikwijdte van de meetresultaten”.

ICMP en TCP-verbinding controleren

U voert dit uit op uw lokale Windows-apparaat. Het gaat alleen om configuraties waarbij u via het bedrijfs-LAN of een toegestane VPN rechtstreeks verbinding maakt met een RDP-host die de standaardpoort TCP 3389 gebruikt. Bepaal bij configuraties via RD Gateway of Azure Virtual Desktop, of met een eigen poort, samen met de beheerder wat u controleert. Er worden geen poorten opengezet en de firewall wordt niet gewijzigd.

1. Voer de toegestane host in en noteer de resultaten van het ICMP-antwoord en de TCP-verbinding.

   $target = Read-Host 'Naam of IP-adres van de RDP-host die u mag onderzoeken'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Geef de host op.'
   }
       
   # Bekijk de ICMP-antwoordtijden meerdere keren. Mislukken alleen betekent niet dat RDP onbereikbaar is.
   ping.exe -n 20 $target
       
   # Controle alleen voor configuraties met een directe verbinding met de standaardpoort TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Leg de resultaten uit trage en normale tijdvakken naast het tijdstip van de symptomen en de werkelijke verbindingsroute.

   Twintig keer ping is een korte observatie. Noteer schommelingen in de waarden en uitblijvende antwoorden, maar ICMP kan ook geblokkeerd zijn. Sluit onderbrekingen die af en toe optreden niet uit op basis van alleen de gemiddelde waarde, maar gebruik de verbindingsinformatie en de netwerkgegevens van de beheerder. Zie: Wat ping meet.

TcpTestSucceeded: True betekent dat de TCP-verbinding met de opgegeven poort is gelukt. Bandbreedte, UDP, bediening na de verificatie en de vloeiendheid van het beeld worden daarmee niet gemeten. Test-NetConnection heeft geen -UDP-schakeloptie om UDP te controleren. Zie: Syntaxis en resultaten van Test-NetConnection.

Beoordeel de resultaten met oog voor de verschillen in route en dienst. Bij RD Gateway en dergelijke komt de route van ICMP of een directe TCP-verbinding naar de host mogelijk niet overeen met de werkelijke RDP-route. In Azure Virtual Desktop zijn de RTT en de geschatte bandbreedte per verbinding beschikbaar, maar die diagnosefunctie is bedoeld voor die dienst. Korte onderbrekingen worden niet uitgesloten op basis van alleen gemiddelde waarden. Zie: Logboeken voor verbindingskwaliteit in Azure Virtual Desktop.

flowchart TB
    accTitle: Gecontroleerde route en werkelijke RDP-route
    accDescr: In configuraties met RD Gateway of iets vergelijkbaars komt de route van ICMP of een directe TCP-verbinding van het lokale apparaat naar de host mogelijk niet overeen met de werkelijke RDP-route.
    A["Lokaal apparaat"] -->|"ICMP, directe TCP"| C["RDP-host"]
    A -->|"Werkelijke RDP"| B["RD Gateway e.d."]
    B --> C

Afbeelding 13: ICMP of een directe TCP-verbinding naar de host en de werkelijke RDP volgen mogelijk niet dezelfde route.

Wachttijd in de invoerwachtrij meten

User Input Delay meet de wachttijd vanaf het moment dat invoer op de host in de wachtrij komt tot het proces die eruit haalt. Het is niet de totale tijd van het indrukken van een toets tot het teken zichtbaar is. Zie: Definitie van User Input Delay.

U onderzoekt dit binnen de externe sessie op de host. Volgens Microsoft worden Windows 10 versie 1809 of later en Windows Server 2019 of later ondersteund. Voor deze systemen hoeft u geen registerwaarde toe te voegen om het in te schakelen. Controleer de weergavenaam, de rechten en of het prestatiemeteritem aanwezig is; is het niet beschikbaar, noteer dat dan en overleg met de beheerder. Zie: Voorwaarden en instellingen.

1. Noteer in PowerShell in dezelfde sessie het tijdstip en de sessie-ID.

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

   Om sessies van andere gebruikers op te vragen, zijn mogelijk extra rechten nodig. De standaardnaam van de instantie voor het betreffende proces is SessionID:ProcessID <Process Image>. Zorg dat u niet alleen op basis van de sessie-ID waarden van andere gebruikers of van processen met dezelfde naam door elkaar haalt. Zie: Rechten voor query session, Instanties identificeren.

2. Voeg in perfmon.exe het beschikbare prestatiemeteritem User Input Delay per Process of User Input Delay per Session toe.

   Kies het betreffende proces of de betreffende sessie en observeer eerst met het standaardinterval van 1 seconde. Maak onderscheid tussen de verzamelinstantie die meerdere sessies samenvoegt en de waarden van afzonderlijke sessies.

3. Reproduceer de handeling met trage invoer en vergelijk het wachten in de wachtrij met het tijdstip van het symptoom.

   Bij een afzonderlijk meetobject wordt gekeken naar de maximale wachttijd binnen het meetinterval. Ook als de waarde laag is, blijven de verwerking nadat de applicatie de invoer heeft opgehaald en de vertraging tot het resultaat terug is op uw computer bestaan.

Zo kunt u onderzoeken of er in de invoerwachtrij op de host wordt gewacht. Het is een andere maatstaf dan de ervaren tijd, waarin de netwerkretour en de weergave op uw computer zijn inbegrepen. Zie: Betekenis van de maximumwaarde en het meetinterval.

flowchart TB
    accTitle: Het traject dat User Input Delay meet
    accDescr: Gemeten wordt het traject van de invoerwachtrij op de host tot de applicatie de invoer ophaalt; de communicatie ervoor en erna en de beeldweergave vallen erbuiten.
    A["Invoer komt van lokaal apparaat"] --> B["In invoerwachtrij van de host"]
    B -->|"Dit wordt gemeten"| C["Applicatie haalt invoer op"]
    C --> D["Verwerking en beeldoverdracht"]
    D --> E["Lokaal weergegeven"]

Afbeelding 14: Gemeten wordt het wachten in de invoerwachtrij op de host. Dat is iets anders dan de totale tijd tot het resultaat op uw computer zichtbaar is.

Schermupdates en redenen voor overgeslagen frames onderzoeken

Zorg voor een handeling met doorlopende schermupdates, zoals scrollen. Of de prestatiemeteritems RemoteFX Graphics beschikbaar zijn en waar ze meten, moet u controleren afhankelijk van het besturingssysteem, de hostconfiguratie en de rechten. Hier worden alleen beschikbare prestatiemeteritems uitgelezen. Het is geen procedure om de oude RemoteFX-functie te installeren of in te schakelen. Zie: Toepassingsvoorwaarden van de Graphics-prestatiemeteritems.

1. Stel met query session of qwinsta de naam van de betreffende sessie vast en kies de bijbehorende instantie van het prestatiemeteritem.

2. Vergelijk tijdens een handeling met schermupdates Input Frames/Second en Output Frames/Second.

   Is de uitvoer kleiner dan de invoer, dan worden er onderweg frames overgeslagen. Controleer de waarden van Frames Skipped/Second per oorzaak: te weinig resources op de host, in het netwerk of op de client.

3. Leg de redenen voor overgeslagen frames naast de belasting aan beide kanten en in het netwerk, en controleer ook Average Encoding Time.

   Is de coderingstijd lang, onderzoek dan de compressie op de host. Is het aantal frames al aan de invoerkant laag, dan werkt de applicatie het scherm mogelijk ook gewoon niet vaak bij. Een laag aantal frames bij een stilstaand scherm is op zich geen afwijking.

Aan de hand van invoer en uitvoer tijdens schermupdates, de redenen voor overgeslagen frames en de coderingstijd kunt u afbakenen waar u verder zoekt. De indeling van de prestatiemeteritems is een aanwijzing; u beoordeelt die samen met de werkelijke belasting en de verbindingsconfiguratie. Zie: Aantal frames en coderingstijd lezen.

flowchart TB
    accTitle: Via overgeslagen frames afbakenen waar u zoekt
    accDescr: Tijdens een handeling met schermupdates worden de invoer- en uitvoerframes vergeleken, en met de prestatiemeteritems voor de redenen van overgeslagen frames wordt dat naast de belasting van verwerking, overdracht en weergave gelegd.
    A["In-/uitvoer bij scrollen vergelijken"] --> B["Minder uitvoer: overslaan nagaan"]
    B --> C["Items per reden bekijken"]
    C --> D["Naast belasting host, netwerk, lokaal"]

Afbeelding 15: Vergelijk invoer en uitvoer tijdens het scrollen en leg de redenen voor overgeslagen frames naast de belasting op de host, op de lijn en op uw eigen computer.

Conceptdiagrammen van de beeldoverdracht en oudere documentatie worden niet gegeneraliseerd naar alle configuraties. Er zijn ook configuraties die video en audio via een apart mechanisme overdragen. Omdat de documentatie over de Graphics-prestatiemeteritems ook beschrijvingen van oudere configuraties bevat, worden de vermelde getallen niet gelezen als een algemene specificatie in de trant van “elke RDP haalt maximaal 30 fps”. Controleer waarop functies en getallen van toepassing zijn voordat u ze gebruikt. Zie: Beeldoverdracht en workloads, Documentatie over de Graphics-prestatiemeteritems.

Reikwijdte van de meetresultaten

Een lage waarde wordt niet gelijkgesteld aan prettige bediening. De reikwijdte van elke maatstaf kunt u nagaan in de Microsoft-documentatie die bij de stappen is genoemd.

Netwerk- en GPU-instellingen

UDP- en GPU-instellingen kiest u op basis van wat vergelijkingen en metingen hebben opgeleverd. Valt de verdenking op het netwerk, controleer dan eerst het transport en de route; valt die op de beeldverwerking, controleer dan eerst in welke fase de GPU wordt gebruikt.

TCP/UDP en verbindingsroute controleren

Wijzen vergelijkingen en metingen op het netwerk, controleer dan samen met de beheerder de gebruikte client, de route en het toegepaste beleid. Ook als instellingen moeten worden gewijzigd, blijft dat beperkt tot wat is goedgekeurd; noteer de waarden vóór de wijziging en hoe u ze herstelt. De firewall of de verificatie wordt niet uitgeschakeld, en de RDP-poort wordt niet rechtstreeks op internet opengezet.

1. Controleer aan de hand van de verbindingsinformatie, de diagnostische logboeken van het product en de netwerkgegevens van de beheerder of er werkelijk TCP of UDP wordt gebruikt en via welke route.

   RDP gebruikt afhankelijk van de configuratie en de netwerkomstandigheden TCP of UDP. Bij “Select RDP transport protocols” kunt u kiezen tussen een instelling die UDP of TCP gebruikt en een instelling met alleen TCP. Omdat er ook gedrag bestaat waarbij TCP wordt gebruikt als er geen UDP-verbinding tot stand komt, zegt een geslaagde verbinding alleen nog niets over het transport. Zie: Keuze van het RDP-transport en terugval.

2. Leg de route en het transport naast het tijdstip van de symptomen en vergelijk alleen de nodige instellingen, één voor één.

   Pas niet als algemene regel iets aan op grond van “zonder UDP wordt het sneller”. Vergelijk bij gelijke VPN- en gatewayomstandigheden, dezelfde handeling en dezelfde weergave-instellingen, en draai onnodige wijzigingen terug.

Als u het transport en de route kent, kunt u het verband tussen wijziging en symptoom vastleggen. Overstappen op alleen TCP maakt het niet altijd sneller.

flowchart TB
    accTitle: Eerst het transport controleren, dan netwerkinstellingen vergelijken
    accDescr: Een gewone directe verbinding wordt onderscheiden van verbindingen via een gateway of dienst; pas na controle van de werkelijke route en het transport worden toegestane vergelijkingen uitgevoerd.
    A["Gebruikte client en verbindingsconfiguratie"] --> B["Werkelijke route, TCP of UDP controleren"]
    B --> C["Naast tijdstip van symptomen leggen"]
    C --> D["Alleen nodige instellingen één voor één"]

Afbeelding 16: Stel het gebruikte transport en de route vast, leg ze naast het symptoom en vergelijk pas daarna alleen de nodige instellingen.

RDP Shortpath is een mechanisme van Azure Virtual Desktop. Het zet een UDP-route van die dienst op en gebruikt afhankelijk van de configuratie een directe route of een relay. Lukt dat niet, dan valt het terug op een op TCP gebaseerde verbinding. Het past niet in dezelfde instellingentabel als een directe verbinding met mstsc naar een pc in het bedrijf. Zie: Routes en terugval van RDP Shortpath.

flowchart TB
    accTitle: Routes en terugval van RDP Shortpath
    accDescr: RDP Shortpath van Azure Virtual Desktop probeert een UDP-route op te zetten; lukt dat, dan wordt afhankelijk van de configuratie een directe route of een relay gebruikt, en anders valt de verbinding terug op een op TCP gebaseerde verbinding.
    A["RDP Shortpath"] --> B{"UDP-route"}
    B -->|"opgezet"| C["Direct of relay"]
    B -->|"mislukt"| D["Terug naar TCP-basis"]

Afbeelding 17: Kan RDP Shortpath geen UDP-route opzetten, dan valt het terug op een op TCP gebaseerde verbinding.

GPU-gebruik bij beeldverwerking controleren

Deze controle doet u als vergelijkingen en metingen op de beeldverwerking wijzen. Controleer de meetresultaten van de beeldverwerking en het ondersteunde besturingssysteem, de drivers, het beleid en de client. Alleen omdat er een GPU aanwezig is, worden geen instellingen gewijzigd. Zorg eerst voor goedkeuring van de beheerder en bereid het terugzetten voor.

1. Scheid het renderen door de applicatie op de host, de RDP-codering en de lokale decodering, en kies de verdachte fase.

   Ook als er een GPU is, gebruiken niet per se alle fasen de GPU. Ook in de configuratiedocumentatie van Microsoft voor Azure Virtual Desktop worden het renderen van de externe sessie en de hardwarecodering van frames apart ingesteld en gecontroleerd. Zie: GPU-configuratie en -controle voor renderen en coderen.

2. Controleer volgens de procedure van het betreffende product het werkelijke gebruik en meet dezelfde handeling vóór en na de nodige wijziging.

   Is de compressietijd lang, onderzoek dan het GPU-gebruik voor de codering. Bij een applicatie die in de invoerwachtrij wacht, mikt een wijziging van de coderingsinstellingen op de verkeerde plek. Voor de leesbaarheid van tekst en voor vloeiende video maakt u ook andere keuzes in beeldkwaliteit, hoeveelheid data en verwerkingsbelasting. Zie: Verschillen per workload.

Zo kunt u, verder dan alleen of er een GPU is, vastleggen of de GPU in de probleemfase wordt gebruikt en hoe de belasting en de reactie bij dezelfde handeling zijn veranderd. Wijzigingen zonder verbetering draait u na overleg met de beheerder terug.

flowchart TB
    accTitle: GPU-gebruik per fase controleren
    accDescr: Het renderen door de applicatie op de host, de RDP-codering en de lokale decodering worden gescheiden; omdat ook met een GPU niet per se alle fasen de GPU gebruiken, wordt het gebruik in de verdachte fase gecontroleerd.
    A["Renderen door applicatie op host"] --> B["RDP-codering"]
    B --> C["Lokale decodering"]
    C -.- D["GPU-gebruik per fase controleren"]

Afbeelding 18: Ook met een GPU gebruiken renderen, coderen en decoderen niet per se allemaal de GPU.

Opnieuw controleren en overdragen

Een verbetering bevestigt u doordat dezelfde handeling na de wijziging zonder problemen lukt en daarnaast de benodigde beeldkwaliteit, apparaten en bedrijfsfuncties behouden blijven. Vergelijk ook het resultaat na het terugzetten naar de oorspronkelijke voorwaarden. Gaat het alleen om een kortstondig herstel, dan wordt de oorzaak niet vastgesteld; leg de resultaten vast inclusief drukke tijdvakken en gelijktijdige processen.

flowchart TB
    accTitle: Volgorde om een verbetering te bevestigen
    accDescr: Toont dat na de wijziging wordt gecontroleerd of dezelfde handeling zonder problemen lukt en of daarnaast de benodigde beeldkwaliteit, apparaten en bedrijfsfuncties behouden blijven, dat dit wordt vergeleken met het resultaat na het terugzetten, en dat een kortstondig herstel alleen de oorzaak niet vaststelt.
    A["Na wijziging zelfde handeling testen"] --> B["Beeld, apparaten, functies controleren"]
    B --> C["Vergelijken met teruggezette toestand"]
    C -.- D["Kort herstel stelt niets vast"]

Afbeelding 19: Vergelijk naast het resultaat van dezelfde handeling ook de benodigde functies en het resultaat na het terugzetten.

Overdracht als het probleem niet is opgelost

Ook als er geen verbetering is, het probleem niet te reproduceren is of prestatiemeteritems niet beschikbaar zijn, is dat een bruikbaar resultaat. Scheid de vergelijkingen die u kon uitvoeren van de controles die niet lukten, en draag het met de volgende notitie over aan beheerders en ontwikkelaars. Verwijder uit gedeelde logboeken bedrijfsinformatie die voor het onderzoek niet nodig is, zoals gebruikersnamen en hosts.

Tijdstip van het symptoom en tijdzone:
Besturingssysteem van de host, gebruikte client en versie:
Directe verbinding / VPN / RD Gateway / Azure Virtual Desktop e.d.:
Trage handeling en applicatie, reactie van andere applicaties in dezelfde sessie:
Resolutie en aantal monitoren aan de externe kant:
Gelijktijdig kopiëren, afdrukken e.d.:
Enige gewijzigde voorwaarde en resultaat na terugzetten:
Op host en lokaal apparaat waargenomen belasting of prestatiemeteritems:

Vermeld daarnaast of het werkelijk gebruikte TCP of UDP kon worden vastgesteld, welke punten niet konden worden gecontroleerd, bijvoorbeeld door onvoldoende rechten, en welke instellingen voor het werk aanvaardbaar zijn. Als u in plaats van “de verbinding is traag” doorgeeft “in Kladblok kan ik gewoon typen, maar bij het scrollen door foto’s blijft het hangen”, kan de volgende behandelaar onder dezelfde voorwaarden onderzoeken.

Gebruikers leggen de reproducerende handeling en de vergelijkingsresultaten vast, beheerders leggen de gegevens van verbindingsroute, gedeelde host en sessies naast elkaar. Alleen het feit dat er onder RDP wordt gewacht, betekent niet dat ook de verwerking die het wachten veroorzaakt RDP is. Zie: Taakverdeling tussen host en back-end.

Applicatieontwikkelaars leggen het ontvangen van invoergebeurtenissen, het begin en einde van database- en bestandsverwerking en het bijwerken van de UI apart vast. Ze overwegen ook een ontwerp waarbij zwaar werk niet op de UI-thread blijft hangen. Een logboek over de voltooiing van de verwerking op de host registreert echter niet de voltooiing van de weergave op de lokale computer. Zie: Verwerking scheiden om de UI responsief te houden.

Gerelateerde artikelen

• Hoe u Windows-sessie-isolatie begrijpt
• Schijfgebruik van 100% in Windows veilig uitzoeken
• Waarom eindigt “nog 1 seconde” maar niet?

Bronnen

Dit zijn primaire bronnen van Microsoft Learn. De geraadpleegde inhoud is op 17 september 2026 gecontroleerd. Lees ze met oog voor de toepassingsvoorwaarden per product en voor het feit dat het geen metingen zijn die in dit artikel zijn uitgevoerd.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Onderscheid tussen RTT en de vertraging van schermopname op de host tot weergave op de lokale computer. De diagnosefunctie zelf is bedoeld voor Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Verband tussen scherminhoud, resolutie, frame-updates, compressie, caching en hoeveelheid data.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Hoe u invoer en uitvoer van het beeld, redenen voor overgeslagen frames en coderingstijd controleert. Omdat ook oudere configuraties worden beschreven, worden de numerieke bovengrenzen niet gegeneraliseerd naar elke RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Belasting van gedeelde hosts, communicatie van de host naar de back-end en gevolgen van apparaatomleiding.
• Microsoft Learn, Threading model. UI-thread en Dispatcher in WPF, en het scheiden van verwerking om de reactiesnelheid te behouden.
• Microsoft Learn, mstsc. Opgeven van breedte, hoogte en meerdere monitoren voor extern bureaublad.
• Microsoft Learn, Supported RDP properties. Onderscheid tussen bureaubladresolutie, dynamische resolutie en smart sizing. Controleer de ondersteunde clients en de toepassingsvoorwaarden per product.
• Microsoft Learn, ping. Controle van het antwoord via ICMP Echo, en opties.
• Microsoft Learn, Test-NetConnection. Controle van de TCP-verbinding en betekenis van de uitvoer.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Meettraject van User Input Delay, ondersteunde besturingssystemen, instanties en betekenis van de maximumwaarde.
• Microsoft Learn, query session. Sessie-informatie en de rechten die nodig zijn om andere sessies op te vragen.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Keuze van TCP en UDP voor RDP, en terugval.
• Microsoft Learn, RDP Shortpath. UDP-route voor Azure Virtual Desktop en het gedrag als die niet kan worden opgezet.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. GPU-configuratie en -controle, gescheiden naar renderen en framecodering.

Gerelateerde artikelen

Recente artikelen met dezelfde tags. Verdiep uw kennis met nauw verwante onderwerpen.

Gerelateerde onderwerpen

Onderwerppagina’s die dicht bij dit thema liggen. Vanuit dit artikel kunt u doorklikken naar verwante diensten en andere artikelen.

Diensten bij dit thema

Dit artikel sluit aan op de volgende dienstpagina’s. Kies een ingang die dicht bij uw vraag ligt.

Veelgestelde vragen

Vragen die tijdens een adviesgesprek vaak over het thema van dit artikel worden gesteld.

De snelheidstest haalt honderden Mbit/s. Waarom is invoer in RDP dan toch traag?

Hoe snel grote hoeveelheden data worden vervoerd en hoe lang het duurt voordat er een reactie op een handeling terugkomt, zijn twee verschillende dingen. Het versturen van de invoer, de verwerking in de applicatie op de host, de compressie van het beeld, de overdracht en de weergave op uw eigen computer spelen allemaal mee. Bovendien verschilt de netwerkroute naar de server van de snelheidstest van die naar de RDP-host.

Typen gaat normaal, alleen scrollen hapert. Ligt dat aan de verbinding?

Dat valt niet alleen tot de verbinding te herleiden. Als het aantal schermupdates toeneemt, kan ergens iets het niet bijbenen: het renderen en comprimeren op de host, de overdracht of het decoderen en weergeven op uw eigen computer. Wijzig de resolutie en het aantal monitoren aan de externe kant één voor één en vergelijk; onderzoek zo nodig de prestatiemeteritems voor het renderen.

Als ping snel is, is de RDP-communicatie dan in orde?

Dat is daaruit alleen niet op te maken. ping meet de reactie op ICMP, niet de beeldoverdracht van RDP of de verwerking in de applicatie. In configuraties met RD Gateway of iets vergelijkbaars komt ook de route mogelijk niet overeen. Maak ook als er geen antwoord komt onderscheid tussen geblokkeerd ICMP en een RDP-verbinding die zelf onbereikbaar is.

Is User Input Delay de tijd van het indrukken van een toets tot het verschijnen van het teken?

Nee. Het is een prestatiemeteritem dat de wachttijd meet vanaf het moment dat invoer op de host in de wachtrij komt tot het proces die eruit haalt. Het is niet de ervaren vertraging inclusief de netwerkretour, de verwerking in de applicatie na het ophalen en de compressie, decodering en weergave van het beeld.

Moet ik UDP uitschakelen als RDP traag is?

Dat raden wij niet als algemene regel aan. Controleer eerst het werkelijke transport, de route en het toegepaste beleid. Het kan zijn dat UDP niet bruikbaar is en de verbinding al is teruggevallen op TCP; overstappen op alleen TCP maakt het niet altijd sneller. Vergelijk met toestemming van de beheerder onder gelijke omstandigheden en draai onnodige wijzigingen terug.

Profiel van de auteur

De profielpagina van de auteur van dit artikel.

Go Komura

Vertegenwoordiger van KomuraSoft LLC

Richt zich op Windows-softwareontwikkeling, technisch advies en foutanalyse, en is vooral sterk in projecten waarin bestaande assets behouden blijven en in storingsonderzoek waarbij de oorzaak moeilijk zichtbaar is.