Gestern hatte ich euch berichtet, welche Fehler man bei der Analyse machen kann. Heute möchte ich euch einen ersten Tipp geben, wie ihr Performanceprobleme mit Datenbankabfragen erkennen könnt.

Ein sehr wichtiger Performancewert ist ja die sogenannte „Time to first byte“, also die Zeit die es dauert, bis der Server nach einer Anfrage die ersten Daten zurückschickt. Ist diese Zeit sehr hoch (etwa mehr als 0,5 Sekunden), dann ist in der Regel eines dieser beiden Dinge schuld (oder beide): die Ausführungszeit der PHP-Skript oder die Dauer der Datenbankabfragen. Um die PHP-Skripte geht es in einem anderen Artikel, also beschäftigen wird und heute mal mit den Datenbankabfragen.

Exkurs: Annahmen zu Datenbankabfragen

Ich möchte auch heute ein wenig auf typische Annahmen eingehen, weshalb eine Seite langsam ist, und diese ein wenig entkräften.

Irrtum 1: Die Anzahl der Datenbankabfragen ist entscheidend

Viele sind der Meinung, dass eine Seite, die hunderte von Datenbankabfragen macht, nicht schnell sein kann. Das kann zwar sein, oft ist es aber nicht der Fall. Selbstverständlich ist jede Datenbankanfrage eine Operation, bei der viele PHP-Funktionen ausgeführt werden und bei der mit einem externen Dienst (dem MySQL-Server) kommuniziert wird, was Arbeitsspeicher, eventuell Festplattenzugriffe und Rechenleistung benötigt. Aber selbst eine WordPress Seite mit hunderten von Datenbankabfragen kann schnell sein. Es ist eben die Qualität und nicht die Quantität die zählt – bzw. die schlechte Qualität 😉

Irrtum 2: Die Größe der Datenbank bzw. der Tabellen ist entscheidend

Auch das ist nicht ganz richtig. viel wichtiger als die Größe einer Datenbank ist die effektive Verwendung von Indizes. Ich hatte schon Tabellen mit 30 Millionen Zeilen und Abfragen hierauf (selbst JOINS) waren in unter 300ms fertig. Die einfache Suche nach einem „nächsten“ Element (Sortierung nach 3 Spalten und Filter nach 4 Spalten) in einer Tabelle mit „nur“ 70.000 Einträgen dauerte 2 Sekunden.

Ursache für die guten Abfragewerte

Wieso also sind weder viele Abfragen noch Tabellen mit vielen Zeilen ein Problem? Das liegt daran, dass MySQL einige sehr ausgeklügelte Caching-Mechanismen und Abfrage-Optimierungen hat. Wenn es gut läuft, dann kann also eine Datenbankabfrage direkt aus dem Cache (meistens dem Arbeitsspeicher) bedient werden und ist somit sehr schnell. Die Einsparung einer Abfrage kann sogar negative Folgen haben. So hatte ich es mal geschafft, eine komplexe Abfrage in nur einem SQL-Statement zu schreiben. Die Laufzeit war 2 Minuten. Ich habe daraus dann 2 Abfragen gemacht, wobei die erste ein Zwischenergebnis lieferte, dass die zweite weiterverarbeitete. Damit ließ sich die Zeit auf nur 0,2 Sekunden senken 🙂

Ihr solltet nun also hoffentlich gemerkt haben, dass die Performance von Datenbankabfragen nicht von einfachen statischen Werten abgeleitet werden kann. Vielmehr ist es wichtig, echte Zahlen zu messen und diese dann zu analysieren.

Abfragen analysieren

Um die Datenbankabfrage, die beim Aufruf einer Seite in WordPress passieren, nutze ich zwei Tools. Diese möchte ich euch nun kurz vorstellen.

Debug Queries

Das erste Tool, dass ich hierzu eingesetzt habe ist das Plugin Debug Queries von Frank Bültge. Das Design darf man ruhig als „suboptimal“ bezeichnen, aber vermutlich hätte ich einen schnellen Debugger auch nicht schöner gestaltet 😉

Das Plugin listet ganz einfach am Ende jeder Seite im Frontend alle Abfragen auf, zeigt an, wie lange sie gedauert haben und zuletzt noch, in welche Funktion und Datei die ausgeführt wurden bzw. welche Dateien zuvor schon geladen wurden.

Damit das Plugin wirklich alle Abfragen erfassen kann, müsst ihr in eurer wp-config.php Datei eine weitere Konstante definieren (am besten in der Nähe von WP_DEBUG, dann findet ihr sie schneller wieder):

define( 'SAVEQUERIES', true );

Setzt ihr diese Konstante nicht, dann werden nur die Abfragen nach dem Laden des Plugins analysiert.

Es gibt mittlerweile ein Nachfolgerplugin, das noch sehr viel mehr Analysen bietet. Es heißt Debug Objects und kann sowohl im Frontend, als auch im Backend eingesetzt werden. Ich habe es aber leider selbst noch nie eingesetzt und kann euch daher keine Erfahrungswerte dazu geben.

Query Monitor

Ein anderes sehr empfehlenswertes Plugin, dass ich mittlerweile hauptsächlich verwende, ist der Query Monitor von John Blackbourn, der auch kein ganz unbeschriebenes Blatt in der WordPress Community ist 🙂

Damit das Plugin seine volle Leistungsfähigkeit entfalten kann, muss auch hier etwas eingerichtet werden. Anstelle einer Konstanten in der wp-config.php Datei muss allerdings ein Symbolic Link gesetzt werden.

Das geniale an dem Plugin ist aber, dass es nicht nur Datenbankabfragen analysiert, sondern auch etliche andere Dinge. Sehr hilfreich ist zum Beispiel die Anzeige, welche „Conditional Tags“ auf der Seite greifen. Alles hier aufzuzählen würde bei weiten den Rahmen für den Beitrag sprengen. Ich kann aber jedem nur empfehlen, das Plugin einfach mal zu testen, es lohnt sich.

Fazit

Ich hoffe, ihr konntet heute ein wenig lernen, welche Tools ihr bei der Analyse von Datenbankabfragen nutzen könnt und welche Einschätzungen eher nicht weiterhelfen. An alle, die erwartet haben, dass ich im Artikel sage, wie lange welche Abfrage dauern darf und wie viele Abfragen zu viele sind, die muss ich leider enttäuschen. Pauschal kann man das nicht beantworten. Da aber die Dauer aller Abfragen die „Time to first byte“ direkt beeinflusst, sollte hier eine Zeit von nicht mehr als etwa 0,4 Sekunden benötigt werden, denn für PHP und andere Dinge wird auch noch Zeit benötigt und man will die Gesamtzeit ja unter allen Umständen unter 0,5 Sekunden halten.

Kennt ihr vielleicht noch ähnliche Tools zur Analyse der Datenbankabfragen? Oder habt ihr noch Tipps zu den hier vorgestellten Tools? Dann hinterlasst doch gerne wie immer einen Kommentar 😉