Praxisfall: SQL über WAN-Strecke – wenn die Applikation bremst, nicht das Netz

„Das Netz ist schuld.” Diesen Satz hört man in IT-Projekten erstaunlich oft – und meistens zu früh. Besonders bei verteilten Anwendungsarchitekturen über WAN-Strecken ist es verlockend, die Netzwerkverbindung als Ursache für Performance-Einbrüche zu benennen. Schließlich liegt sie irgendwo zwischen den Systemen, ist schwer sichtbar und noch schwerer zu beweisen.

Dieser Praxisfall zeigt, wie eine strukturierte Netzwerkanalyse mit Wireshark dabei hilft, genau diese Schuldfrage sauber zu beantworten – und warum die Antwort manchmal überraschend klar ausfällt.

Die Ausgangssituation: Einfrieren ohne offensichtliche Ursache

Das Szenario ist typisch für mittelständische IT-Umgebungen: Eine geschäftskritische Anwendung wird über eine Citrix-Farm bereitgestellt. Sie läuft stabil – bis auf ein wiederkehrendes Phänomen, das die Anwender zunehmend frustriert: Die Anwendung friert mehrmals täglich ein, für Zeiträume zwischen zwei und dreißig Sekunden.

Auffällig dabei ist, dass das Problem alle Benutzer gleichzeitig trifft, unabhängig davon, auf welchem Terminalserver ihre Sitzung läuft. Noch merkwürdiger: Das Einfrieren tritt auch dann auf, wenn die Anwender gerade gar nichts tun – also zum Beispiel telefonieren und nur auf den Bildschirm schauen. Das deutet früh darauf hin, dass es sich nicht um ein benutzerspezifisches Problem handelt, sondern um etwas im Hintergrund.

Die Architektur hinter der Anwendung ist eine klassische dreistufige Konstellation: Ein Applikationsserver im lokalen Rechenzentrum kommuniziert mit einem Linked DB Server, der wiederum Datenbankabfragen an einen externen DB Server eines Drittanbieters weiterleitet – über eine WAN-Verbindung. Diese Architektur ist grundsätzlich nichts Ungewöhnliches, birgt aber typische Fallstricke, die sich bei der Analyse schnell zeigen.

Die Methodik: Aufzeichnung zum Fehlerzeitpunkt

Bevor man mit der Analyse anfängt, ist eine saubere Aufzeichnung entscheidend. Der Mitschnitt muss an der richtigen Stelle im Netzwerk platziert werden – idealerweise dort, wo der verdächtige Datenverkehr vorbeiläuft, also am Linked DB Server, der die zentrale Vermittlungsstelle zwischen den beiden Umgebungen darstellt.

Entscheidend ist außerdem, die Fehlerzeitpunkte von den Anwendern dokumentieren zu lassen. Nicht vage („irgendwann am Morgen”), sondern so präzise wie möglich. Nur so lässt sich der Mitschnitt später gezielt filtern und der relevante Zeitraum isolieren. In der Praxis kommt es immer wieder vor, dass Traces über Stunden oder Tage laufen – und der eigentlich interessante Moment sich auf wenige Sekunden konzentriert.

Wenn du tiefer in die Methodik einer strukturierten Aufzeichnung einsteigen möchtest, empfehle ich dir den Artikel Netzwerkprobleme systematisch eingrenzen, der den gesamten Analyse-Workflow beschreibt.

Der erste Blick: Was zeigt die Übertragungskurve?

Ein guter Einstieg in jeden Mitschnitt ist die Übertragungskurve – also die grafische Darstellung, wie viele Daten über die Zeit übertragen werden. Hier erkennt man auf Anhieb, ob es Einbrüche, Pausen oder Auffälligkeiten gibt, die zeitlich mit dem gemeldeten Fehlerzeitpunkt korrelieren.

In diesem Fall war die Übertragungskurve eindeutig: Zum gemeldeten Fehlerzeitpunkt bricht die Übertragung für mehrere Sekunden nahezu vollständig ein. Das ist ein klares Signal, dem man nachgehen muss.

Die entscheidende Frage ist jetzt: Wer ist verantwortlich für diese Pause? Das Netz? Der Server? Die Applikation?

Die Analyse auf TCP-Ebene: Wer schweigt hier?

Um das zu beantworten, filtert man den Mitschnitt auf die betroffenen TCP-Sitzungen und schaut sich die Kommunikation im Detail an. Wireshark bietet dafür hervorragende Möglichkeiten – insbesondere die TCP Delta Time, also die Zeit zwischen zwei aufeinanderfolgenden Paketen innerhalb einer TCP-Verbindung.

Wenn du wissen willst, wie man TCP-Streams grundsätzlich liest und interpretiert, ist der Artikel Wie lese ich einen TCP Stream richtig? eine gute Ergänzung zu diesem Praxisfall.

Im konkreten Fall zeigt sich bei genauem Hinsehen etwas Interessantes: Während der Übertragungspause sendet der Applikationsserver selbst keine SQL-Requests. Der Linked DB Server antwortet korrekt und zeitnah auf die vorherigen Anfragen. Der App Server quittiert diese Antworten ordnungsgemäß – und macht dann einfach eine Pause. Er stellt für mehrere Sekunden gar keine neuen Anfragen.

Das ist ein wichtiger Befund: Das Netz schweigt, weil der Absender schweigt – nicht weil das Netz blockiert ist.

Netzwerklaufzeit und Response Time: Das Netz ist unauffällig

Um sicherzugehen, dass keine versteckten Netzprobleme vorliegen, schaut man sich die klassischen Kennzahlen an.

Die Netzwerklaufzeit (RTT) wird am elegantesten beim TCP-Sitzungsaufbau gemessen – am sogenannten TCP Three-Way Handshake. Beim SYN/SYN-ACK/ACK-Austausch gibt es noch keine Applikationslogik, die Verarbeitungszeit verursacht. Was man hier misst, ist reine Netzwerklaufzeit.

In diesem Fall liegt die durchschnittliche Netzwerklaufzeit zwischen Applikationsserver und Linked DB Server im lokalen Rechenzentrum im Bereich von unter 0,1 ms – ein vollkommen unauffälliger Wert für eine LAN-Verbindung. Die WAN-Strecke zum externen DB Server zeigt etwas höhere Werte, wie es für eine dedizierte Standleitung zu erwarten ist – aber auch hier nichts, was als Problem gewertet werden müsste.

Die Server Response Time – also die Zeit, die ein Server benötigt, um auf eine Anfrage zu antworten – ist ebenfalls unauffällig. Zwischen Applikationsserver und Linked DB Server gibt es keine Ausreißer, die auf Überlast oder Verarbeitungsprobleme hindeuten würden.

TCP Retransmissions: Gibt es Paketverluste?

Ein weiterer klassischer Indikator für Netzprobleme sind TCP Retransmissions. Sie entstehen, wenn Pakete auf der Strecke verloren gehen und der Sender sie erneut übermitteln muss.

Im Mitschnitt wurden einige TCP Retransmissions erfasst – genauer gesagt TCP Fast Retransmissions. Bei näherer Betrachtung zeigt sich jedoch, dass diese nicht auf Paketverluste zurückzuführen sind. Stattdessen hat der empfangende Applikationsserver auf das TCP-PSH-Flag nicht schnell genug reagiert, weshalb der Sender präventiv erneut gesendet hat. Ein echter Paketverlust hat dabei nicht stattgefunden.

Wer den Unterschied zwischen TCP Fast Retransmission, Dup ACKs und Out-of-Order-Paketen genauer verstehen möchte, findet dazu eine ausführliche Erklärung in: TCP Retransmissions, Dup ACKs & Out-of-Order – Unterschiede.

TCP Zero Window Events – also Situationen, in denen ein Empfänger seinen Eingangspuffer nicht schnell genug leert und den Sender ausbremst – wurden im gesamten Mitschnitt nicht ein einziges Mal erfasst. Auch das spricht klar gegen ein Netzwerk- oder Kapazitätsproblem.

Die Server-Analyse: Wo entsteht der Engpass?

Interessant wird es bei der Auswertung der simultanen Requests. Zwischen Linked DB Server und dem externen DB Server bestanden während des Aufzeichnungszeitraums nur wenige parallele TCP-Sitzungen. Da SQL-Requests innerhalb einer TCP-Sitzung sequenziell abgearbeitet werden – also eine Anfrage nach der anderen – ist die maximale Parallelität durch die Anzahl der offenen Verbindungen begrenzt.

Zwischen Applikationsserver und Linked DB Server gab es deutlich mehr gleichzeitige Verbindungen und entsprechend mehr simultane Requests. Sobald die Zahl der simultanen Anfragen jedoch die Kapazität der Verbindungen zum externen DB Server übersteigt, steigt die durchschnittliche Antwortzeit spürbar an. Hier entsteht ein Engpass – nicht weil das Netz zu langsam ist, sondern weil die Anzahl der parallelen Verbindungen zur Datenbank die Menge der eingehenden Anfragen nicht aufnehmen kann.

Das ist kein Netzwerkproblem. Es ist ein Architektur- und Konfigurationsproblem: zu wenige parallele Verbindungen für die Last, die die Applikation erzeugt.

Das Gesamtbild: Was sagt der Trace wirklich aus?

Am Ende der Analyse ergibt sich ein klares Bild:

• Das Netz ist unauffällig. Laufzeiten, Response Times und Paketverluste bewegen sich alle im erwarteten und akzeptablen Bereich.
• Die Übertragungspausen gehen vom Applikationsserver aus. Er stellt selbst keine neuen SQL-Requests – das Netz wartet auf ihn, nicht umgekehrt.
• TCP Retransmissions sind kein Hinweis auf Paketverluste, sondern auf verzögerte ACKs seitens des Applikationsservers.
• Ein potenzieller Engpass liegt in der Verbindungsarchitektur zur externen Datenbank: Zu wenige parallele TCP-Sitzungen sorgen dafür, dass bei hoher Last die Antwortzeiten deutlich ansteigen.

Was konkret zur Pause auf dem Applikationsserver führt – ob es sich um interne Verarbeitungslogik, Timer, Sperrmechanismen oder andere applikationsseitige Ursachen handelt – lässt sich allein aus dem Netzwerktrace nicht abschließend klären. Dafür braucht man weitergehende Analyse auf Serverebene: Prozess-Monitoring, Applikations-Logs oder serverseitige Traces können hier Licht ins Dunkel bringen.

Was man aus diesem Praxisfall mitnehmen kann

Dieser Fall ist ein gutes Beispiel dafür, wie wertvoll eine saubere Netzwerkanalyse als Ausschlussverfahren ist. Manchmal besteht das Ergebnis nicht darin, das Problem zu finden – sondern darin, klar zu belegen, wo es nicht liegt.

Das klingt auf den ersten Blick unbefriedigend. In der Praxis ist es aber das Gegenteil: Ein sauber dokumentierter Nachweis, dass das Netzwerk keine Ursache ist, spart enorme Zeit. Er verhindert, dass IT-Teams wochenlang an der falschen Stelle suchen, unnötige Hardware beschafft wird oder Dienstleister beauftragt werden, ein Problem zu lösen, das gar nicht bei ihnen liegt.

Gleichzeitig gibt der Trace konkrete Hinweise: Die Pause liegt auf dem Applikationsserver, und die Verbindungsarchitektur zur Datenbank zeigt einen potenziellen Engpass bei hoher Last. Das sind verwertbare Erkenntnisse, die das weitere Vorgehen gezielt steuern.

Typische Fehler bei WAN-SQL-Szenarien

In der Praxis begegnen mir bei ähnlichen Architekturen immer wieder die gleichen Muster, die Performance-Probleme verursachen:

• Zu wenige parallele Datenbankverbindungen – die Applikation erzeugt mehr Last, als der Connection Pool verarbeiten kann
• Sequentielle statt parallele Abfragen – Abfragen werden nacheinander abgesetzt, obwohl sie unabhängig voneinander wären
• Chatty Application Patterns – die Anwendung sendet viele kleine Anfragen statt wenige effiziente, was über WAN-Strecken besonders stark ins Gewicht fällt
• Fehlkonfigurierte Prefetch-Größen – Datenbankclient holt Zeilen einzeln statt in Blöcken, was die Round Trips multipliziert

Einige dieser Muster – insbesondere das N+1-Query-Problem und sequentielle DB-Requests – werden in einem eigenen Praxisfall ausführlich behandelt: Praxisfall: Sequentielle DB-Requests & N+1 Query.

Fazit: Wireshark als Beweismittel, nicht nur als Tool

Was diesen Praxisfall besonders lehrreich macht, ist nicht die Komplexität des Problems – sondern die Klarheit, mit der Wireshark die Ursache eingrenzt. Der Mitschnitt lügt nicht. Er zeigt objektiv, wer wann sendet, wer wartet und wo Verzögerungen entstehen.

Das macht Paketanalyse zu einem der wenigen Werkzeuge in der IT, das tatsächlich als Beweismittel taugt – nicht nur als Diagnosehelfer. Gerade in Situationen, wo mehrere Teams beteiligt sind und Zuständigkeiten ungeklärt sind, ist das unbezahlbar.

Wenn du vermutest, dass dein Netzwerk langsam ist, aber nicht weißt, wo genau der Flaschenhals liegt – genau dafür ist eine strukturierte Analyse da. Nicht um Schuldige zu suchen, sondern um Klarheit zu schaffen.

Hast du ähnliche Performance-Probleme in deiner Umgebung? Schreib mir gerne – ich schaue mir den Fall an.