Bei einem aktuellen Projekt musste ich mich ein wenig mit dem Ram einschränken, da der vServer nur 96MB Ram zur Verfügung hat. Darum habe ich mich für eine saubere Lighttpd Installation ohne Schnickschnack und ohne Control Panel entschieden. Der Server läuft sauber mit ca. 60MB Ram-Auslastung dank WP Supercache für Wordpress, XCache und einigen kleinen Optimierungen. Das einzige Problem ist die etwas unterschiedliche (im Vergleich zu Apache) Architektur des Webservers Lighttpd, was zur Folge hat, dass mod_rewrite Regeln aus einer .htaccess Datei nicht beachtet werden und man sich mit dem eigenen url.rewrite helfen muss. Nach einigem Zusammensuchen im Netz habe ich eine gute Konfiguration gefunden, die Einwandfrei funktioniert.
Die Rewrite-Regeln muss man dem Server noch beibringen, indem man die Konfiguration anpasst. Man öffnet die lighttpd.conf
nano /etc/lighttpd/lighttpd.conf
und fügt folgende Zeilen hinzu:
url.rewrite = (
"^/(wp-admin|images|wp-content|awstats)/{0,1}(?!no.css)(.*)" => "$0",
"^/sitemap/?$" => "/index.php?pagename=sitemap&pg=1",
"^/sitemap/([0-9]+)/?$" => "/index.php?pagename=sitemap&pg=$1",
"^/library/?$" => "/index.php?now_reading_library=true",
"^/library/tag/(.+)/?$" => "/index.php?now_reading_tag=true&now_reading_tag=$1",
"^/library/([0-9]+)/?$" => "/index.php?now_reading_single=true&now_reading_id=$1",
"^/page/([0-9]+)/?$" => "/index.php?paged=$1",
"^/date/([0-9]+)/?([0-9]+)/?$" => "/index.php?m=$1$2",
"^/date/([0-9]+)/?([0-9]+)/?([0-9]+)?$" => "/index.php?m=$1$2$3",
"^/feed/(feed|rdf|rss|rss2|atom)/?$" => "/index.php?feed=$2",
"^/(.+)/feed/(feed|rdf|rss|rss2|atom)/?$" => "/index.php?category_name=$1&feed=$2",
"^/(.+)/(feed|rdf|rss|rss2|atom)/?$" => "/index.php?category_name=$1&feed=$2",
"^/(.+)/([0-9]+)/[^/]+/?/feed/(feed|rdf|rss|rss2|atom)/?$" => "/index.php?category_name=$1&p=$2&feed=$3",
"^/(.+)/([0-9]+)/[^/]+/?/(feed|rdf|rss|rss2|atom)/?$" => "/index.php?category_name=$1&p=$2&feed=$3",
"^/(.+)/([0-9]+)/[^/]+/?/page/?([0-9]{1,})/?$" => "/index.php?category_name=$1&p=$2&paged=$3",
"^/(.+)/([0-9]+)/[^/]+/?([0-9]+)?/?$" => "/index.php?category_name=$1&p=$2&page=$3",
"^/(.+)/([0-9]+)/[^/]+/?/trackback/?$" => "/index.php?category_name=$1&p=$2&tb=1",
"^/category/(.+)/?$" => "/index.php?category_name=$1",
"^/?$" => "/index.php",
"^/([_0-9a-zA-Z-]+)/?$" => "/index.php?page_id=$1"
)/etc/init.d/lighttpd restart
Anschließend startet man noch den Lighttpd Webserver neu und die Änderungen sollten Wirksam sein. Wenn es noch nicht auf Anhieb klappt auch an solche Sachen denken wie “Cache leeren” 
(via)
Ein riesiger Teil aller Internetseiten verwendet heutzutage Google Analytics oder andere ähnliche Analysedienste um das Nutzungsverhalten seiner Besucher zu Untersuchen und dementsprechend Optimierungen zu treffen oder auch Werbung zu schalten. Aber was ist mit den Nutzer, dem einfachen Surfer? Er sieht meistens nicht einmal, dass seine Browserdaten und Informationen über sein Betriebssystem oder die Bildschirmauflösung mitgeloggt werden. Für Firefox gibt es daher die Erweiterung Ghostery, die jedem Internetnutzer schnell ein Zeichen gibt, welches Analysetool gerade auf der besuchten Webseite aktiv ist.
Ghostery erkennt Analysedienste
Es kommt sogar vor, dass Webseiten 3 oder 4 verschiedene Analysetools im Einsatz haben. Ich persönlich habe natürlich auch gern einen Überblick über meine Besucheranzahl und nutze daher CyStats. Die meisten Informationen sind für micht hierbei jedoch irrelevant.
Nachdem die neue Version von Wordpress erschien waren einige Plugins nicht mehr kompatibel und man ist sich nicht sicher, ob man updaten sollte und sich eventuell den Blog zerschießt. Daher sollte man die Kompatibilität vorher hier überprüfen und sich erst dann für ein Update entschließen oder nicht.
Kompatibilitätscheck für Wordpress Plugins
Wer viele Plugins benutzt sollte seinen RAM-Verbrauch ein wenig im Blick behalten. Hierzu habe ich schon einmal ein Plugin vorgestellt. Nun lohnt es sich natürlich ein bisschen im Blick zu behalten welches Plugin denn am meisten RAM verbraucht und eventuell wieder deaktiviert werden sollte. Studenten haben ja bekanntlich alle Zeit der Welt und so hat Info-Tain eine Übersicht über alle Plugins und deren RAM-Auslastung in seinem Blog erstellt. Die Werte können natürlich bei anderen variieren, aber als Richtwerte sind sie schon ganz übersichtlich zusammengetragen.
Viele Blogger haben nach dem Upgrade auf Wordpress 2.8 ein Problem mit dem Ram-Verbrauch (gelesen bei caschy). Eine Meldung wie “WordPress: Fatal error: Allowed memory size of X bytes exhausted” kommt dann. Fast immer liegt der hohe Speicherverbrauch an der Anzahl der installierten Plugins, ich habe zur Zeit 18 installiert, die alle mehr oder weniger ihren Dienst erledigen. Um sich rechtzeitig vor solch einem Fehler zu bewahren kann man das Wordpress-Plugin WP-Memory-Usage benutzen um den aktuellen RAM-Verbrauch zu ermitteln.
WP-Memory Usage - RAM-Verbrauch bestimmen
Bei den meisten “shared Hosting” Packeten liegt das Memory Limit allerdings bei 32 oder maximal 64MB und man hat somit nicht mehr allzu viel Luft nach oben übrig.
Heute habe ich den Blog auf Wordpress 2.8 DE umgestellt. Die neue Version trägt den Namen “Baker”. Die Entwickler von Wordpress haben nach eigenen Angaben 790 Bugs gefixt und andere Dinge wie den Speed und das Theme-Management verbessert. Ich bin gespannt wie gut oder schlecht die neue Version läuft. Es gab beim Umstellen kurz das ein oder andere Problem mit den Plugins, aber diese sollten nun alle behoben sein und alles sollte wieder wie gewohnt (gut) funktionieren. Die wichtigsten neuen Änderungen sind hier zu betrachten.