Die gestrichelte Linie zeigt die Antwortzeit mit dem Index SCALE_SLOW
. Bei 25 gleichzeitigen Abfragen steigt die Antwortzeit auf 32 Sekunden. Im Vergleich zur Geschwindigkeit ohne Hintergrundaktivität – wie es zum Beispiel in einer Entwicklungsumgebung sein könnte – dauert die Abfrage 30-mal so lange. Selbst wenn man den vollen Datenbestand in der Entwicklungsumgebung hat, kann die Abfrage im Produktionssystem immer noch um Faktoren langsamer sein.
Die zweite Linie zeigt den Verlauf der Antwortzeit mit dem Index SCALE_FAST
– also ohne Filterprädikat. Dadurch bleibt die Antwortzeit stets unter 2 Sekunden – selbst wenn 25 Abfragen gleichzeitig laufen.
Das sorgfältige Lesen des Ausführungsplanes gibt mehr Sicherheit als oberflächliche Tests.
Ein voller Stresstest ist dennoch wertvoll, aber viel aufwendiger.
Auffällige Antwortzeiten werden während der Entwicklung oft „auf die leichte Schulter genommen“. Meistens, weil man von der „viel stärkeren Produktionshardware“ bessere Performance erwartet. Das Produktionssystem ist aber häufig komplexer – dadurch können sich zum Beispiel Latenzen akkumulieren, die in der Entwicklungsumgebung nicht auftreten. Selbst wenn das Testsystem produktionsäquivalent ist, hat man in der Produktion eine andere Hintergrundlast und damit andere Antwortzeiten. Im nächsten Abschnitt werden wir sehen, dass es ganz generell keine gute Idee ist, von „größerer Hardware“ schnellere Antworten zu erwarten.
Artikel „Latency: Security vs. Performance“ über Latenzen in komplexen Infrastrukturen.
Artikel: „We are experiencing too much load. Let’s add a new server“ von Jams Golick.
Du kannst nicht alles an einem Tag lernen. Abonniere den Newsletter via E-Mail, Bluesky oder RSS um sukzessive aufzuholen. Und sieh dir auch modern-sql.com an.
Markus verwandelt veraltetes SQL-92-Wissen in solides und zeitgemäßes SQL-Know-how