Manchmal ist das Auffälligste an einem Performance-Problem, dass die naheliegenden Maßnahmen bereits ergriffen wurden und trotzdem nichts bringen. Der folgende Fall ist dafür ein gutes Beispiel. Er zeigt, warum „mehr Server“ und „besserer Code“ eine Website nicht zwangsläufig schneller machen und wo die eigentlichen Hebel stattdessen liegen können.
Die Ausgangslage
Ein PHP-basiertes Shop-System, das bereits alles richtig gemacht zu haben schien: horizontal über mehrere Hosts skaliert, mit einem Paar Load-Balancern davor. Auch der Anwendungscode war zu diesem Zeitpunkt bereits überprüft und verbessert worden. Trotzdem lag die Antwortzeit (Time to First Byte) stabil bei rund 1,4 Sekunden, für einen Shop spürbar zu hoch.
Nach der üblichen Lehrbuchlogik hätte hier nichts mehr zu holen sein dürfen. Genau deshalb ist der Fall interessant.
Erste Ursache: die Taktfrequenz der CPU
Ein Hinweis kam bereits aus dem Erstgespräch: Das Entwicklungsteam hatte alles Hosting-Bezogene vollständig an den Rechenzentrums-Anbieter übergeben, der die horizontal skalierte Umgebung bereitstellte. Diese Umgebung lief auf CPUs mit 2,4 GHz Taktfrequenz.
Das ist der Punkt, an dem horizontale Skalierung oft missverstanden wird. Mehr Hosts erhöhen die Menge an Anfragen, die parallel verarbeitet werden können, also den Durchsatz. Eine einzelne Anfrage machen sie damit nicht schneller, da diese maßgeblich von der Einzelkern-Leistung abhängt, also unter anderem von der Taktfrequenz. Ein Shop kann über beliebig viele Hosts verteilt sein: Wird jede einzelne Anfrage auf einem langsamen Kern verarbeitet, bleibt die TTFB hoch.
Der Wechsel auf Infrastruktur mit 3,5 GHz brachte die Antwortzeit in die Nähe der Ein-Sekunden-Marke, allein durch die höhere Einzelkern-Leistung, ohne eine Zeile Code zu ändern. Die verbesserte Taktfrequenz der CPU half hier allerdings auch der Datenbank-Performance. Win-win also.
Zweite Ursache: Langsamer Session-Handler
Der zweite Hebel lag im Session-Management. PHP war so konfiguriert, dass Sessions als Dateien gespeichert wurden, auf dem geteilten Festplattenspeicher des Hypervisors. Jeder Lese- oder Schreibvorgang für eine Session verursachte also einen Roundtrip von der VM zum Storage und zurück, allein um Session-Daten zu lesen und zu schreiben.
Die Umstellung des Session-Managers von „files“ auf Redis verlagerte diese Daten in den Arbeitsspeicher. Der Umweg über den geteilten Festplattenspeicher entfiel. Pro Anfrage sparte das rund 80 bis 120 Millisekunden, genug, um die TTFB nun sicher unter eine Sekunde zu drücken.
Was der Fall zeigt
Weder mehr Server noch besserer Code waren hier die Lösung, beides war längst vorhanden. Die entscheidenden Verbesserungen kamen aus zwei Stellen, die im Tagesgeschäft leicht übersehen werden: der Einzelkern-Leistung der eingesetzten Hardware und dem Weg, den Session-Daten bei jeder Anfrage zurücklegen.
Leider ist dies ein häufiges Muster. Horizontale Skalierung löst ein Mengenproblem, kein Geschwindigkeitsproblem. Und ausgelagerte Verantwortung, etwa „das Hosting übernimmt der Anbieter“, führt oft dazu, dass genau solche Details niemand mehr prüft. Eine Antwortzeit von 1,4 Sekunden ist selten das Ergebnis eines großen Fehlers. Häufiger ist sie die Summe mehrerer kleiner, für sich genommen unauffälliger Entscheidungen.
Gefunden werden solche Details nicht durch Raten, sondern durch Messung von vordefinierten Leistungswerten und durch die Bereitschaft, auch dort nochmal zu suchen, wo scheinbar schon alles optimiert ist.