Die ersten beiden Artikel dieser Reihe beschäftigten sich hauptsächlich mit Optimierungen auf der Content-Bereitstellungsseite durch WordPress. Im heutigen dritten und vorerst letztem Teil möchten wir versuchen, den ein oder anderen Tipp für die Optimierung auf der Datenbank-Ebene zu geben.

Tipps bei Zugriff auf die MySQL-Konfiguration

Wer einen eigenen Server (VServer oder Root-Server) für sein Blog betreibt, hat in aller Regel auch vollen Zugriff auf die Konfiguration des Servers. Dies ist besonders wichtig, da in der Regel innerhalb des /etc-Verzeichnisses eine Datei namens my.cnf zu finden ist, die die Konfigurationsdetails der MySQL-Datenbank beinhaltet. Bitte Beachten: Sämtliche Änderungen an dieser Datei beeinflussen das Verhalten der Datenbank und können im Fehlerfall auch dazu führen, dass die Datenbank nicht mehr startet und nicht mehr ausgeführt wird. Es empfiehlt sich also vor jeder Änderung in dieser Datei, sich eine Kopie des Originals zu ziehen, damit im Problemfall wieder die Originaleinstellungen vor der Änderung eingetragen werden können.

Doch was sind die optimalen Einstellungsparameter? Dies kann man pauschal leider nicht  beantworten, da hier sehr individuell auf die Serverumgebung abgestimmt werden sollte. Es gibt jedoch ein Script, welches auf der Linux-Shell des Servers aufgerufen wird, und welches anhand der Statusvariablen der laufenden Datenbank anzeigt, wo aktuell Probleme und Engpässe zu erkennen sind und welche Parameter in Ordnung sind. Herunterladen kann man den Tuning-Primer hier: Downloadlink zum Tuning-Primer-Skript.

Es empfiehlt sich, immer nur wenige Änderungen auf einmal vorzunehmen und den Datenbankserver mindestens 48h mit der neuen Konfiguation laufen zu lassen, um für den nächsten Tuning-Primer-Lauf genügend statistische Werte gesammelt zu haben, um die Änderungen durch das Script beurteilen zu lassen. Kürzere Wartezeiten gehen zwar auch, liefern aber erwartungsgemäß ungenauere Werte.

Im Idealfall lässt man das Tuning-Primer-Script alle paar Wochen vielleicht mal von Hand durchlaufen, um sich einen Überblick zu verschaffen, was die Statistik so sagt  und ob an der ein oder anderen Stelle noch einmal nachgeschraubt werden muss.

Mal vollkommen von der Konfiguration der Datenbank entfernt wurde mir persönlich auch mal der Tipp herangetragen, statt des Hostnamen für den Datenbankserver in der wp-config.php die IP-Adresse des Servers einzutragen, da dann auf Webserverseite eine DNS-Abfrage wegfallen würde, was wiederum einige Millisekunden Zeitersparnis einbringen würde. Da jedoch DNS-Abfragen 30  Minuten auf der Clientseite gecached werden (und der Werbserver ist in diesem Fall der Client im DNS) ist die Ersparnis, die sich hierdurch ergeben würde, eigentlich für ein durchschnittliches Blog vernachlässigbar.

Optimierungschancen bei fehlendem Konfigurationszugriff auf den Datenbankserver

Wer keine Möglichkeit hat, auf die Konfigurationsdatei der MySQL-Datenbank zuzugreifen, weil man vielleicht ein Shared-Hosting-Paket gebucht hat und damit im Grunde zufrieden ist, dem ist immer noch die Optimierungsmöglichkeit auf der Strukturebene der WordPress-Datenbank gegeben.

Datenbank-Indices und ihre Wirkungen

Im Grunde ist hier zwar keine Nacharbeit erforderlich, da WordPress im Lieferzustand durchaus sinnvoll die sogenannten Indices auf die Tabellen gesetzt hat, doch hin und wieder soll es schon mal vorkommen, dass Plugins eigene Tabellen der Gesamtstruktur hinzufügen und dabei kann es passieren, dass aus Nachlässigkeit oder durch ein fehlerhaftes Update eines Plugins auf diesen Tabellen Indices fehlen, die sinnvollerweise doch besser vorhanden wären.

Doch bevor hier über Dinge gesprochen wird, die man nicht kennt: Was sind eigentlich Indices?

Eine Datenbanktabelle besteht aus einer zweidimmensionalen Struktur: Wir haben Zeilen (diese Stellen einen Datensatz dar) und diese einzelnen Zeilen bestehen aus Spalten (dies wiederum sind die konkreten einzelnen Datenfelder eines Datensatzes). Daten werden innerhalb dieser “Tabellen” so gespeichert, dass sie einfach chronologisch in der Reihenfolge ihres Auftauchens unten an die Tabelle angehangen werden. Im Grunde ist also eine solche Tabelle “unsortiert” oder eben zufällig zeitlich sortiert. Nun gibt es aber Datenfelder, die immer wieder mal als Suchspalte herhalten müssen. Eine Suche über eine Datenspalte in einer unsortierten Tabelle endet immer darin, dass die komplette Tabelle von Anfang bis Ende (=sequenziell) durchsucht werden muss, weil man sich ja nicht sicher sein kann, ob man mit dem auffinden eines Datums bereits alle möglichen gefunden hat. Eine Sortierung über diese Spalte hätte simpel ausgedrückt den genialen Vorteil, dass man, wenn man wieder von Anfang bis Ende suchen würde, nach dem ersten Auffinden nur noch so oft weitersuchen müsste, bis man keine weiteren Datensätze mehr in Folge gefunden hätte, die dem Suchkriterium entsprechen. Die Suche kann also im Idealfall bereits beim 2. Datensatz enden, wenn der gesuchte Datensatz der erste in der Tabelle wäre und der zweite im Suchkriterium sich vom ersten unterscheidet.

In der Datenbanktheorie gibt es hier noch viele viele andere Möglichkeiten, wie man nun effizient und schnell in sortierten Datenbanken suchen kann – darüber brauchen wir uns jedoch keine Gedanken zu machen, denn für uns sucht MySQL – und wie es das tut, ist uns egal, Hauptsache ist nur: Es geht schnell!

Doch damit MySQL nun in einer Tabelle über eine Spalte schnell suchen kann, benötigt es hier einen Index auf der Spalte. Diesen Index kann man z.B. mit einem Tool wie phpMyAdmin (meistens sogar von den Hosting-Unternehmern in den Verwaltungstools zur Datenbankverwaltung integriert) auf den Tabellenspalten anlegen. Jedoch sollte man hier schon genau wissen, was man tut, denn wildes Indizieren kann auch wiederum negative Wirkungen entfalten und die Datenbank eher bremsen als beschleunigen.

Die Datenbank “entschlacken”

Wie im menschlichen Leben ist es in der IT speziell bei Datenbanken so: Wer ein wenig schlanker ist, ist in der Regel auch etwas schneller unterwegs. Bezogen auf die WordPress-Datenbank heißt dies: Hier sammelt sich im Laufe eines Blog-Lebens viel Datenkram an, der nicht wirklich benötigt wird aber in häufig benutzten Tabellen rumlungert und damit die Anzahl der zu durchsuchenden Datensätze nur unnötig vergrößert.

Hier rät man gerne dazu, regelmäßig mal die Datenbank ein wenig zu entschlacken, zu belüften und damit wieder etwas Performance zu gewinnen. Im Plugin-Repository von WordPress finden sich einige gute Plugins zur Optimierung und Entschlackung. Ich selbst nutze z.B. das Plugin “WP-Optimize” (zur Homepage von WP-Optimize). Es bietet zwar nur wenige Funktionen, diese sind jedoch klar und deutlich in dem, was sie tun und somit für Einsteiger sicherlich besser geeignet als irgendwelche Allrounder, wo man über sehr ausgebildetes Datenbankverständnis verfügen muss.

Lesetipps im WWW

• MySQL-Referenzhandbuch, Kapitel 6: MySQL-Optimierung
• Linux-Magazin: Performance-Optimierung in MySQL
• MySQL-Server Optimierung und Defragmentierung

Ähnliche Artikel

1. Blogoptimierung – woher kommt der Speed – Teil 2
2. Blogoptimierung – woher kommt der Speed – Teil 1
3. WordPress 2.9 veröffentlicht