PostgreSQL unter dem Shop schneller machen
Mehr tippen Sie nicht
„Analysiere die Performance der PostgreSQL-Datenbank auf shop01. Was sich am Server verbessern lässt, mach gleich. Was die Shop-Anwendung ändern müsste, schreib mir als Bericht.“
- Wer
- Der Admin, nach einer Beschwerde aus dem Vertrieb
- Server
- shop01, PHP-Shop und PostgreSQL 16 auf einer Maschine
- Ihr Anteil
- Ein Satz, abends den Bericht lesen
- Stufe
rwxÄndert allein, siehe die drei Stufen
Problem
Der Shop wird langsamer, je mehr Bestellungen die Datenbank hält. Datenbank und PHP teilen sich eine Maschine, PostgreSQL läuft mit den Vorgaben der Installation, und ob die Schuld bei der Datenbank oder im Shop-Code liegt, weiß niemand. Eine Analyse kostet einen Tag mit pg_stat_statements und Ausführungsplänen, und von den Funden kann der Admin nur die Hälfte selbst beheben: Der Rest ist Sache der Entwickler des Shops.
Gesucht: Was am Server zu tun ist, gleich tun. Was in den Shop-Code gehört, als Bericht für die Entwickler.
Lösung
Ein Satz mit zwei Aufträgen. Heinzel Pro misst, stimmt Datenbank und Server ab, legt die fehlenden Indizes an und schreibt die drei Dinge auf, die nur der Shop ändern kann.
Schritt 1: Sie teilen die Aufgabe in zwei Hälften
Der Satz oben sagt, was Heinzel Pro selbst erledigen soll und was nur aufgeschrieben wird. Sie wählen shop01 und stellen die Stufe auf „Ändert allein“: Die Änderungen am Server sind umkehrbar, und der Bericht ist ohnehin Ihr Teil.
Schritt 2: Heinzel Pro misst
Drei lesende Befehle: die Maschine und die Einstellungen von PostgreSQL, die teuersten Abfragen und die Tabellen, die ganz gelesen werden, die Verbindungen aus php-fpm. Der Befund: 32 GB Speicher, aber 128 MB Puffer und Kosten wie für Festplatten; zwei fehlende Indizes, die 60 % der Datenbankzeit kosten; 180 offene Verbindungen, von denen 6 arbeiten. Drei Dinge löst Heinzel Pro am Server, drei weitere gehören in den Shop-Code.
Schritt 3: Der Plan für den Server läuft allein
Drei Schritte: die Einstellungen in conf.d und ein Neustart von drei Sekunden, die zwei Indizes ohne Sperre, während der Shop läuft, und die Prüfung mit derselben Abfrage wie vorher. Dazu, was der Neustart kostet und wie alles zurückgeht. Niemand gibt frei; der Plan steht da, bevor der erste Schritt läuft.
Schritt 4: Der Bericht für die Entwickler
Die Artikelsuche braucht 0,09 ms statt 212 ms, PostgreSQL rechnet mit 8 GB Puffer und SSD. Dann die drei Punkte, die nur der Shop ändern kann: die Suche ohne lower(), die 38 Abfragen je Produktseite auf eine, und die 180 offenen Verbindungen aus php-fpm. Sie stehen in der Antwort, in der Zusammenfassung der Session und im Journal von shop01, wo die nächste Session sie liest.
