Es ist nicht so einfach, WordPress mit varnish zu verheiraten; WordPress schickt bei jedem Aufruf Session-IDs mit, was das Caching aus dem Stand heraus unmöglich macht.
Man kann sich behelfen, indem man diese (ohnehin überflüssigen) Sessions wegschmeißt; tut man das jedoch generell für die gesamte Seite, kann man sich ins Admin-Interface wp-admin nicht mehr einloggen. Und auch die Vorschau von sich in Arbeit befindlichen Artikeln funktioniert dann nicht mehr, und… achja… ;)
Ich habe nun eine ganze Weile an einer Konfiguration getüftelt, die sowohl für mich als auch für meine Besucher so komfortabel wie möglich ist, und die HIT-Raten sind inzwischen bemerkenswert: recht stabil bei 70% und oftmals deutlich darüber. Meine aktuelle Konfiguration — und es ist ganz sicher nicht die letzte Version davon — habe ich nun auf github gepackt, da ich immer wieder auf das Thema angesprochen werde. Benötigt sind die (eher übersichtliche) /etc/default/varnishGITHUB und die (recht umfangreiche) /etc/varnish/default.vclGITHUB.
Der Host ist übrigens ein winzigkleiner VPS mit 1GB RAM; er ist, trotz steigender Zugriffszahlen, vergleichsweise idle, da ich die MySQL-Konfiguration ebenfalls ein wenig frisiert habe, so dass auch hier viel aus dem Cache geholt wird, und zugleich varnish die meisten HTTP-Anfragen (auf Port 80) beantwortet und nur wenige an apache (Port 8080) durchreichen muss.
Wie gestaltet ihr das Tuning auf euren Servern? Oder erschlagt ihr auftretende Probleme lieber mit Hardware?
1 Comment
WordPress lasse ich mit Wordfence ausliefern – das generiert statische HTML-Dateien in einem Unterverzeichnis, biegt per mod_rewrite die Zugriffe um, so dass statische Dateien ausgeliefert werden. Bevor das dichtgezogen wird durch Massenzugriffe, ist mein upstream dicht (7,5 MBit/s …).
Andere Seiten (auf MODX-Basis) lasse ich auch mit Varnish cachen, komplett im RAM. Läuft gut.