Auf Ebene der TCP-Dialoge wird unterschieden zwischen:
Response Time (einfache Antwortzeit)
Application Response Time
(Antwortzeit der Applikation)
Dies erklärt sich wie folgt an einem einfachen Beispiel:
Wenn ein Client eine Anfrage an den Datenbank-Server stellt, antwortet dieser in der Regel sofort mit einem leeren TCP ACK, also einer Empfangs-Quittung ohne Daten-Anteil, mit welcher (a) der Erhalt der Anfrage bestätigt wird sowie (b) der Client mittels TCP Window Size = 0 = ZERO davon abgehalten wird, weitere Anfragen zu stellen, bevor der Server die Antwort zurück gegeben hat.
Auf der Ebene des TCP-Protokolls wäre jetzt eine Response Time von praktisch fast 0 Sekunden gegeben.
Für den Client jedoch zählt am Ende, zu welchem Zeitpunkt die Antwort aus den Datenbank-Tabellen vorliegt. Da diese Antwort nicht die des TCP-Treibers ist, sondern der Datenbank-Anwendung, wird die Wartezeit zwischen Client-Anforderung und Applikations-Antwort Application Response Time bzw. ART genannt.
Ein LAN-Analyzer, der lediglich die Delta Time zwischen TCP-Request und TCP-ACK darstellt, ist am Ende wenig hilfreich. Viele LAN-Analyzer jedoch können die ART korrekt darstellen.
Die Erfordernisse an die Analyse von Antwortzeit gehen aber noch weiter. Dies lässt sich am Beispiel verdeutlichen.
Sendet nun der Datenbank-Server die Applikations-Daten an den Client zurück (= Application Response), lässt sich zwar somit (wie oben beschrieben) die ART des Servers ermitteln, aber nicht die des Clients.
Der Server wird in aller Regel mit dem letzten TCP-Paket seiner Antwort die TCP Window Size wieder herauf setzen, um den Client in die Lage zu versetzen, erneut eine Anfrage an den Server zu richten. (In diesem Zusammenhang versteht sich von selbst, dass eine TCP Window Size von "0" nichts Falsches ist, sondern einen zweckmäßigen Stop-And-Go Verkehr durchsetzt.)
Nunmehr ist es Aufgabe, die Wartezeit zu ermitteln, die
zwischen der Server-Antwort und der nächsten Client-Anforderung liegt,
zwischen der ersten Client-Anfrage und der zweiten Client-Anfrage liegt.
Am Ende also liegen mehrere Zeit-Werte vor, und erst deren gemeinsame Betrachtung ergibt ein Bild davon, wie die verschiedenen Wartezeiten sich aufgliedern.
Dessen aber immer noch nicht genug.
Nunmehr müsste zur Bewertung dieser Zeit-Werte bekannt sein, ob denn die Antwortzeiten als "schnell" oder "langsam" eingestuft werden sollten. Denn dies hängt von vielen Faktoren ab:
Wie komplex ist die Datenbank-Abfrage? Ist es ein einfaches SQL-Statement des Clients? Werden sog. "Stored Procedures" verwendet? Werden Filter verwendet?
Wie groß sind die Datenbank-Tabellen, auf die sich die Anfrage richtet? Sind es mehrere Tabellen? Sind diese relational verbunden? Müssen sie gefiltert werden? Welche Aktionen in weiteren Tabellen ziehen diese Filterungen nach sich?
Muss der Datenbank-Server auf weitere Daten-Server zurück greifen, um antworten zu können, oder gehen bereits alle erforderlichen Daten aus den Tabellen der Datenbank hervor?
Passt die Antwort in ein einziges TCP-Paket, oder muss sie auf mehrere TCP-Pakete verteilt werden? Verläuft die Strecke zurück zum Client nur via LAN, oder auch via WAN?
Verfügt der Datenbank-Server über ein internes Protokoll, das die Transaktionen aufzeichnet samt der wechselseitigen Abhängigkeiten der einzelnen Aktionen sowie samt der jeweils verstrichenen Wartezeit je Aktion?
Timer und Timeouts können, sofern ungünstig konfiguriert und/oder ungünstig reagierend, die Anwender-Tätigkeiten stark ausbremsen - und dies traditionell sehr stark in den Namensdiensten, aber auch in Applikationen und Treibern. Hier muss gezielt angesetzt und analysiert werden.
Wie schnell ersichtlich ist, sind die Einfluss-Größen nach Art und Zahl dermaßen vielgestaltig, dass eine Bewertung der Client-Server-Dialoge nach den Kategorien von "schnell" und "langsam" nur nach eingehender Betrachtung möglich sind - sofern nicht wirklich blitzschnelle Antworten beiderseits vorliegen (dann erübrigt sich naturgemäß und erfreulicherweise jede Diskussion). Sobald jedoch die Antwortzeiten Raum zu Zweifeln lassen, kann es sehr schnell sehr schwierig werden.
Mail
an die Online-Redaktion zum aktuellen Thema ("Antwortzeit").
