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 wegschmeisst; 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 winzigkleider 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?
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.