Nachdem sich nun schon einige Leute über die vermehrt stark ausgeprägte Trägheit meines Blogs beschwert haben, eine Neuinstallation mit zugehöriger Bereinigung gewisser Altlasten und das Abschalten aller vermeintlich unnützen Plugins nichts gebracht hat, habe ich mich für andere Wege entschieden.
Phase 1: Noch mehr Plugins (Yeah gib’s ihm Jonny)
So ein WordPress nutzt eine Datenbank. Und nicht nur WordPress nutzt die, sondern auch einige PlugINs. Diese Tatsache pfeifen mittlerweile schon Spatzen von den Dächern. Hier muss es also Einsparpotenzial geben. Die Logik, welche dahinter steht ist klar wie ein Gebirgsquell: Große Datenbank = langsame Zugriffe, kleine Datenbank = schnelle Zugriffe.
Als erstes habe ich via WP-DBManager meine WordPress-Datenbank gesichert und optimieren lassen. Viel gebracht hat es meines Erachtens nicht, aber wenigstens hatte ich nun eine Sicherung. Im zweiten Schritt habe ich von CyStats die Live-Datenbanktabelle gelöscht. Auch das hat nicht wirklich viel gebracht. Die Datenbank war wieder etwas kleiner, die Seitenperformance aber nicht besser und wenn, dann nur unmerklich. Alles weitere Gebastel an der Datenbank brachte in meinen Augen keinen Nutzen. Also stoppte ich hier und schaltete um auf …
Phase 2: Zwischenspeicher („Ca$h-is-Klee“)
Nun kann man ja verschiedene Daten zwischenspeichern. So sorgen Plugins wie WP-Cache, W3 Total Cache oder WP Super Cache dafür, dass die Seiten des Blogs nicht dynamisch in Laufzeit zusammengebaut und angezeigt werden, sondern die Seiten werden vorher gebaut und auf dem Server abgelegt. Wenn dann ein Besucher den Blog anklickt, dann bekommt er eine statische, schon fertige Seite abgeliefert. Das entlastet den Server. Gerade bei Servern mit hohen Besucherzahlen muss der Server nicht für jede Person erneut die Seite aufbauen.
Allerdings hat diese Technik auch ihre Schattenseiten. So werden einige Statistik-Plugins damit nicht fertig und verzählen sich. Da falsche Zahlen nicht so mein Fall sind, habe ich diese Cache-Geschichte erst einmal wieder fallen lassen. Vielleicht komme ich später noch einmal darauf zurück. Da bekanntlicher Weise aller guten Dinge drei sind, kommen wir nun zu
Phase 3: ran an den Server („Liebling, ich bin zu Hause!“)
Ich mag einfach das Schrauben an unserem Server. Da mir das Schrauben an der Hardware aus Ermangelung an einer dicken Standleitung und dem nötigen Kleingeld für die Serverenergie leider weiterhin verwehrt bleiben wird und ich in absehbarer Zeit auch kein eigenes Rechenzentrum aufmachen werde, muss ich mich hier auf die Software beschränken. Aber selbst das kann schon ein Akt sein, wenn man bedenkt, dass ein Provider selbst bei einem V-Server mit Rootzugriff immer noch die Eckdaten des Systems vorschreibt. Zwar kann man Geschmacksrichtungswünsche bezüglich der Hardwareausstattung mit dem nötigen Kleingeld erkaufen, aber spätestens bei der Vielfalt der Betriebssysteme und dessen Versionierung legt der Provider sein Veto ein. Schließlich läuft der V-Server in seiner Infrastruktur.
Wie dem auch sei, ich hatte mich für einen Virtual Server L mit der Geschmacksrichtung Linux von 1und1 entschieden. Ich bereue diese Entscheidung auch nicht. Performance und Preis/Leistung stimmen für mich. Allerdings hatte ich in einem Anfall von geistiger Umnachtung damals bei der Erstinstallation auf ein Suse Linux 64 bit geklickt. Mein Fehler! Wenn ich eins an der Suse Distribution hasse, dann die Tatsache, dass alle Dateien irgendwie an einer anderen Stelle liegen, als es bei sonstigen Tuxen der Fall ist. (Von Yast möchte ich gar nicht erst schreiben. Was man sich da wohl gedacht hat?) Da lobe ich mir doch die aufgeräumte Struktur von Debian. Debian gab es zwar auch, aber mittlerweile leider in der nicht mehr ganz so aktuellen 4er Version. Aber wie schon gesagt: Mein Fehler!
Auf der Tuxe läuft eine Standardinstallation des Apache2 mit PHP 5.2 und MySQL 5. Nun gibt es für eine PHP-Server-Umgebung ebenfalls Optimierungsmaßnahmen, welche zwar meist zum Standard vieler Hosting-Angebote zählen, bei einer Standardinstallation eines V-Servers jedoch vom Administrator – in diesem Falle mir – selber installiert werden müssen. Die Rede ist von Optimierungen der Zend Engine. Diese liest PHP-Code ein, analysiert diesen und bringt ihn zur Ausführung. Man spricht hier von einem Interpreter. Der Unterschied zum Compiler ist, dass der Quellcode nicht erst in ein vom System direkt ausführbares Programm umgewandelt wird, sondern er wird direkt zur Laufzeit ausgeführt. Soll das Programm nochmals durchlaufen werden, muss der Quellcode erneut vom Interpreter analysiert werden.
Und hier setzen die Optimierungen an. Der PHP-Code durchläuft mehrere Interpreterschritte. Die Zend Engine ist so gebaut, dass mehrere Caches zwischengeschaltet und redundanter Code entfernt werden kann. Neben verschiedenen Lösungen gibt es den eAccelerator und den Zend Optimizer. Beide Mechanismen tragen auf ihre Weise zur Codeoptimierung bei. Während der eAccelerator wie eine Art Cache für PHP-Seiten wirkt und fertig interpretierte Seiten im Shared Memory des Server für einen erneuten Abruf bereit hält, optimiert der Zend Optimizer den PHP-Code zur Laufzeit. Beide zusammengenommen sorgen also für optimierte, vorgespeicherte, schnell abrufbare Seiten. Hört bzw. liest sich ja erst einmal nicht schlecht.
Beide Optimierungslösungen, der eAccelerator ist open-source und der Zend Optimizer ist in der kostenlosen Community-Edition erhältlich. Der eAccelerator kann in der aktuellen Version hier bezogen werden: [KLICK]. Für den Zend Optimizer muss man sich leider einmal registrieren, bevor man ihn hier herunterladen kann: [KLICK]. Beide lassen sich mit unterschiedlichem Schwierigkeitsgrad an den Start schieben. Während man beim Zend Optimizer nur die für den eigenen Server passende .so-Datei an die richtige Stelle zu kopieren ist, muss der eAccelerator auf dem System kompiliert werden. Das klingt schlimmer als es ist, wenn alles optimal vorbereitet ist.
Bei mir war leider nicht alles optimal vorbereitet und so musste ich ein wenig suchen, bevor ich alle Komponenten auf dem System hatte, um den eAccelerator zu kompilieren. Folgende Pakete sollten sich auf dem System befinden, bevor man loslegt:
- apache 2 und php5
- php5-devel (phpize ist Bestandteil dieses Pakets)
- autoconf (zum Generieren von Konfigurationsscripten)
- automake (zum Generieren der make-Datei)
- libtool (Supportscript für Programmbibliotheken)
- m4 (Makroprozessor)
- gcc (compiler)
Alle Programmpakete können in Suse über Yast2 installiert werden. Man verbindet sich also per SSH mit dem Server. Dazu kann man z. B. Putty nutzen. Ein feiner, kleiner SSH- und Telnet-Client, welchen ich mir persönlich in das System32-Verzeichnis kopiert habe. So kann man ihn direkt als Befehl aufrufen. Aber das ist Geschmackssache.
Wie dem auch sei. Die ersten Schritte sind:
- Putty starten –> Domain des Servers eingeben –> auf „verbinden“ klicken
- so denn SSH-Zugang eingerichtet war, anmelden –> yast2 eingeben –> Softwareumgebung
- Pakete suchen und installieren
- Yast wieder beenden
Der eAccelerator
Die Vorarbeit ist damit abgeschlossen. Nun soll der eAccelerator kompiliert und installiert werden. Dazu muss er aber erst auf den Server geladen und entpackt werden. Dazu wechseln wir in das Verzeichnis /usr/src und holen uns mit wget http://bart.eaccelerator.net/source/0.9.6.1/eaccelerator-0.9.6.1.zip das Archiv mit den Source-Dateien. Wenn alles richtig gelaufen ist, dann sieht das so aus:
Nun heißt es das Archiv mit unzip -x eaccelerator-0.9.6.1.zip zu entpacken und dann wechselt man mit cd eaccelerator-0.9.6.1 in den Ordner, um folgende Befehle abzusetzen:
sxxxxxxxxx:/usr/src/eaccelerator-0.9.6.1 # phpize sxxxxxxxxx:/usr/src/eaccelerator-0.9.6.1 # ./configure sxxxxxxxxx:/usr/src/eaccelerator-0.9.6.1 # make sxxxxxxxxx:/usr/src/eaccelerator-0.9.6.1 # make install
Damit ist der eAccelerator installiert. Allerdings muss dieser noch in der php.ini aufgerufen und konfiguriert werden. Bevor dort jedoch Änderungen vorgenommen werden, sollte man noch ein Cache-Verzeichnis für das Zwischenspeichern angelegt und mit den nötigen Schreibrechten versehen werden. Ich habe mein Cache-Verzeichnis unter /var/cache angelegt:
sxxxxxxxxx:/usr/src/eaccelerator-0.9.6.1 # cd /var/cache sxxxxxxxxx:/var/cache # mkdir eaccelerator sxxxxxxxxx:/var/cache # chmod 0644 eaccelerator
Danach wechselt man in das Verzeichnis ( /etc/php5/apache2) und öffnen die php.ini mit einem Texteditor. Bei den meisten Standardtuxen ist VIM immer mit an Board. In die php.ini habe ich dann folgende Zeilen eingepflegt:
extension="eaccelerator.so" eaccelerator.shm_size="16" eaccelerator.cache_dir="/var/cache/eaccelerator" eaccelerator.enable="1" eaccelerator.optimizer="1" eaccelerator.check_mtime="1" eaccelerator.debug="0" eaccelerator.filter="" eaccelerator.shm_max="0" eaccelerator.shm_ttl="0" eaccelerator.shm_prune_period="0" eaccelerator.shm_only="0" eaccelerator.compress="1" eaccelerator.compress_level="9"
Der Zend Optimizer
Hier ist die ganze Sache weniger tragisch. Man läd sich hier nach der Anmeldung das Komplettpaket herunter und sucht sich für die installierte Linux-Distribution und der zugehörigen PHP-Version die richtige Datei heraus und kopiert diese in den Extension-Ordner für die PHP-Umgebung. Danach noch ein kleiner Eintrag in die php.ini und die Sache ist fertig. Ich habe das in drei einfache Schritte erledigt:
- .so-Datei herausgesucht und per ftp auf den Server geladen
- in das Extension-Verzeichnis (/usr/lib64/php5/extensions) gewechselt und per wget-Befehl (wget http://www.leben-zwo-punkt-null.de/ZendOptimizer.so) die Datei geholt
- Eintrag in die php.ini mit Hilfe von VIM –> Zend_extension=/usr/lib64/php5/extensions/ZendOptimizer.so
Jetzt flux den Apache mit /etc/init.d/apache2 restart neu gestartet und die Sache ist vollbracht. Wenn man sich jetzt die über einen Browser die php.info anzeigen läßt, dann sollte man unter anderen auch diesen Eintrag vorfinden:
Beide Optimierungen sind nun installiert und aktiv. Ob es etwas für den Blog gebracht hat? Mag sein. Es war auf jeden Fall die Erfahrung wert.
Yeah Baby, jetzt gehts ab hier… 8)
Wie auch gestern Abend versteh ich nicht mehr als Bahnhof, aber es funktionniert! Das freut mich!
Ich verstehe das ganze auch nicht, aber ich kann wieder schreiben. das ist gut schönes Wochenende
it works! i love it!
[…] Server damit ausgestattet.Besonders geholfen haben mir dabei die folgenden Seiten:Gregel Dot Comleben-zwo-punkt-nullJetzt hoffe ich, es hat etwas gebracht, das Modul läuft jedenfalls mit Erfolg.Jetzt heißt es […]