Wie ihr über das Wochenende sicher bemerkt habt, hatte dieser Server am Wochenende mehrmals Schluckauf, was dem Speicherengpässen zuzurechnen ist.
Sowohl der Arbeitsspeicher als auch die Swap-Partition liefen regelmäßig voll, da die Requests nicht mehr bearbeitet werden konnten.
Dies ist nun über einen einfachen aber sehr wirkungsvollen Hack gelöst.
Alle 45 Minuten wird nun der jeweilige Blogindex manuell gecached und somit als statische Variante ausgeliefert.
Das funktioniert einfach in der Verbindung mit cron (*/45 * * * * /home/pw/bin/cron.sh 2>&1 /dev/null) und:
/usr/bin/wget -N -q -O /.../www/domain1.org/index.html http://www.domain1.org/ondex.php
/usr/bin/wget -N -q -O /.../www/domain2.de/index.html http://www.domain2.de/ondex.php
Das funktioniert einfach und gut. Vorher muss nur die alte index.php von WordPress in ondex.php umbenannt werden (oder ihr ändert einfach die Auslieferungsreihenfolge von index.php auf zuerst index.html) und gegebenenfalls die Permalinks abgeändert werden, in diesem Fall auf:
/ondex.php/%category%/%year%/%monthnum%/%postname%/
Der Vorteil gegenüber herkömmlichen Caching-Plugins wie WP-Cache, WP Super Cache und Co ist schlichtweg, dass alle PHP-Interpretationen und MySQL-Aufrufe eliminiert werden und so zumindest auf der jeweiligen Startseite keine unnötige Speicherbelastung vorkommt.
Die jeweiligen Unterseiten werden, zumindest bei mir, dann über WP-Cache bedient, denn dort sind die Speicheraufrufe weniger interessant, da der meiste Traffic einfach auf der Startseite ankommt.
Der 45 Minutenintervall wird verwendet, da meine Blogs meist zu diesen Zeiten geupdatet werden.
Damit könnt ihr loslegen und euch einiges an Speicher sparen.
Soeben habe ich eine menge Blogs auf das neue WordPress 3.0 mit dem Releasenamen “Thelonious” in der de_DE-Version portiert.
Bei den meisten Blogs hat das Upgrade problemlos funktioniert, nur bei einem leider nicht.
Der Blog zeigt an sich nur statische Seiten an, weswegen ich mein Template so umgebogen habe, dass es keine weiteren Funktionen gibt und lediglich eine Theme-Datei geladen werden muss.
Um möglichst viele Rechenoperationen zu sparen hatte ich im Design für die Anzeige des Contents lediglich geschrieben:
Das führte dazu, dass nach dem Update der gesamte Content nicht angezeigt wurde.
Das Problem lässt sich einfach lösen, wenn man den Inhalt mit folgendem Code anzeigt:
Rechnet zwar ein paar Millisekunden länger aber das sollte keine Probleme machen.
Daher noch ein paar Empfehlungen für eine schnelle Auslieferung:
Fasst so viele Dateien zusammen, wie möglich. Dies sowohl bei den CSS- als auch JS-Files aber auch unbedingt die internen PHP-Aufrufe minimieren.
Installiert das WP-Cache-Plugin um möglichst viele Seiten statisch auszuliefern
Komprimiert euren Code
Optimiert eure Datenbank und euren Webserver auf minimale Timeouts, sodass diese lediglich so lange laufen wie nötig, aber so kurz wie möglicht.
Hat jemand noch mehr Tips dazu?
Beste Grüße!
Peter
Aktuell entwickle ich wieder an einem WordPress-Plugin um kontextabhängig Produkte aus der Zanox-API anzuzeigen.
Das ganze basiert auf über den Ajax-Callback und benötigt damit keine weiteren Serverkapazitäten (zumindest auf der Seite des Webseitenbetreibers).
Das Plugin gibt es wie die anderen dann auf der WordPress Extend Seite bei den Plugins oder hier.
Wer es vorher haben und testen will, soll mir einfach kurz eine eMail schreiben.