Warum ist RDP über eine schnelle Verbindung träge? — Eingabe, Bildaufbau und Netzwerk getrennt untersuchen

Der Speedtest zeigt mehrere Hundert Mbit/s, doch im Remotedesktop erscheinen Zeichen mit leichter Verzögerung. Beim Scrollen durch eine Seite mit vielen Fotos ruckelt der Bildschirm. Nur wenn Sie in einer Geschäftsanwendung die Suche auslösen, hängt die Anwendung einige Sekunden. Wo sollten Sie bei einem solchen Zustand – „die Leitung ist schnell, aber RDP ist träge“ – mit der Untersuchung beginnen?

Die Bedienreaktion in RDP hängt nicht allein von der Übertragungsrate der Leitung ab. Auch wenn der Speedtest schnell ist, kann an irgendeiner Stelle Wartezeit entstehen: beim Netzwerk-Roundtrip, bei der Eingabewartezeit der Anwendung auf dem Host, bei der Codierung des Bildschirms oder bei Decodierung und Anzeige auf Ihrem eigenen Rechner. Trennen Sie zuerst nach „Welche Aktion ist langsam?“ und vergleichen Sie dieselbe Aktion, wobei Sie jeweils nur eine Bedingung ändern. Grenzen Sie den Untersuchungsbereich durch Vergleiche und Messungen ein und wählen Sie UDP- und GPU-Einstellungen passend zu diesen Ergebnissen. Siehe: Messabschnitte der Verbindungsqualität, Leistungsfaktoren von Sitzungshosts.

Allerdings ist die Grundursache in dem Stadium, in dem Sie den Untersuchungsbereich eingegrenzt haben, noch nicht festgestellt. Auch wenn eine niedrigere Auflösung Besserung bringt, ändert sich nicht nur die Übertragung, sondern auch die Bildschirmverarbeitung an beiden Enden; daher wird daraus nicht gefolgert, dass „die Leitung die Ursache war“. Halten Sie die Ergebnisse fest und trennen Sie dabei gemessene von nicht gemessenen Abschnitten.

Dieser Artikel grenzt Eingabe, Bildlauf und Anwendungsreaktion nach dem Verbindungsaufbau ein. Auch bei ähnlichen Symptomen gibt es nicht unbedingt nur eine Ursache. Fälle wie „es dauert lange, bis der Anmeldebildschirm erscheint“ oder „es hängt nur bei der Authentifizierung“ werden als separates Problem behandelt, das anhand der Protokolle zu Verbindungsaufbau und Authentifizierung untersucht wird.

Zielgruppe sind vor allem Benutzer und Administratoren, die sich mit der Windows-App „Remotedesktopverbindung“ (mstsc) mit Windows 11 oder Windows Server verbinden. Die Befehlsbeispiele sind für Windows PowerShell 5.1 gedacht. Vorausgesetzt wird, dass sich dieselbe Aktion in einer bestehenden Sitzung reproduzieren lässt.

Bei Direktverbindung, VPN, RD Gateway und Azure Virtual Desktop unterscheiden sich der Pfad, die verfügbaren Diagnoseinformationen und der Geltungsbereich der Einstellungen. Das Prüfbeispiel für TCP 3389 gilt nur für eine erlaubte Direktverbindung zu einem RDP-Host, der den Standardport verwendet. Diagnosefunktionen und GPU-Einstellungen aus Dokumentation für Azure Virtual Desktop werden nicht unverändert auf gewöhnliche Firmen-PCs übertragen.

Auf Firmengeräten untersuchen Sie nur in dem Umfang, den der Administrator erlaubt hat. Identifizieren Sie auf einem gemeinsam genutzten Host Ihre eigene Sitzung und den betroffenen Prozess, und wenden Sie sich an den Administrator, wenn Sie Aufzeichnungen anderer Benutzer benötigen. Ob Leistungsindikatoren verfügbar sind, wie sie angezeigt werden und welche Berechtigungen nötig sind, prüfen Sie für jede Umgebung.

Die hier gezeigten Prüfmethoden beruhen auf offizieller Dokumentation. Sie sind kein Messbericht darüber, dass ein Fehler auf einem bestimmten Gerät reproduziert und behoben wurde. Zahlenbeispiele werden als Annahmen zur Erklärung kenntlich gemacht.

Den Mechanismus können Sie der Reihe nach lesen, beginnend mit dem nächsten Abschnitt „Übertragungsrate und Roundtrip-Zeit“. Wenn Sie bei den Symptomen ansetzen möchten, gehen Sie zu „Erster Vergleich nach Symptom“. Die Arbeitsschritte finden Sie unter „Bedingungen einzeln vergleichen“ und „Messen, wo gewartet wird“.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (7 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

Übertragungsrate und Roundtrip-Zeit

RDP (Remote Desktop Protocol) ist ein Protokoll, mit dem Eingaben, Bildschirminformationen und Ähnliches zwischen Ihrem eigenen Gerät und dem Host ausgetauscht werden. Es überträgt nicht nur Bildschirm und Eingaben, sondern auch Informationen für Geräteumleitung, Drucken und Ähnliches. Siehe: Von RDP übertragene Informationen.

Die Übertragungsrate einer Leitung gibt an, wie viele Daten pro Sekunde transportiert werden können. Die „500 Mbit/s“ eines Speedtests sind eine Zahl für diese Menge. Sie geben nicht an, wie lange es von einer Aktion bis zum Eintreffen der Antwort dauert. Siehe: Bandbreitenanforderungen von RDP.

flowchart TB
    accTitle: Was die Zahl eines Speedtests aussagt
    accDescr: Die 500 Mbit/s eines Speedtests geben an, wie viele Daten pro Sekunde transportiert werden können; das ist eine andere Zahl als die Zeit von einer Aktion bis zum Eintreffen der Antwort.
    A["Speedtest: 500 Mbit/s"] --> B["Daten pro Sekunde"]
    B -.->|"andere Zahl"| C["Zeit bis zur Antwort"]

Abbildung 1: Die Zahl des Speedtests gibt die transportierbare Menge an, nicht die Zeit, bis eine Antwort eintrifft.

Die Roundtrip-Zeit (RTT) ist die Zeit, die eine Übertragung bis zur Gegenstelle und wieder zurück braucht. Der Unterschied zwischen einer höheren Übertragungsrate und einer kürzeren Roundtrip-Zeit ähnelt dem Unterschied zwischen zusätzlichen Fahrspuren auf einer Straße und einer kürzeren Strecke zum Ziel. Auch wenn die Kapazität für den Transport großer Dateimengen wächst, bleibt bei gleicher Roundtrip-Zeit das Warten auf die Antwort auf eine Aktion bestehen. Siehe: RTT und Verzögerung der Bildschirmanzeige.

flowchart TB
    accTitle: Übertragungsrate und Roundtrip-Zeit als Straße
    accDescr: Die Abbildung vergleicht das Erhöhen der Übertragungsrate mit zusätzlichen Fahrspuren einer Straße und das Verkürzen der Roundtrip-Zeit mit einer kürzeren Strecke zum Ziel.
    A["Übertragungsrate erhöhen"] -->|"als Straße"| B["Mehr Fahrspuren"]
    B ~~~ C["Roundtrip-Zeit verkürzen"]
    C -->|"als Straße"| D["Kürzere Strecke"]

Abbildung 2: Mehr Fahrspuren verkürzen die Strecke zum Ziel nicht.

Bis das Ergebnis eines Zeichens zurückkommt

Nehmen wir an, Sie tippen ein Zeichen in den Editor auf dem Remoterechner. Der Editor läuft auf dem Host. Nimmt man zur Erklärung an, dass die Aktion 50 Millisekunden bis zum Host braucht und die Bildschirminformationen mit dem Ergebnis 50 Millisekunden für den Rückweg, beträgt die Zeit für die Übertragung insgesamt 100 Millisekunden, also 0,1 Sekunden. Die Verarbeitungszeit an beiden Enden ist in diesem Beispiel nicht enthalten.

flowchart TB
    accTitle: Beispiel für die Übertragungszeit, bis das Ergebnis eines Zeichens zurückkommt
    accDescr: Ein Beispiel, das zur Erklärung für Hin- und Rückweg jeweils 50 Millisekunden annimmt. Die Verarbeitungszeit an beiden Enden ist nicht enthalten, und es stellt auch nicht die Anzahl der Pakete pro Taste dar.
    A["Lokal ein Zeichen tippen"] -->|"Hinweg: 50 ms"| B["Host empfängt die Eingabe"]
    B --> C["Bild mit der Eingabe senden"]
    C -->|"Rückweg: 50 ms"| D["Ergebnis kommt lokal an"]

Abbildung 3: Bei angenommenen 50 Millisekunden für den Hinweg und 50 Millisekunden für den Rückweg kostet allein die Übertragung 0,1 Sekunden. Das ist kein Messwert.

Auch wenn die Leitung mehr Daten transportieren kann, bleiben diese 0,1 Sekunden bestehen, solange sich die Roundtrip-Zeit nicht ändert. Abbildung 3 ist ein Konzeptdiagramm, das beim Verständnis der Verarbeitung helfen soll. Es bedeutet nicht, dass für jede Taste ein eigenständiges Paket hin und zurück geschickt wird. Auch die Pfade zum Speedtest-Server und zum RDP-Host unterscheiden sich; berücksichtigen Sie dabei VPN, Gateways, den Upload auf der Hostseite und Überlastungen unterwegs. Siehe: Wie RTT zu verstehen ist, Netzwerk- und Hostleistung.

Bildschirm erzeugen und übertragen

Mit verzögerter Bedienreaktion ist hier die Wartezeit gemeint, von einer Aktion auf Ihrem eigenen Rechner bis das Ergebnis sichtbar wird. Neben der RTT spielen auch die Verarbeitung in der Anwendung und das Erzeugen und Übertragen des Bildschirms eine Rolle. Sie ist auch von der Verzögerung allein im Übertragungsabschnitt des Bildschirms zu unterscheiden. Siehe: Messabschnitt von der Bildschirmerfassung bis zur Anzeige.

Erreicht eine Eingabe von Ihrem Rechner den Host, verarbeitet die Anwendung auf dem Host die Eingabe und aktualisiert den Bildschirm; die codierten Bildschirminformationen werden über die Leitung transportiert und auf Ihrem Rechner decodiert und angezeigt. Auch vor und nach der Übertragung gibt es Arbeit, die von verschiedenen PCs übernommen wird. Siehe: Verarbeitung von der Bildschirmerfassung bis zur Anzeige.

flowchart TB
    accTitle: Auch vor und nach der Leitung wird der Bildschirm verarbeitet
    accDescr: Der Ablauf, in dem eine lokale Eingabe den Host erreicht, die Anwendung auf dem Host sie verarbeitet, den Bildschirm erzeugt und komprimiert und die über die Leitung transportierten Bildschirminformationen lokal in eine anzeigbare Form zurückgewandelt und angezeigt werden.
    I["Lokal: Aktion eingeben"] --> J["Leitung: Eingabe transportieren"]
    J --> K["Host: Anwendung verarbeitet"]
    K --> A["Host: Bild erzeugen, komprimieren"]
    A --> B["Leitung: Bilddaten transportieren"]
    B --> C["Lokal: in Anzeigeform zurückwandeln"]
    C --> D["Lokal: auf dem Bildschirm anzeigen"]

Abbildung 4: Auf dem Host verarbeiten und komprimieren, über die Leitung transportieren, lokal für die Anzeige zurückwandeln. Jede dieser Arbeiten findet an einem anderen Ort statt.

Codierung bezeichnet in diesem Artikel die Verarbeitung, bei der der Host den Bildschirm in eine leicht übertragbare Form umwandelt und komprimiert. Unabhängig von der Übertragung über die Leitung kostet sie auf dem Host Verarbeitungszeit. Siehe: Codierungszeit auf dem Host.

Decodierung bezeichnet in diesem Artikel die Verarbeitung, bei der die empfangenen Bildschirminformationen auf Ihrem Rechner in eine anzeigbare Form zurückgewandelt werden. Sie ist von der Entschlüsselung im Sinne der Aufhebung einer Verschlüsselung zu unterscheiden. Siehe: Lokale Decodierungs- und Anzeigezeit.

Dauert die Komprimierung auf dem Host lange, wartet die Übertragung auf die Sendebereitschaft, auch wenn die Leitung frei ist. Auch wenn die Informationen angekommen sind, verzögert sich die Aktualisierung, wenn Decodierung oder Anzeige auf Ihrem Rechner nicht mithalten. „Der Firmen-PC ist leistungsstark, also ist das lokale Gerät egal“ trifft nicht unbedingt zu. Reserven auf der Leitung und Reserven bei der Verarbeitung an ihren beiden Enden sind zweierlei. Siehe: Leistungsindikatoren der Grafikverarbeitung.

flowchart TB
    accTitle: Verzögerung, wenn die Verarbeitung an beiden Enden nicht mithält
    accDescr: Dauert die Komprimierung auf dem Host lange, wartet das Senden trotz freier Leitung auf die Vorbereitung; halten lokale Decodierung oder Anzeige nicht mit, verzögert sich die Aktualisierung, obwohl die Informationen angekommen sind.
    A["Komprimierung auf dem Host dauert"] --> B["Senden wartet trotz freier Leitung"]
    B ~~~ C["Lokale Decodierung hält nicht mit"]
    C --> D["Trotz Empfang verzögert"]

Abbildung 5: Auch wenn die Leitung Reserven hat, verzögert sich die Bildschirmaktualisierung, wenn die Verarbeitung an beiden Enden nicht mithält.

Unterschied zwischen Tippen und Scrollen

Fügen Sie im Editor ein Zeichen hinzu, ändert sich nur ein kleiner Teil des Bildschirms. Scrollen Sie durch eine Seite mit vielen Fotos, ändert sich die Anzeige in einem großen Bereich in rascher Folge. RDP verringert die Datenmenge, indem es geänderte Bereiche überträgt und zum Inhalt passende Komprimierung und Zwischenspeicherung einsetzt. Es sendet nicht jedes Mal den gesamten Bildschirm unkomprimiert. Der Arbeitsaufwand hängt vom Bildschirminhalt und von der Häufigkeit der Aktualisierungen ab. Siehe: Zusammenhang zwischen Bildschirminhalt und Bandbreite.

flowchart TB
    accTitle: Bildschirmaufwand bei Tippen und Scrollen
    accDescr: Eine kleine Änderung durch ein Zeichen und fortlaufende Aktualisierungen in einem großen Bereich unterscheiden sich in der Art der Arbeit, den Bildschirm zu erzeugen und zu senden.
    A{"Änderung am Bildschirm"} -->|"Ein Zeichen hinzufügen"| B["Kleiner Bereich"]
    A -->|"Scrollen"| D["Großer Bereich, fortlaufend"]
    B --> E["Je nach Änderung komprimieren, senden"]
    D --> E

Abbildung 6: Selbst bei derselben Verbindung unterscheidet sich der Aufwand, wenn ein Zeichen hinzukommt oder wenn sich ein großer Bereich ständig bewegt.

Auch wenn ein ruhendes Dokument wenig Last erzeugt, kann der Grafikübertragung beim Scrollen der Spielraum ausgehen. Erhöhen Sie Auflösung oder Anzahl der Monitore auf der Remoteseite, wird auch der zu verarbeitende Bildschirm größer. Der Vergleich mit niedrigerer Auflösung ist ein Experiment, das zeigt, ob die Bewegung wieder flüssig wird, wenn die Arbeit für das Erzeugen und Senden des Bildschirms abnimmt. Es ist keine Berechnung, die die Datenmenge allein aus der Pixelanzahl bestimmt. Siehe: Einfluss von Auflösung, Bildschirmaktualisierung und Komprimierung.

Wartezeiten der Anwendung

Wenn nur die Suche in einer Geschäftsanwendung einige Sekunden hängt, Sie im Editor derselben Sitzung aber normal tippen können, prüfen Sie, worauf diese Anwendung wartet. Die Anwendung auf dem Host richtet womöglich ihrerseits eine Abfrage an eine andere Datenbank oder liest eine Datei aus einem freigegebenen Ordner und wartet auf deren Antwort. Das ist ein anderer Pfad als die RDP-Verbindung zwischen Ihrem Rechner und dem Host. Siehe: Kommunikation vom Host zum Back-End.

flowchart TB
    accTitle: Auch hinter RDP gibt es Kommunikationspartner
    accDescr: Zeigt den Fall, dass die Anwendung auf dem Host unabhängig von der Verbindung zwischen lokalem Gerät und Host auf die Antwort eines Geschäftsservers wartet.
    A["Lokales Gerät"] -->|"RDP"| B["Geschäftsanwendung auf dem Host"]
    B -->|"Suche, Dateianforderung"| C["DB, freigegebener Ordner"]
    C -->|"erwartete Antwort"| B

Abbildung 7: Die Geschäftsanwendung hinter RDP wartet unter Umständen ihrerseits auf die Antwort eines anderen Servers.

Hat die für Bildschirm und Eingabe zuständige Verarbeitung eine langwierige Aufgabe zu erledigen, verzögern sich die nächste Eingabe und die nächste Bildschirmaktualisierung. In WPF beispielsweise leidet die Reaktionsfähigkeit, wenn der UI-Thread lange belegt ist. Eine niedrige Gesamt-CPU-Auslastung allein schließt Wartezeiten eines bestimmten UI-Threads nicht aus. Siehe: Dispatcher und UI-Thread.

flowchart TB
    accTitle: Die für Bildschirm und Eingabe zuständige Verarbeitung staut sich
    accDescr: Hat die für Bildschirm und Eingabe zuständige Verarbeitung eine lange Aufgabe, verzögern sich die nächste Eingabe und Bildschirmaktualisierung; eine niedrige Gesamt-CPU-Auslastung allein schließt dieses Warten nicht aus.
    A["Zuständig für Bild und Eingabe"] --> B["Hat eine lange Aufgabe"]
    B --> C["Nächste Eingabe und Aktualisierung verzögert"]
    C -.- D["Niedrige Gesamt-CPU schließt es nicht aus"]

Abbildung 8: Wartezeiten des UI-Threads lassen sich nicht allein über die Gesamt-CPU-Auslastung ausschließen.

Erster Vergleich nach Symptom

Die transportierbare Menge, die Wartezeit auf eine Antwort und die Zeit zum Erzeugen und Anzeigen des Bildschirms sind drei verschiedene Dinge. Wenn Sie diese Unterscheidung beibehalten, schieben Sie „RDP ist träge“ nicht auf eine einzige Ursache, sondern können bei der Aktion ansetzen, die gerade langsam ist.

flowchart TB
    accTitle: Erst die drei trennen, dann untersuchen
    accDescr: Zeigt, dass „RDP ist träge“ nicht auf eine einzige Ursache geschoben wird, sondern transportierbare Menge, Wartezeit auf die Antwort und Zeit zum Erzeugen und Anzeigen des Bildschirms getrennt werden und bei der gerade langsamen Aktion angesetzt wird.
    A["„RDP ist träge“"] --> S
    subgraph S["Getrennt betrachten"]
    direction TB
    B["Transportierbare Menge"] ~~~ C["Wartezeit auf Antwort"]
    C ~~~ D["Bild erzeugen und anzeigen"]
    end
    S --> E["Bei der langsamen Aktion ansetzen"]

Abbildung 9: Wenn Sie transportierbare Menge, Wartezeit auf die Antwort und Zeit zum Erzeugen und Anzeigen des Bildschirms trennen, können Sie bei der Aktion ansetzen, die gerade langsam ist.

Bei der Eingrenzung geht es darum, den Bereich zu beschränken, in dem Sie der Langsamkeit nachgehen. Es geht nicht darum, Einstellungen pauschal zu ändern und dadurch zufällig schneller zu werden. Nutzen Sie Unterschiede wie „der Editor reagiert, nur die Suche hängt“ oder „Tippen ist normal, nur der Bildlauf ist träge“, dann können Sie einen Einstiegspunkt für die Untersuchung wählen, noch bevor Sie Netzwerkeinstellungen ändern.

Die folgende Tabelle ist ein Ausgangspunkt für die Untersuchung. Sie dient nicht dazu, die Ursache zu bestimmen. Vergleichen Sie zuerst Aktionen in derselben Sitzung und ändern Sie danach bei Bedarf Gerät, Pfad oder Anzeigebedingungen.

Verzögerte Zeichen in mehreren Anwendungen

Erscheinen Zeichen in mehreren Anwendungen derselben Sitzung einzeln verzögert, vergleichen Sie dieselbe Aktion auch von einem anderen Gerät oder über einen anderen erlaubten Pfad. Gleichen Sie Roundtrip-Zeit, Eingabewartezeit auf dem Host und Gesamtlast des Hosts miteinander ab; die Ursache wird nicht anhand eines einzelnen Werts festgelegt.

Nur der Bildlauf ruckelt

Auch wenn das Tippen normal ist, folgen beim Scrollen durch eine Seite mit vielen Fotos fortlaufend Bildschirmaktualisierungen in einem großen Bereich. Ändern Sie Auflösung oder Anzahl der Monitore auf der Remoteseite jeweils einzeln und vergleichen Sie mit derselben Seite. Tritt eine Besserung ein, sind die Komprimierung auf dem Host, die Grafikübertragung und die lokale Decodierung die nächsten Untersuchungsgegenstände. Allein anhand der Auflösung lässt sich nicht sagen, welcher dieser drei die Ursache ist. Siehe: Last durch Bildschirminhalt und Auflösung.

Nur eine Anwendung hängt

Hängt nur die Geschäftsanwendung, in der Sie die Suche ausgelöst haben, prüfen Sie im Vergleich, ob der Editor o. Ä. in derselben Sitzung reagiert. Funktionieren andere Anwendungen, untersuchen Sie zuerst die Verarbeitung der betroffenen Anwendung, den Datenträger sowie Anforderungen an Datenbank und freigegebene Ordner. Dass Sie über RDP arbeiten, bedeutet nicht, dass die RDP-Kommunikation die Ursache des Wartens ist. Siehe: Leistungsfaktoren von Anwendung und Back-End.

Für alle langsam, wenn viele Benutzer aktiv sind

Wird es für mehrere Benutzer zur selben Zeit langsam, erkundigen Sie sich beim Administrator nach dem Zustand der anderen Sitzungen. Gleichen Sie die Last von CPU, Arbeitsspeicher und Speichersystem des gemeinsam genutzten Hosts sowie der gemeinsam genutzten Leitung mit dem Zeitpunkt der Symptome ab. Greifen Sie nicht ohne Erlaubnis auf Aufzeichnungen oder Prozesse anderer Benutzer zu und halten Sie keine Jobs an. Siehe: Ressourcen gemeinsam genutzter Hosts und Benutzeranzahl.

Langsam beim Kopieren oder Drucken

Fällt das Problem zeitlich mit dem Beginn eines eigenen Kopier- oder Druckvorgangs zusammen, halten Sie zum Vergleich nur Übertragungen kurz an, deren Anhalten erlaubt ist. Notieren Sie, ob es sich nach dem Anhalten bessert und ob es beim Fortsetzen wieder langsam wird, und untersuchen Sie die Konkurrenz mit Übertragungen außer dem Bildschirm und mit der Geräteumleitung. Vergleiche, bei denen für die Arbeit benötigte Geräte pauschal deaktiviert werden, werden nicht durchgeführt. Siehe: Auswirkungen der Geräteumleitung.

Bedingungen einzeln vergleichen

Sie müssen nicht alle Einstellungen der Reihe nach ändern. Legen Sie zuerst eine Vergleichsbasis fest und wählen Sie nur die Prüfungen aus, die zum Symptom passen. Speichern Sie Ihre Arbeit vor Einstellungsänderungen und erneuten Verbindungen, und notieren Sie die ursprünglichen Werte und wie sie sich wiederherstellen lassen. Fehlen die nötigen Berechtigungen oder Funktionen, erzwingen Sie keine Aktivierung, sondern übergeben Sie an den Administrator.

Bedienung direkt am Host und Bedienung über RDP finden nicht unbedingt unter denselben Bedingungen statt. Dass es am physischen Bildschirm des Hosts schnell ist, ist ein nützlicher Hinweis, doch Sitzung und Rendering-Bedingungen können sich unterscheiden. Gleichen Sie Benutzer, Daten und Anwendungszustand an, und schränken Sie die Ursache nicht allein deshalb auf die Leitung ein, weil es „am physischen Bildschirm schnell ist“.

Dieselbe Aktion vergleichen

Bereiten Sie denselben Benutzer, dieselben Daten und dieselbe Aktion vor. Prüfen Sie auf einem gemeinsam genutzten Host Ihre eigene Sitzung; Anwendungen und Prozesse anderer Benutzer werden nicht beendet. Auch die Nutzung eines anderen Geräts oder Pfads beschränkt sich auf den Umfang, den der Administrator erlaubt hat.

1. Reproduzieren Sie die langsame Aktion mit den ursprünglichen Einstellungen und notieren Sie Uhrzeit und Symptom.

   Tippen Sie im Editor derselben Remotesitzung wie die betroffene Anwendung ungefähr gleich viele Zeichen. Unterscheiden Sie, ob nur eine Anwendung oder die gesamte Sitzung betroffen ist.

2. Prüfen Sie im selben Zeitraum die Last auf dem Host und auf Ihrem eigenen Rechner.

   Sehen Sie sich im Task-Manager auf dem Host CPU, Arbeitsspeicher und Datenträger der betroffenen Anwendung an und auf Ihrem Rechner die Last des RDP-Clients. Prüfen Sie nicht nur den Gesamtwert der CPU, sondern den betroffenen Prozess. Siehe: Was bei der Last zu untersuchen ist.

3. Ändern Sie nur eine Bedingung – anderes Gerät, anderer erlaubter Pfad oder Anzeigebedingungen – und wiederholen Sie dieselbe Aktion.

   Ändert sich bei einem Vergleich gleichzeitig auch der Zustand von Host oder Anwendung, notieren Sie auch diesen Unterschied. Ein Ergebnis, bei dem sich mehrere Bedingungen geändert haben, wird nicht als Wirkung einer einzelnen Bedingung gewertet.

4. Stellen Sie die ursprünglichen Bedingungen wieder her und prüfen Sie dieselbe Aktion erneut.

   Bleibt es auch nach dem Zurücksetzen schnell, kommen auch vorübergehende Laständerungen oder Ähnliches in Betracht. Gehen Sie nicht vorschnell davon aus, dass die Änderung gewirkt hat, sondern notieren Sie die Bedingungen, unter denen das Symptom auftritt.

Damit liegen die Ergebnisse für den Ausgangszustand, den geänderten und den zurückgesetzten Zustand vor, und Sie können vergleichen, welche Bedingung mit welchem Symptom zusammenhängt. Eine Bedingung, die Besserung brachte, ist ein Hinweis für die Untersuchung und für sich allein kein Beweis der Grundursache.

flowchart TB
    accTitle: Die gleichzeitig geänderten Bedingungen begrenzen
    accDescr: Der Ablauf, im Ausgangszustand eine reproduzierbare Aktion festzulegen, nur eine Bedingung zu ändern und zu vergleichen und auch das Ergebnis nach dem Zurücksetzen zu prüfen.
    A["Dieselbe Aktion, ursprüngliche Einstellung"] --> B["Nur eine Bedingung ändern"]
    B --> C["Dieselbe Aktion wiederholen"]
    C --> D["Zurücksetzen und erneut prüfen"]
    D --> E["Bedingung mit Besserung notieren"]

Abbildung 10: Wiederholen Sie dieselbe Aktion im Ausgangszustand, nach der Änderung und nach dem Zurücksetzen, und notieren Sie die Bedingung, bei der sich etwas geändert hat.

Auflösung der Remoteseite vergleichen

Diesen Vergleich führen Sie durch, wenn Bildschirmaktualisierungen wie beim Scrollen träge sind. Notieren Sie Auflösung und Anzahl der Monitore vor der Änderung, speichern Sie Ihre Arbeit und verbinden Sie sich dann neu. Einstellungen, die die für die Arbeit nötige Bildschirmfläche oder die Lesbarkeit von Text beeinträchtigen, werden nicht unverändert dauerhaft verwendet.

1. Ändern Sie entweder nur die Anzahl der Monitore oder nur die Auflösung.

   In mstsc können Sie über die Einstellungen auf der Registerkarte „Anzeige“ vor dem Verbinden oder durch Angabe von Breite und Höhe vergleichen. Siehe: Bildschirmangaben für mstsc.

2. Vergewissern Sie sich, dass sich die tatsächliche Größe des Desktops auf dem Host geändert hat, und scrollen Sie durch dieselbe Seite.

   Wenn Sie nur das Fenster auf Ihrem Rechner verkleinern, wird unter Umständen ein großer Desktop verkleinert dargestellt. Unterscheiden Sie zwischen dynamischer Auflösung und smart sizing, und prüfen Sie, welche Voraussetzungen der verwendete Client unterstützt. Siehe: Desktopauflösung und Anzeigeskalierung.

3. Stellen Sie die ursprüngliche Einstellung wieder her, wiederholen Sie dieselbe Aktion und vergleichen Sie die Last an beiden Enden und die Bewegung auf dem Bildschirm.

   Haben Sie gleichzeitig auf eine niedrige Auflösung und einen einzigen Monitor umgestellt, bleibt es bei einem groben Vergleich. Tritt eine Besserung ein, setzen Sie die beiden einzeln zurück, um ihre Auswirkungen zu trennen.

Tritt eine Besserung ein, liegt ein Hinweis im Bereich der Bildschirmverarbeitung und Grafikübertragung. 3840×2160 hat viermal so viele Pixel wie 1920×1080, doch die Datenmenge wird nicht immer viermal so groß. Sie hängt von den geänderten Bereichen und der Komprimierung ab, und eine Änderung der Auflösung wirkt sich auch auf die Verarbeitung an beiden Enden aus. Siehe: Zusammenhang zwischen Pixelanzahl und Datenmenge, Prüfung der Grafikverarbeitung.

flowchart TB
    accTitle: Was der Vergleich mit niedrigerer Auflösung zeigt
    accDescr: Eine niedrigere Auflösung auf der Remoteseite kann sowohl die Last der Bildschirmverarbeitung als auch die der Übertragung ändern; eine Besserung allein grenzt die Ursache daher nicht auf die Leitung ein.
    A["Auflösung der Remoteseite senken"] --> S
    subgraph S["Was sich ändert"]
    direction TB
    B["Bildverarbeitung auf dem Host"] ~~~ C["Gesendete Datenmenge"]
    C ~~~ D["Lokale Anzeigeverarbeitung"]
    end

Abbildung 11: Eine Änderung der Auflösung ist ein Vergleich, der nicht nur die Leitung, sondern auch die Bildschirmverarbeitung auf dem Host und auf Ihrem Rechner betrifft.

Kopieren und Drucken mit dem Symptom abgleichen

Angehalten werden nur Vorgänge, deren Anhalten erlaubt ist, etwa eine selbst gestartete Übertragung. Sicherungs- und Sicherheitsprozesse des Unternehmens sowie Jobs anderer Benutzer werden nicht angehalten. Die Umleitung von Audio- und Eingabegeräten, die für die Arbeit nötig sind, wird nicht pauschal deaktiviert.

1. Notieren Sie vor dem Start und während des Kopierens, der Cloudsynchronisierung oder des Druckens dieselbe Aktion und die Last.

   Über RDP fließen neben dem Bildschirm auch Informationen für Laufwerke, Drucker und Ähnliches. Eine Umleitung, mit der Geräte Ihres Rechners auf dem Host genutzt werden, kann während der Nutzung die Netzwerk- und Verarbeitungslast erhöhen. Siehe: Auswirkungen der Geräteumleitung.

2. Halten Sie die betreffende Übertragung im erlaubten Rahmen kurz an und prüfen Sie dieselbe Aktion erneut.

   Wenn Sie durch Fortsetzen vergleichen können, notieren Sie auch das Symptom nach dem Fortsetzen. Auch wenn Sie das Abschalten nicht benötigter Geräteumleitungen ausprobieren, ändern Sie jeweils nur eine und sorgen Sie dafür, dass Sie zur ursprünglichen Einstellung zurückkehren können.

So können Sie beurteilen, ob Übertragungsbeginn und Problem sowie Anhalten und Erholung zusammenfallen. Zeigt sich ein Zusammenhang, gleichen Sie Übertragungen außer dem Bildschirm und die Last gemeinsam genutzter Ressourcen mit den Aufzeichnungen des Administrators ab.

flowchart TB
    accTitle: Vor und nach dem Problem auf derselben Zeitachse betrachten
    accDescr: Vor, während und nach dem Anhalten einer Übertragung werden dieselbe Aktion und die Last notiert und der Zusammenhang zwischen Problem und Vorgang verglichen.
    A["Aktion und Last vor der Übertragung"] --> B["Aktion und Last während der Übertragung"]
    B --> C["Aktion und Last nach dem Anhalten"]
    C --> D["Passen Problem und Erholung zusammen?"]

Abbildung 12: Beobachten Sie, wie sich Langsamkeit und Last derselben Aktion vor, während und nach dem Anhalten der Übertragung verändern.

Messen, wo gewartet wird

Von Ihrem Rechner aus untersuchen Sie den Netzwerk-Roundtrip und die TCP-Verbindung, auf dem Host die Wartezeit in der Eingabewarteschlange und die Bildschirmaktualisierung. Da jeder Wert nur einen begrenzten Abschnitt misst, lesen Sie die Ergebnisse im Abgleich mit der Tabelle unter „Aussagebereich der Messergebnisse“.

ICMP und TCP-Verbindung prüfen

Ausgeführt wird dies auf Ihrem lokalen Windows-Gerät. Betrachtet werden nur Konfigurationen, bei denen Sie sich im Firmen-LAN oder über ein erlaubtes VPN direkt mit einem RDP-Host verbinden, der den Standardport TCP 3389 verwendet. Bei Konfigurationen über RD Gateway oder Azure Virtual Desktop oder mit eigenem Port legen Sie das Prüfziel bitte gemeinsam mit dem Administrator fest. Ports werden nicht freigegeben, und die Firewall wird nicht geändert.

1. Geben Sie den erlaubten Host ein und notieren Sie die Ergebnisse von ICMP-Antwort und TCP-Verbindung.

   $target = Read-Host 'Name oder IP-Adresse des RDP-Hosts, dessen Untersuchung erlaubt ist'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Bitte geben Sie den Host an.'
   }
       
   # ICMP-Antwortzeiten mehrmals ansehen. Ein Fehlschlag allein bedeutet nicht, dass RDP nicht erreichbar ist.
   ping.exe -n 20 $target
       
   # Prüfung nur für Konfigurationen mit direkter Verbindung zum Standardport TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Gleichen Sie die Ergebnisse aus langsamen und normalen Zeiträumen mit dem Zeitpunkt der Symptome und dem tatsächlichen Verbindungspfad ab.

   Ein 20-maliges ping ist eine kurze Beobachtung. Notieren Sie Schwankungen der Werte und ausbleibende Antworten, doch ICMP kann auch blockiert sein. Schließen Sie zeitweilige Aussetzer nicht allein anhand des Durchschnittswerts aus, sondern nutzen Sie die Verbindungsinformationen und die Netzwerkaufzeichnungen des Administrators. Siehe: Was ping misst.

TcpTestSucceeded: True bedeutet, dass die TCP-Verbindung zum angegebenen Port erfolgreich war. Bandbreite, UDP, die Bedienung nach der Authentifizierung und die Flüssigkeit der Bildschirmanzeige werden damit nicht gemessen. Test-NetConnection hat keinen -UDP-Schalter zur Prüfung von UDP. Siehe: Syntax und Ergebnisse von Test-NetConnection.

Beurteilen Sie die Ergebnisse unter Berücksichtigung der Unterschiede in Pfad und Dienst. Bei RD Gateway und Ähnlichem stimmt der Pfad von ICMP oder einer direkten TCP-Verbindung zum Host womöglich nicht mit dem tatsächlichen RDP-Pfad überein. In Azure Virtual Desktop stehen RTT und Schätzwerte der Bandbreite pro Verbindung zur Verfügung, doch diese Diagnosefunktion ist für diesen Dienst bestimmt. Kurze Aussetzer werden nicht allein anhand von Durchschnittswerten ausgeschlossen. Siehe: Protokolle zur Verbindungsqualität in Azure Virtual Desktop.

flowchart TB
    accTitle: Geprüfter Pfad und tatsächlicher RDP-Pfad
    accDescr: In Konfigurationen mit RD Gateway oder Ähnlichem stimmt der Pfad von ICMP oder einer direkten TCP-Verbindung vom lokalen Gerät zum Host womöglich nicht mit dem tatsächlichen RDP-Pfad überein.
    A["Lokales Gerät"] -->|"ICMP, direktes TCP"| C["RDP-Host"]
    A -->|"Tatsächliches RDP"| B["RD Gateway o. Ä."]
    B --> C

Abbildung 13: ICMP oder eine direkte TCP-Verbindung zum Host und das tatsächliche RDP nehmen womöglich nicht denselben Pfad.

Wartezeit in der Eingabewarteschlange messen

User Input Delay misst die Wartezeit von dem Moment, in dem eine Eingabe auf dem Host in die Warteschlange gelangt, bis der Prozess sie abholt. Es ist nicht die Gesamtzeit vom Tastendruck bis zum sichtbaren Zeichen. Siehe: Definition von User Input Delay.

Die Untersuchung erfolgt innerhalb der Remotesitzung auf dem Host. Laut Microsoft werden Windows 10 Version 1809 oder höher und Windows Server 2019 oder höher unterstützt. Für diese Systeme ist kein Registrierungseintrag zur Aktivierung nötig. Prüfen Sie Anzeigenamen, Berechtigungen und ob der Leistungsindikator vorhanden ist; ist er nicht verfügbar, notieren Sie diese Tatsache und wenden Sie sich an den Administrator. Siehe: Voraussetzungen und Einstellungen.

1. Notieren Sie in PowerShell in derselben Sitzung die Uhrzeit und die Sitzungs-ID.

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

   Um Sitzungen anderer Benutzer abzufragen, sind unter Umständen zusätzliche Berechtigungen erforderlich. Der Standardname der Instanz für den betroffenen Prozess lautet SessionID:ProcessID <Process Image>. Achten Sie darauf, nicht allein anhand der Sitzungs-ID Werte anderer Benutzer oder gleichnamiger Prozesse zu vermischen. Siehe: Berechtigungen für query session, Identifizierung von Instanzen.

2. Fügen Sie in perfmon.exe den verfügbaren Leistungsindikator User Input Delay per Process oder User Input Delay per Session hinzu.

   Wählen Sie den betroffenen Prozess bzw. die betroffene Sitzung und beobachten Sie zunächst im Standardintervall von 1 Sekunde. Unterscheiden Sie zwischen der Sammelinstanz, die mehrere Sitzungen zusammenfasst, und den Werten einzelner Sitzungen.

3. Reproduzieren Sie die Aktion mit langsamer Eingabe und vergleichen Sie die Wartezeit in der Warteschlange mit dem Zeitpunkt des Symptoms.

   Bei einem einzelnen Messobjekt wird die maximale Wartezeit innerhalb des Messintervalls betrachtet. Auch wenn der Wert niedrig ist, bleiben die Verarbeitung, nachdem die Anwendung die Eingabe abgeholt hat, und die Verzögerung, bis das Ergebnis auf Ihren Rechner zurückkommt, bestehen.

So können Sie untersuchen, ob in der Eingabewarteschlange auf dem Host gewartet wird. Es ist ein anderer Messwert als die empfundene Zeit, die den Netzwerk-Roundtrip und die Anzeige auf Ihrem Rechner einschließt. Siehe: Bedeutung von Maximalwert und Messintervall.

flowchart TB
    accTitle: Der von User Input Delay gemessene Abschnitt
    accDescr: Gemessen wird der Abschnitt von der Eingabewarteschlange auf dem Host bis zum Abholen durch die Anwendung; die Übertragung davor und danach sowie die Bildschirmanzeige sind nicht enthalten.
    A["Eingabe kommt vom lokalen Gerät"] --> B["Eingabewarteschlange des Hosts"]
    B -->|"Hier wird gemessen"| C["Anwendung holt Eingabe ab"]
    C --> D["Verarbeitung und Bildübertragung"]
    D --> E["Lokal angezeigt"]

Abbildung 14: Gemessen wird die Wartezeit in der Eingabewarteschlange auf dem Host. Das ist nicht die Gesamtzeit, bis das Ergebnis auf Ihrem Rechner sichtbar ist.

Bildschirmaktualisierung und Gründe für ausgelassene Frames untersuchen

Bereiten Sie eine Aktion mit fortlaufenden Bildschirmaktualisierungen vor, etwa Scrollen. Ob die Leistungsindikatoren RemoteFX Graphics verfügbar sind und wo sie gemessen werden, müssen Sie je nach Betriebssystem, Hostkonfiguration und Berechtigungen prüfen. Hier werden nur verfügbare Leistungsindikatoren gelesen. Es ist keine Anleitung zum Installieren oder Aktivieren der alten RemoteFX-Funktion. Siehe: Geltungsbedingungen der Graphics-Leistungsindikatoren.

1. Ermitteln Sie mit query session oder qwinsta den Namen der betroffenen Sitzung und wählen Sie die entsprechende Instanz des Leistungsindikators.

2. Vergleichen Sie während einer Aktion mit Bildschirmaktualisierungen Input Frames/Second und Output Frames/Second.

   Ist die Ausgabe geringer als die Eingabe, werden unterwegs Frames ausgelassen. Prüfen Sie die Werte von Frames Skipped/Second, aufgeschlüsselt nach Ressourcenmangel auf dem Host, im Netzwerk und auf dem Client.

3. Gleichen Sie die Gründe für ausgelassene Frames mit der Last an beiden Enden und im Netzwerk ab, und prüfen Sie auch Average Encoding Time.

   Ist die Codierungszeit lang, untersuchen Sie die Komprimierung auf dem Host. Ist die Anzahl der Frames bereits auf der Eingangsseite gering, aktualisiert die Anwendung den Bildschirm möglicherweise auch einfach nicht häufig. Eine geringe Frame-Anzahl bei einem ruhenden Bildschirm ist für sich genommen keine Anomalie.

Anhand von Ein- und Ausgabe während der Bildschirmaktualisierung, den Gründen für ausgelassene Frames und der Codierungszeit können Sie den Untersuchungsbereich eingrenzen. Die Einteilung der Leistungsindikatoren ist ein Hinweis; beurteilt wird zusammen mit der tatsächlichen Last und der Verbindungskonfiguration. Siehe: Frame-Anzahl und Codierungszeit richtig lesen.

flowchart TB
    accTitle: Den Untersuchungsbereich über ausgelassene Frames eingrenzen
    accDescr: Während einer Aktion mit Bildschirmaktualisierungen werden die Ein- und Ausgabe-Frames verglichen und anhand der Leistungsindikatoren zu den Gründen für ausgelassene Frames mit der Last von Verarbeitung, Übertragung und Anzeige abgeglichen.
    A["Ein-/Ausgabe beim Scrollen vergleichen"] --> B["Weniger Ausgabe: Auslassen prüfen"]
    B --> C["Indikatoren nach Grund ansehen"]
    C --> D["Mit Last von Host, Netz, lokal abgleichen"]

Abbildung 15: Vergleichen Sie Ein- und Ausgabe beim Scrollen und gleichen Sie die Gründe für ausgelassene Frames mit der Last auf dem Host, auf der Leitung und auf Ihrem Rechner ab.

Konzeptdiagramme der Grafikübertragung und ältere Dokumentation werden nicht auf alle Konfigurationen verallgemeinert. Es gibt auch Konfigurationen, in denen Video und Audio über einen eigenen Mechanismus übertragen werden. Da die Dokumentation zu den Graphics-Leistungsindikatoren auch Beschreibungen älterer Konfigurationen enthält, werden die dort genannten Zahlen nicht als gemeinsame Spezifikation im Sinne von „jedes RDP hat maximal 30 fps“ gelesen. Prüfen Sie, wofür Funktionen und Zahlen gelten, bevor Sie sie verwenden. Siehe: Grafikübertragung und Workloads, Dokumentation zu den Graphics-Leistungsindikatoren.

Aussagebereich der Messergebnisse

Ein niedriger Wert wird nicht mit einer angenehmen Bedienung gleichgesetzt. Den Geltungsbereich jedes Messwerts können Sie in der in den Schritten genannten Microsoft-Dokumentation nachprüfen.

Netzwerk- und GPU-Einstellungen

UDP- und GPU-Einstellungen wählen Sie passend zu dem, was Vergleiche und Messungen ergeben haben. Steht das Netzwerk unter Verdacht, prüfen Sie zuerst Transportart und Pfad; steht die Bildschirmverarbeitung unter Verdacht, prüfen Sie zuerst, in welcher Phase die GPU genutzt wird.

TCP/UDP und Verbindungspfad prüfen

Wenn Vergleiche und Messungen auf das Netzwerk hindeuten, prüfen Sie gemeinsam mit dem Administrator den verwendeten Client, den Pfad und die angewendeten Richtlinien. Auch wenn Einstellungsänderungen nötig sind, beschränken sie sich auf den genehmigten Umfang; notieren Sie die Werte vor der Änderung und das Wiederherstellungsverfahren. Firewall oder Authentifizierung werden nicht deaktiviert, und der RDP-Port wird nicht direkt im Internet veröffentlicht.

1. Prüfen Sie anhand der Verbindungsinformationen, der Diagnoseprotokolle des Produkts und der Netzwerkaufzeichnungen des Administrators, ob tatsächlich TCP oder UDP verwendet wird und über welchen Pfad.

   RDP verwendet je nach Konfiguration und Netzwerkbedingungen TCP oder UDP. Unter „Select RDP transport protocols“ können Sie zwischen einer Einstellung, die UDP oder TCP verwendet, und einer Einstellung nur mit TCP wählen. Da es auch ein Verhalten gibt, bei dem TCP verwendet wird, wenn keine UDP-Verbindung zustande kommt, verrät eine erfolgreiche Verbindung allein nicht die Transportart. Siehe: Auswahl des RDP-Transports und Fallback.

2. Gleichen Sie Pfad und Transportart mit dem Zeitpunkt der Symptome ab und vergleichen Sie nur die nötigen Einstellungen, jeweils eine nach der anderen.

   Ändern Sie nicht pauschal nach dem Motto „ohne UDP wird es schneller“. Vergleichen Sie bei gleichen VPN- und Gateway-Bedingungen, gleicher Aktion und gleichen Anzeigebedingungen, und machen Sie unnötige Änderungen rückgängig.

Wenn Sie Transportart und Pfad kennen, können Sie den Zusammenhang zwischen Änderung und Symptom festhalten. Eine Umstellung auf ausschließlich TCP führt nicht immer zu höherer Geschwindigkeit.

flowchart TB
    accTitle: Erst die Transportart prüfen, dann Netzwerkeinstellungen vergleichen
    accDescr: Eine gewöhnliche Direktverbindung wird von Verbindungen über Gateway oder Dienst unterschieden; erst nach Prüfung des tatsächlichen Pfads und der Transportart werden erlaubte Vergleiche durchgeführt.
    A["Verwendeter Client und Verbindungskonfiguration"] --> B["Tatsächlichen Pfad, TCP oder UDP prüfen"]
    B --> C["Mit Zeitpunkt der Symptome abgleichen"]
    C --> D["Nur nötige Einstellungen einzeln vergleichen"]

Abbildung 16: Prüfen Sie die verwendete Transportart und den Pfad, gleichen Sie sie mit dem Symptom ab und vergleichen Sie erst dann nur die nötigen Einstellungen.

RDP Shortpath ist ein Mechanismus von Azure Virtual Desktop. Es baut einen UDP-Pfad dieses Dienstes auf und verwendet je nach Konfiguration einen direkten Pfad oder ein Relay. Kann der Pfad nicht aufgebaut werden, kehrt die Verbindung zu einer TCP-basierten Verbindung zurück. Es lässt sich nicht in dieselbe Einstellungstabelle aufnehmen wie eine direkte Verbindung mit mstsc zu einem Firmen-PC. Siehe: Pfade und Fallback von RDP Shortpath.

flowchart TB
    accTitle: Pfade und Fallback von RDP Shortpath
    accDescr: RDP Shortpath in Azure Virtual Desktop versucht, einen UDP-Pfad aufzubauen; gelingt das, wird je nach Konfiguration ein direkter Pfad oder ein Relay verwendet, andernfalls kehrt die Verbindung zu einer TCP-basierten Verbindung zurück.
    A["RDP Shortpath"] --> B{"UDP-Pfad"}
    B -->|"aufgebaut"| C["Direkt oder Relay"]
    B -->|"nicht aufgebaut"| D["Zurück zu TCP-basiert"]

Abbildung 17: Kann RDP Shortpath keinen UDP-Pfad aufbauen, kehrt es zu einer TCP-basierten Verbindung zurück.

GPU-Nutzung der Bildschirmverarbeitung prüfen

Diese Prüfung ist angezeigt, wenn Vergleiche und Messungen auf die Bildschirmverarbeitung hindeuten. Prüfen Sie die Messergebnisse der Bildschirmverarbeitung sowie unterstütztes Betriebssystem, Treiber, Richtlinien und Client. Allein weil eine GPU eingebaut ist, werden keine Einstellungen geändert. Holen Sie zuerst die Genehmigung des Administrators ein und bereiten Sie die Wiederherstellung vor.

1. Trennen Sie das Rendern der Anwendung auf dem Host, die RDP-Codierung und die lokale Decodierung, und wählen Sie die verdächtige Phase aus.

   Auch wenn eine GPU vorhanden ist, nutzen nicht unbedingt alle Phasen die GPU. Auch in Microsofts Konfigurationsdokumentation für Azure Virtual Desktop werden das Rendern der Remotesitzung und die Hardwarecodierung der Frames getrennt eingerichtet und überprüft. Siehe: GPU-Konfiguration und -Überprüfung für Rendern und Codierung.

2. Prüfen Sie nach dem Verfahren des betreffenden Produkts die tatsächliche Nutzung und messen Sie dieselbe Aktion vor und nach der nötigen Änderung.

   Ist die Komprimierungszeit lang, untersuchen Sie die GPU-Nutzung für die Codierung. Bei einer Anwendung, die in der Eingabewarteschlange wartet, setzt eine Änderung der Codierungseinstellungen an der falschen Stelle an. Für die Lesbarkeit von Text und für flüssiges Video werden Bildqualität, Datenmenge und Verarbeitungslast auch unterschiedlich gewichtet. Siehe: Unterschiede je nach Workload.

So können Sie über das bloße Vorhandensein einer GPU hinaus festhalten, ob die GPU in der problematischen Phase genutzt wird und wie sich Last und Reaktion bei derselben Aktion verändert haben. Änderungen ohne Besserung machen Sie nach Rücksprache mit dem Administrator rückgängig.

flowchart TB
    accTitle: GPU-Nutzung Phase für Phase prüfen
    accDescr: Das Rendern der Anwendung auf dem Host, die RDP-Codierung und die lokale Decodierung werden getrennt; da auch mit GPU nicht unbedingt alle Phasen die GPU nutzen, wird die Nutzung in der verdächtigen Phase geprüft.
    A["Rendern der Anwendung auf dem Host"] --> B["RDP-Codierung"]
    B --> C["Lokale Decodierung"]
    C -.- D["GPU-Nutzung je Phase prüfen"]

Abbildung 18: Auch mit GPU nutzen nicht unbedingt Rendern, Codierung und Decodierung alle die GPU.

Erneute Prüfung und Übergabe

Eine Besserung bestätigen Sie daran, dass dieselbe Aktion nach der Änderung problemlos möglich ist und zudem die nötige Bildqualität, die Geräte und die geschäftlichen Funktionen erhalten bleiben. Gleichen Sie auch das Ergebnis nach dem Zurücksetzen auf die ursprünglichen Bedingungen ab. Handelt es sich nur um eine kurzzeitige Erholung, wird die Ursache nicht festgelegt; halten Sie die Ergebnisse einschließlich Stoßzeiten und gleichzeitig laufender Vorgänge fest.

flowchart TB
    accTitle: Reihenfolge, um eine Besserung zu bestätigen
    accDescr: Zeigt, dass nach der Änderung geprüft wird, ob dieselbe Aktion problemlos möglich ist und zudem die nötige Bildqualität, Geräte und geschäftlichen Funktionen erhalten bleiben, dass mit dem Ergebnis nach dem Zurücksetzen abgeglichen wird und dass eine kurzzeitige Erholung allein die Ursache nicht festlegt.
    A["Nach Änderung dieselbe Aktion testen"] --> B["Bildqualität, Geräte, Funktionen prüfen"]
    B --> C["Mit zurückgesetztem Zustand abgleichen"]
    C -.- D["Kurze Erholung legt nichts fest"]

Abbildung 19: Gleichen Sie neben dem Ergebnis derselben Aktion auch die nötigen Funktionen und das Ergebnis nach dem Zurücksetzen ab.

Übergabe bei ungelöstem Problem

Auch wenn sich nichts bessert, das Problem nicht reproduzierbar ist oder Leistungsindikatoren nicht verfügbar sind, ist das ein nützliches Ergebnis. Trennen Sie die durchgeführten Vergleiche von den Prüfungen, die nicht möglich waren, und übergeben Sie an Administratoren und Entwickler mit der folgenden Notiz. Entfernen Sie aus geteilten Protokollen Geschäftsinformationen, die für die Untersuchung nicht nötig sind, etwa Benutzernamen und Hosts.

Zeitpunkt des Symptoms und Zeitzone:
Betriebssystem des Hosts, verwendeter Client und Version:
Direktverbindung / VPN / RD Gateway / Azure Virtual Desktop o. Ä.:
Langsame Aktion und Anwendung, Reaktion anderer Anwendungen in derselben Sitzung:
Auflösung und Anzahl der Monitore auf der Remoteseite:
Gleichzeitig laufendes Kopieren, Drucken o. Ä.:
Einzige geänderte Bedingung und Ergebnis nach dem Zurücksetzen:
Auf Host und lokalem Gerät beobachtete Last oder Leistungsindikatoren:

Ergänzen Sie außerdem, ob sich das tatsächlich verwendete TCP oder UDP bestätigen ließ, welche Punkte sich etwa mangels Berechtigungen nicht prüfen ließen und welche Einstellungen geschäftlich vertretbar sind. Wenn Sie statt „die Leitung ist langsam“ mitteilen „im Editor kann ich normal tippen, aber beim Scrollen durch Fotos hängt es“, kann die nächste zuständige Person unter denselben Bedingungen untersuchen.

Benutzer halten die reproduzierende Aktion und die Vergleichsergebnisse fest, Administratoren gleichen die Aufzeichnungen zu Verbindungspfad, gemeinsam genutztem Host und Sitzungen ab. Allein die Tatsache, dass unter RDP gewartet wird, bedeutet nicht, dass auch die Verarbeitung, die das Warten verursacht, RDP ist. Siehe: Aufgabenteilung zwischen Host und Back-End.

Anwendungsentwickler protokollieren den Empfang von Eingabeereignissen, Beginn und Ende von Datenbank- und Dateiverarbeitung sowie die Aktualisierung der UI getrennt. Sie prüfen auch einen Entwurf, bei dem schwere Arbeit nicht auf dem UI-Thread verbleibt. Ein Protokoll über den Abschluss der Verarbeitung auf dem Host dokumentiert allerdings nicht den Abschluss der Anzeige auf dem lokalen Rechner. Siehe: Auslagern von Verarbeitung, um die UI reaktionsfähig zu halten.

Verwandte Artikel

• Wie man die Windows-Sitzungsisolierung versteht
• Einen Windows-Datenträger bei 100 % sicher eingrenzen
• Warum dauert „Noch 1 Sekunde“ so lange?

Quellen

Es handelt sich um Primärquellen von Microsoft Learn. Die referenzierten Inhalte wurden am 17. September 2026 überprüft. Lesen Sie sie mit Blick auf die Geltungsbedingungen des jeweiligen Produkts und darauf, dass es sich nicht um in diesem Artikel durchgeführte Messungen handelt.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Unterscheidung zwischen RTT und der Verzögerung von der Bildschirmerfassung auf dem Host bis zur Anzeige auf dem lokalen Rechner. Die Diagnosefunktion selbst ist für Azure Virtual Desktop bestimmt.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Zusammenhang zwischen Bildschirminhalt, Auflösung, Frame-Aktualisierung, Komprimierung, Caching und Datenmenge.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Wie Ein- und Ausgabe des Bildschirms, Gründe für ausgelassene Frames und Codierungszeit geprüft werden. Da auch ältere Konfigurationen beschrieben werden, werden die zahlenmäßigen Obergrenzen nicht auf jedes RDP verallgemeinert.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Last auf gemeinsam genutzten Hosts, Kommunikation vom Host zum Back-End und Auswirkungen der Geräteumleitung.
• Microsoft Learn, Threading model. UI-Thread und Dispatcher in WPF sowie das Auslagern von Verarbeitung, um die Reaktionsfähigkeit zu erhalten.
• Microsoft Learn, mstsc. Angabe von Breite, Höhe und mehreren Monitoren für Remotedesktop.
• Microsoft Learn, Supported RDP properties. Unterscheidung zwischen Desktopauflösung, dynamischer Auflösung und smart sizing. Prüfen Sie die unterstützten Clients und die Geltungsbedingungen je Produkt.
• Microsoft Learn, ping. Prüfung der Antwort per ICMP Echo und Optionen.
• Microsoft Learn, Test-NetConnection. Prüfung der TCP-Verbindung und Bedeutung der Ausgabe.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Messabschnitt von User Input Delay, unterstützte Betriebssysteme, Instanzen und Bedeutung des Maximalwerts.
• Microsoft Learn, query session. Sitzungsinformationen und die zum Abfragen anderer Sitzungen nötigen Berechtigungen.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Auswahl von TCP und UDP für RDP und Fallback.
• Microsoft Learn, RDP Shortpath. UDP-Pfad für Azure Virtual Desktop und das Verhalten, wenn er nicht aufgebaut werden kann.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. GPU-Konfiguration und -Überprüfung, getrennt nach Rendern und Frame-Codierung.

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Dies sind Themenseiten, die zu diesem Thema passen. Ausgehend vom Artikel gelangen Sie zu verwandten Leistungen und weiteren Artikeln.

Leistungen zu diesem Thema

Dieser Artikel führt zu den folgenden Leistungsseiten. Beginnen Sie gern mit einem Einstieg, der Ihrem Anliegen nahekommt.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Der Speedtest zeigt mehrere Hundert Mbit/s – warum ist die Eingabe in RDP trotzdem langsam?

Wie schnell große Datenmengen transportiert werden und wie lange es dauert, bis auf eine Aktion eine Reaktion zurückkommt, sind zwei verschiedene Dinge. Beteiligt sind das Senden der Eingabe, die Verarbeitung in der Anwendung auf dem Host, die Komprimierung des Bildschirms, die Übertragung und die Anzeige auf Ihrem eigenen Rechner. Außerdem unterscheidet sich der Netzwerkpfad zum Speedtest-Server von dem zum RDP-Host.

Tippen funktioniert normal, nur der Bildlauf ruckelt. Liegt das an der Leitung?

Auf die Leitung allein lässt sich das nicht eingrenzen. Wenn die Bildschirmaktualisierungen zunehmen, kommt möglicherweise eine Stelle nicht mehr mit: das Rendern und Komprimieren auf dem Host, die Übertragung oder das Decodieren und Anzeigen auf Ihrem eigenen Rechner. Ändern Sie Auflösung und Anzahl der Monitore auf der Remoteseite jeweils einzeln und vergleichen Sie; untersuchen Sie bei Bedarf die Leistungsindikatoren für das Rendern.

Wenn ping schnell antwortet, ist die RDP-Kommunikation dann in Ordnung?

Das allein reicht für ein Urteil nicht aus. ping misst die Antwort auf ICMP, nicht aber die RDP-Grafikübertragung oder die Verarbeitung in der Anwendung. In Konfigurationen mit RD Gateway oder Ähnlichem stimmt zudem der Pfad möglicherweise nicht überein. Auch wenn keine Antwort kommt, unterscheiden Sie zwischen blockiertem ICMP und einer nicht erreichbaren RDP-Verbindung.

Ist User Input Delay die Zeit vom Tastendruck bis zum Erscheinen des Zeichens?

Nein. Es ist ein Leistungsindikator, der die Wartezeit misst, von dem Moment, in dem eine Eingabe auf dem Host in die Warteschlange gelangt, bis der Prozess sie abholt. Er gibt nicht die empfundene Verzögerung an, die den Netzwerk-Roundtrip, die Verarbeitung in der Anwendung nach dem Abholen sowie Komprimierung, Decodierung und Anzeige des Bildschirms einschließt.

Sollte ich UDP deaktivieren, wenn RDP träge ist?

Pauschal empfehlen wir das nicht. Prüfen Sie zuerst die tatsächliche Transportart, den Pfad und die angewendeten Richtlinien. Es kann sein, dass UDP nicht nutzbar ist und die Verbindung bereits auf TCP zurückgefallen ist; eine Umstellung auf ausschließlich TCP macht die Verbindung nicht immer schneller. Vergleichen Sie mit Erlaubnis des Administrators unter gleichen Bedingungen und machen Sie unnötige Änderungen rückgängig.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Vertretungsberechtigter von KomuraSoft LLC

Schwerpunkte sind Windows-Softwareentwicklung, technische Beratung und Fehleruntersuchung. Besondere Stärken liegen bei Projekten mit bestehenden Assets und bei der Untersuchung von Störungen, deren Ursache schwer erkennbar ist.