Warum eine geschwätzige SQL-App über ein VPN kriecht und was sich bündeln lässt

Ein Formular, das im LAN in unter einer Sekunde erscheint, braucht über ein VPN fünf Sekunden, während eine Dateikopie auf derselben Verbindung mit voller Geschwindigkeit läuft. Der Unterschied ist nicht die Bandbreite. Das Formular wartet auf eine Folge von Antworten und zahlt bei jedem Schritt den vollen Umlauf, während die Dateikopie Bytes fortlaufend in Bewegung hält. Zählen Sie diese Wartezeiten, bevor Sie die Zugangsleitung anfassen.

Das Symptom ist ein Bildschirm, keine Abfrage

Jede Abfrage auf diesem Bildschirm kann schnell sein, und der Bildschirm kann trotzdem langsam sein, weil die Summe aus Wartezeiten besteht und nicht aus Ausführungszeiten. Eine Anweisung, die in zwei Millisekunden läuft, kostet trotzdem einen vollen Umlauf, wenn der Client ihr Ergebnis erhalten muss, bevor er die nächste sendet. Auf einem Pfad mit vierzig Millisekunden Latenz summieren sich hundert abhängige Aufrufe auf etwa vier Sekunden, bevor irgendeine Darstellungsarbeit beginnt. Diese Arithmetik ist ein Modell der Wartezeit, kein Messwert Ihrer Leitung.

Deshalb wirkt ein Geschwindigkeitstest harmlos. Massentransfer misst Durchsatz, ein geschwätziges Formular misst Latenz, und ein VPN kann bei dem einen hervorragend und bei dem anderen mittelmäßig sein. Den Bildschirm zu diagnostizieren heißt daher, den Bildschirm zu messen und nicht die Leitung.

Notieren Sie die Ende-zu-Ende-Zeit einer Benutzeraktion, bevor Sie etwas ändern. Diese Zahl ist die einzige Grundlinie, die Ihnen sagen kann, ob eine spätere Korrektur gewirkt hat.

Zählen Sie sequenzielle Wartezeiten in einer Benutzeraktion

Messen Sie im Client, statt zu raten. In psql gibt \timing on die verstrichene Zeit jeder Anweisung aus, und EXPLAIN (ANALYZE, BUFFERS) zeigt, wie viel dieser Zeit der Server tatsächlich für die Arbeit aufgewendet hat.

Die Lücke zwischen diesen beiden Zahlen ist Ihr Netzwerk- und Client-Overhead. Wenn eine Anweisung in zwei Millisekunden ausgeführt wird und der Client sechzig notiert, sind die verbleibenden achtundfünfzig Reise und lokale Verarbeitung, und kein Index beseitigt sie. Wiederholen Sie diesen Vergleich für jede Anweisung, die der Bildschirm absendet, und addieren Sie die Lücken statt der Ausführungszeiten.

Schreiben Sie das Ergebnis als Anzahl sequenzieller Wartezeiten auf. Das ist die Größe, die die nächsten beiden Abschnitte senken können, und es ist eine Zahl, über die Sie mit Belegen streiten können.

Bündeln Sie die unabhängigen Aufrufe, behalten Sie die abhängigen

Zwei Anweisungen, die nicht die Ergebnisse der anderen lesen, können gemeinsam reisen und einmal eingesammelt werden, was zwei Wartezeiten zu einer macht. Zwei Anweisungen, bei denen die zweite den Wert der ersten braucht, können das nicht, weil die Abhängigkeit real ist und Bündelung ändern würde, was das Programm tut. Sortieren Sie die Aufrufe in diese zwei Haufen, bevor Sie etwas umschreiben, und die Größe jedes Haufens sagt Ihnen, was möglich ist.

Mengenbasierte Arbeit entfernt Wartezeiten gründlicher als Bündelung. Eine Abfrage, die die Zeilen zurückgibt, die eine Schleife einzeln abholte, beseitigt die Schleife ebenso wie die Umläufe. Suchen Sie zuerst die Schleife, weil sie meist der größere Gewinn und die leichtere Änderung für das Review ist.

Ein Bündel muss weiterhin Fehlerbehandlung und Transaktionsgrenzen wahren. Unzusammenhängende Anweisungen zu einer Zeichenkette zu verketten ist keine sichere Optimierung, und ein Bündel, das eine fehlgeschlagene Anweisung hinter einer erfolgreichen Übermittlung versteckt, ist schlimmer als die eingesparten Wartezeiten.

Verwenden Sie Verbindungen wieder, bevor Sie Bandbreite kaufen

Eine neue Verbindung kostet Namensauflösung, einen TCP-Handshake, TLS-Verhandlung und Authentifizierung, und auf einem Pfad mit hoher Latenz ist jedes davon ein weiterer Umlauf, bevor die erste Abfrage läuft. Verbindungspools existieren, um diese Kosten einmal pro Prozess zu zahlen statt einmal pro Aufruf.

In ADO.NET gibt das Schließen oder Freigeben einer gepoolten Verbindung sie zur Wiederverwendung zurück, statt eine neue physische zu öffnen, sodass das Muster, das wie ein Leck aussieht, oft die korrekte Nutzung ist. Prüfen Sie, ob der Pool wirklich genutzt wird, statt es anzunehmen: Protokollieren Sie die Erstellung physischer Verbindungen oder beobachten Sie die Sitzungszahl auf dem Server, während der Bildschirm läuft. Die SQL-Leistungsempfehlungen sagen dasselbe über das Reduzieren von Umläufen und das Bündeln häufiger Ad-hoc-Aufrufe, mit dienstspezifischen Beispielen, die Sie auf Ihre eigene Bereitstellung übertragen sollten.

Pooling beseitigt die Einrichtungskosten und lässt sequenzielle Abfragewartezeiten unberührt. Es ist eine Voraussetzung für eine saubere Messung, keine Korrektur für sich.

Wägen Sie ab, die Ausführung näher an die Daten zu verlagern

Die Anwendung nahe an der Datenbank auszuführen ersetzt viele entfernte Datenbank-Austausche durch eine einzige entfernte Anzeigesitzung. Für eine geschwätzige Last kann das eine große Änderung sein, und es ist ebenso eine betriebliche Änderung wie eine Leistungsänderung: Sitzungsverwaltung, Zugriffskontrolle, Softwareverteilung und Benutzererfahrung ziehen alle mit der Anwendung um.

Messen Sie die tatsächliche Schnittstelle und die Daten, die sie überträgt, bevor Sie annehmen, dass eine Richtung schneller ist. Eine entfernte Desktop-Sitzung bewegt Pixel, und ein Bildschirm mit dichter Grafik kann auf demselben Pfad schlechter abschneiden als die Abfragen, die er ersetzt hat, besonders wenn der Client fortlaufend neu zeichnet.

Wiederholen Sie dann die ursprüngliche Aktion und vergleichen Sie drei Zahlen: sequenzielle Wartezeiten, Ergebnisvolumen und Ende-zu-Ende-Fertigstellungszeit. Eine Verbesserung, die die gemessene Benutzeraufgabe verändert und dabei Datenkorrektheit und Zugriffsrichtlinie bewahrt, ist die, die es zu behalten gilt.