Artikelformat

WordPress optimieren: Varnish und mehr

Ich möchte einfach nur mal kurz beschreiben, was ich in den letzten Tagen so alles angestellt habe, um diesen Blog, der mir WordPress betrieben wird, ein wenig mehr Dampf zu geben, denn wie wir alle wissen, ist die Geschwindigkeit nicht nur gut für Google-Ranking und co., nein, viel wichtiger ist die Performance für den Leser, dem eigentlichen Empfänger der Seite. Und mir persönlich als Blogger raubt ein langsamer Blog Nerven und den Spaß am Schreiben.

Bildschirmfoto 2011-01-16 um 14.14.16.jpg

Dieser Artikel geht aber nicht unbedingt ins kleinste Detail. Ich versuche nur einige Dinge zusammenzufassen. Eventuell findet ja jemand den einen oder anderen Tipp oder kann sogar noch etwas dazu beitragen.

Bevor man mit komplexen Methoden wie Caching und co. anfängt, sollte man erst einmal die eigentlich Webseite schlank halten und in meinen Fall die Seite aufräumen und entschlacken. Das wichtigste, was einem schnell bewusst werden muss, ist die Tatsache, dass es nicht die „Performance-Lösung“ gibt, sondern das die Geschwindigkeit von Webseiten durch sehr viele einzelnen Komponenten beeinflusst wird und man an sehr viele Schrauben drehen kann und muss.

Unter Aufräumen verstehe ich zum Beispiel:

  • Entfernen von unnützen und nicht mehr gebrauchten Plugins: es sammeln sich doch im Laufe eines WordPress-Lebens zahlreiche Plugins an, die man eventuell schon längst nicht mehr benuzt. Viele Plugins bringen eigene CSS und Javascript Dateien mit, die immer bei jedem Aufruf geladen werden. Ich habe das auch getan und so ca. 20 Plugins entfernt.
  • das benutzte Theme aktualisieren: auch das benutzte Theme sollte man auf Updates überprüfen
  • Datenbank optimieren: auch die Datenbank, meisten MySQL, so auch in meinem Fall, kann durch diverse Parameter auf Performance getrimmt werden – ein Tool, welches die MySQL DB testen und danach Tipps gibt ist: mysqltuner siehe http://blog.mysqltuner.com/

Bildschirmfoto 2011-01-15 um 18.00.12.jpg

  • HTTP Request verringern: je mehr Plugins man in WordPress verwendet, um so mehr CSS und Javascript Dateien werden einzeln geladen, warum da nicht alle CSS- und Javascript-dateien zu einem File bzw. wenigen zu kombinieren – es gibt zwar ein paar WP-Plugins, die einem da unter die Arme greifen. So richtig rund lief aber keins. Daher auch keine Empfehlung.
  • Bildergrößen optimieren: Bilder sind meistens der dickste Teil einer Webseite – auch bei uns. Eine Möglichkeit ist zB. die smush.it API zu nutzen um Bilder nachträglich ohne großen Qualitätsverlust (entfernen der JPEG Meta Daten, …) zu verkleinern. Folgendes WP Plugin automatisiert diesen Prozess. http://dialect.ca/code/wp-smushit/
  • Hilfreich sind darüber hinaus Tools wie YSlow, Page-Speed von Google bzw. Firebug oder die eingebauten Entwicklertools in Safari oder Chrome. Onlinetesttools findet man unter: http://tools.pingdom.com/ oder http://www.webpagetest.org/ .

Bildschirmfoto 2011-01-16 um 13.35.09.jpg

Es gibt mit Sicherheit noch viel mehr Möglichkeiten. Nutzt doch die Kommentarfunktion für eure Tipps rund um Optimierung von Webseiten insbesondere WordPress. Ich bin noch längst nicht am Ende damit. Werde mir in Zukunft auch sehr genau überlegen, welche Plugins installiert werden und welche nicht.

Varnish – Caching und mehr

Seit einiger Zeit erzeugen kurzfristige Zugriffspitzen hier im Blog eine dermaßen große CPU-Last, dass man teilweise überhaupt nicht mehr zugreifen und die Seite als „down“ bezeichnen konnte. Speicher ist bei meiner Seite nicht das Problem. Zwei Dualcore Xeon CPUs sollten auch eigentlich ausreichen. Das CPU-intensive Erzeugen der dynamischen Seiten mittels PHP schaukelte die Last dermaßen auf, bis gar nichts mehr ging.

Lösung: Caching?!

Unter Caching versteht man das Abspeichern der dynamisch-erzeugten PHP-Seiten als statische HTML-Seiten, die dann sehr schnell geladen werden können, ohne dass die CPU zu sehr belastet wird. In diesem Zusammenhang wird oft das WordPress Plugin: WP Super Cache und der WordPress-eigene Cache empfohlen, welche auch prima bis zu einer bestimmten Seitengröße funktionieren.

Hat man aber vollen Zugriff auf seinem Server, kann man auch zu anderen Mitteln greifen – zum Beispiel: Varnish. Dieser Webbeschleuniger ist eine Art Proxy für dynamische Webseiten, konzipiert für Seiten mit viel Inhalt und wird vor dem eigentlichen Server (Apache, Nginx) geschaltet. Einen sehr guten Überblick über die verschiedenen Caching-Lösungen gibt dieser Benchmark-Artikel.

Die Installation ist recht einfach und kann mittels ein paar Befehlen unter Debian ausgeführt werden: apt-get install varnish . Fertige Pakete gibt es auch für FreeBSD, RedHat und mehr.

Die Konfiguration erfordert dann aber ein wenig mehr Einarbeitung in die Varnish Configuration Language (VCL), mit der man festlegen kann, was und wie gecacht werden soll. Eine recht brauchbare VCL für WordPress findet man hier. (Danke!) Diese kann man seinen eigene Bedürfnissen anpassen.

Varnish bringt darüber hinaus ein paar interessante Konsolentools mit:

Bildschirmfoto 2011-01-16 um 14.22.17.jpg

varnishhist – ein Histogram der Cache Treffer, varnishlog – LiveLog, varnishstat – umfangreiche Statistiken und varnishtop – Anzeige der Prozesse innerhalb von varnish

Varnish kann man auch für Loadbalancing und weiteren interessanten Konfigurationen benutzt werden.

Ein wichtiger Befehl im Zusammenhang mit Varnish ist die Möglichkeit bestimmte Elemente kurzfristig und schnell aus dem Cache zu löschen. Hier benutzt man das Administrationsschnittstelle von varnish mittels varnishadm. Beispiel: „varnishadm -T localhost:6082 purge.url http://www.aptgetupdate.de/feed/“ löscht den generierten RSS-Feed und legt den aktualisierten Feed beim nächstem Aufruf neu in den Cache. Das WordPress Plugin wp-varnish ermöglicht das Löschen des Caches aus dem WordPress-Backend heraus.

Ich persönlich finde, der Einsatz von Varnish hat sich schon gelohnt. Die Verbesserung sind deutlich spürbar, sowohl auf der Serverseite, wo die CPU-Last kaum noch spürbar ist, auch nicht wenn die gleichzeitigen Zugriffszahlen in die Höhe steigen, als auch direkt am Browser.

Frage an die WordPressbetreiber: Setzt ihr auch auf Caching? Welche Software, welche Lösung würdet ihr empfehlen?

Autor: Oliver

Ich bin Oliver und habe den aptgetupdateDE Blog im Juli 2007 aus der Taufe gehoben. Man findet mich auch auf Twitter.

22 Kommentare

  1. Ich habe auch vor meinen Blog in den nächsten ein wenig zu tunen. Zwar läuft bis jetzt alles flüssig, aber da die Besucherzahlen immer mehr werden ist es sicherlich besser schon rechtzeitig mit dem entschlacken anzufangen.

    Ich freue mich schon auf die Kommentare der anderen Leser, in der Hoffnung noch ein paar Tipps mit nehmen zu können.

    Ich werde mir gleich erstmal den MySQL Tuner genauer angucken. Auch Varnish klingt gut. Danke für die ersten Tipps.

    Gruß Timo

  2. 1.) Hatte vor einiger Zeit auch mit Varnish als Proxy experimentiert (http://suckup.de/blog/2010/10/29/nginx-varnish-auf-debianubuntu/) auch wenn die Ladegeschwindigkeit wirklich gestiegen ist, hatte ich einige Probleme mit JavaScript!?

    2.) Wer seine Webseite / Web-Server / MySQL-Server etc. per Hand optimieren möchte, findet hier (http://suckup.de/blog/2010/07/26/webseiten-beschleunigen/) meine Tipps zum Webseiten optimieren!

    3.) Und wer einfach nur WordPress beschleunigen möchte, sollte sich einmal das Plugin „W3 Total Cache“ Uhttp://wordpress.org/extend/plugins/w3-total-cache/) anschauen -> Page Cache + Minify + Database Cache + Object Cache + Content Delivery Network (CDN) + Browser Cache -> zudem kann man den Cache nicht nur auf die Festplatte schreiben, sondern auch den Opcode-Cache für PHP (APC + eAccelerator + XCache – http://suckup.de/blog/2010/07/26/apc-eaccelerator-xcache/) bzw. Memcached (http://memcached.org/ – verteiltes Caching-System per Netzwerk oder auch lokal) zum speichern der Daten verwenden. Zudem läuft das ganz auch mit Nginx (Webserver) und WordPress Multi. :-)

  3. Seit wann habt ihr denn Varnish hier im Einsatz? Ich meine die Page lädt jetzt *deutlich* schneller. Ich persönlich nutze auf http://linuxundich.de bislang W3 Total Cache. Gegenüber WP Super Cache hat es mehr Funktionen und imho ist es auch leistungsfähiger. Für WordPress-Blogger ohne eigenen Server imho eine gute Wahl.

  4. die sache mit den http requests und den zig parallel verwendeten javascript-libraries ist in der tat ein problem. ich habe mir irgendwann mal die mühe gemacht, alle js-dateien von plugins mit wp_deregister_script abzumelden.

    dann habe ich jquery global von der google ajax api angemeldet.

    danach alle plugin-spezifischen js-dateien ordnungsgemäß mit wp_enqueue_script eingebunden, so dass sie nur auf den seiten auftauchen, wo sie es sollen und dort jeweils im fußbereich der seite.

    schlussendlich wird – wenn möglich – eine js-library erkoren, die für den blog zuständig ist und alle anderen rausgeworfen. das kann etwas aufwendiger sein. so musste ich z.b. mein lightbox-plugin komplett umschreiben (von prototype zu jquery). aber die mühe lohnt sich.

    problematisch sind auch plugins, in denen js-dateien nicht – wie es sich gehört – mit wp_enqueue_script eingebunden werden. da muss man das entweder selbst im plugin umschreiben (obacht bei updates!) oder dem autor nahe legen, es zu tun.

    ein print ‚<script…‘ am wp_head aufzuhängen ist nämlich böser dilettantismus :-)

  5. Hab mich letzte Woche und heute etwas intensiver mit varnish beschäftigt. Das rockt wirklich gut. Werde mal meine Config etc. in einem der nächsten Blogposts verarbeiten. Damit kann man wirklich ne Menge machen. Welche varnish-Version setzt Du denn ein? Noch ne 1er oder schon ne 2er? Nächstes Wochenende werde ich das mal bei einigen größeren Blogumgebungen teste. Mal schauen ob es da wirklich was bringt. Danke für den Beitrag.

  6. Pingback: Wordpress optimieren: Varnish und mehr

  7. Bin mit WP Super Cache in Verbindung mit WP Minify eigentlich ganz zufrieden. Bzw. es gibt im Moment nichts zu bemägeln.
    Die Zusammenführung der static files klappt wunderbar. Über WP Super Cache könnte ich die sogar noch auf ein CDN auslagern, aber das wäre ein wenig arg overdosed.

    Ansonsten natürlich PHP Opcode Cache einsetzen, wie bevorzugt APC. Da ein Blog sehr read heavy ist, machts in normalen Umgebungen auch noch Sinn, die MySQL Engine MyISAM zu wählen falls möglich.

  8. Ich nutze bei mir aktuell das WordPress Plugin W3 Total Cache mit welchem ich ganz gut zurecht komme.

    Von der Ladezeit meiner Webseite bin ich sehr zufrieden.

    Muss da aber mal aufzeichen lassen wie stark die Ressourcen durchschnittlich ausgelastet sind.

  9. Danke für den Tipp mit Varnish – kannte ich bisher nicht und werde es mir mal genauer anschauen.

    Als Optimierungstipp könnte man z. B. auch Bildern, JS und CSS Dateien einen Expires-Header mitschicken – soo oft werden diese ja dann doch nicht aktualisiert. Zusätzlich kann das ganze komprimiert an den Besucher geschickt werden, z. B. mit nem Eintrag in der .htaccess („AddOutputFilter DEFLATE…“)

  10. Ich nutze eigentlich keine Plugins zur Blog-Optimierung (Ausnahme mein Cachify), habe alles manuell eingestellt oder halt mit kurzen Snippets in der functions.php realisiert. Ist smarter und überschaubar.

  11. Kann es sein, dass seit dem „Update“ das „speichern“ von Namen und eMail Adresse in den Kommentaren nicht mehr funktioniert?
    Eine Frage: Ist euer eigener PC/Server der Server auf dem die Dateien liegen oder nutzt ihr einen Anbieter?

  12. … die RSS- bzw. Twitter-Symbole oben rechts werden anscheinend nicht mehr animiert und die Empfohlenen Post werden auch nicht mehr korrekt angezeigt bzw. nicht mehr animiert, so dass nur noch ein Post empfohlen wird!

    … wie erwähnt hatte ich auch einige Probleme mit JavaScript + Varnish-Cache, falls es damit zusammenhängt und eine Lösung gefunden wird, würde ich diese gerne hören.

  13. Stimmt, Kommentarlogin wird nicht mehr gespeichert.
    Die Seite kommt mir jetzt auch um einiges schneller vor, schade nur, daß in der Seitenleiste die letzten Kommentare nicht mehr angezeigt werden. =)

  14. Ich habe recht gute Erfahrungen mit einem eigenen, kleinen CDN gemacht.

    Browser führen nur eine gewisse Anzahl an HTTP-Requests an eine Domain aus. Subdomains werden jedoch als seperate Domain angesehen. D.h. lagert man das JavaScript auf js.aptgetupdate.de, das CSS auf css.* und die Bilder auf img.* aus, sollte das eine deutliche Geschwindigkeitssteigerung geben, wenn man nicht sowieso viele Requests einfach weglassen kann.

    Das hat bei mir bei Grafik- u. css lastigen Seiten gute Ergebnisse gebracht. Wenn man es noch auf die Spitze treiben will, kann man mehrere virtual-hosts mit unterschiedl. Subdomains aufs gleiche wwwRoot zeigen lassen, und im eigenen Code bzw. den Verlinkungen img.aptgetupdate.de durch img.aptgetupdate.de ersetzen. So würde nicht nur eine Subdomain für alle Bilder angefragt, sondern im Idealfall die Anfragen gleichmäßig auf 6 verschiedene Subdomains verteilt. :)

  15. Erm ja, „img.aptgetupdate.de durch img<?php rand(1,6); ?>.aptgetupdate.de“ sollte es eigentlich heissen. :)

  16. PHP-Code im Pfaden von Bildern, CSS, JS […] ist nicht schön… zumindest wenn man diese Dateien sofort ausliefert -> nutze dafür nginx als Webserver :-)