Timeouts von Anfragen bedeuten nicht immer ein Problem in der Datenbank. Oft ist die Degradation im Weg zwischen der Anwendung und der DB verborgen.
Das Problem tritt auf, wenn die Metriken der Datenbank stabil erscheinen, die Kunden jedoch Timeouts erhalten. Auf der Beobachtungsebene sieht es wie ein Widerspruch aus: Die Latenz steigt, während die Datenbankzeit gleich bleibt. Der Grund dafür ist, dass die Benutzererfahrung nicht durch die Ausführungszeit der Anfrage in der Datenbank, sondern durch die gesamte Round-Trip-Verzögerung geprägt wird. Diese umfasst Verbindungspools, Load Balancer, Proxys und das Netzwerk. Die meisten Überwachungstools für Datenbanken sehen nur die interne Ausführung der Anfrage, weshalb die Degradation außerhalb der DB unsichtbar bleibt.
Der Ansatz besteht darin, die Latenz in zwei Teile zu zerlegen: Datenbankzeit und alles andere. Dieses Verhältnis lässt sich gut als Eltern-Kind-Modell betrachten. Der Elternteil ist der vollständige Round Trip (von der Anfrage bis zur Antwort). Darin enthalten sind die Ausführungszeit in der DB und der externe Overhead. Die Schlüssel Frage ist: Welcher Teil dominiert? Wenn die Datenbankzeit steigt, macht es Sinn, die Anfragen zu optimieren oder die DB zu skalieren. Wenn die externe Komponente wächst, liegt das Problem in der Infrastruktur, und eine SQL-Optimierung wird keinen Effekt haben. Dies ist ein einfacher, aber kritischer Schnittpunkt aus diagnostischer Sicht.
Die Implementierung basiert auf der Korrelation von zwei Datenquellen. APM erfasst den vollständigen Round Trip, da es auf der Anwendungsseite arbeitet und den gesamten Weg der Anfrage misst. Database Monitoring hingegen bezieht die Metriken direkt aus der DB (zum Beispiel total_exec_time in Postgres), wo nur die Ausführungszeit der Anfrage ohne Datenübertragung an den Kunden berücksichtigt wird. Der Unterschied zwischen diesen beiden Messungen ist der gesuchte externe Overhead. In der Praxis wird dies als Verhältnis von Round Trip zu Datenbankzeit dargestellt. Ein Anstieg dieses Wertes weist auf eine Degradation außerhalb der DB hin. Im betrachteten Szenario war die Ursache PgBouncer: Bei steigender Last stieß seine single-threaded Event-Loop an die CPU-Grenzen, was die Verzögerung auf der Ebene des Verbindungspools erhöhte.
Das Ergebnis dieses Ansatzes ist eine Verkürzung der Diagnosetzeit und eine Verringerung der Anzahl falscher Hypothesen. Anstatt Optimierungen innerhalb der Datenbank durchzugehen, kann man sofort die Schicht des Problems lokalisieren. Im genannten Fall ermöglichte dies, auf das Tuning von Anfragen zu verzichten und PgBouncer durch das Hinzufügen einer Instanz und Lastverteilung zu skalieren. Konkrete Metriken zur Verbesserung sind nicht angegeben, aber der Fokuswechsel von der DB zur Infrastruktur beseitigte die Quelle der Timeouts.