WordPress mit nginx und varnish Cache

fehlt wasgeht sogutsehr guthat geholfen (No Ratings Yet)
Loading ... Loading ...
Werbung




varnish HTTP Accelerator kann hoch frequentierte Worpress Blog beschleunigen. Die Anfragen werden zwischengespeichert und in einem Cache abgelegt. Gäste werden dann aus diesem Cache bedient. Somit muss der Webserver die Seiten nicht nochmal neu parsen und durch den PHP Compiler schicken.Nginx vorbereiten

Nginx ist somit für die Abarbeitung der Webseiten zuständig. Er arbeitet garz normal im Hintergrund weiter. Da aber die Anfragen nun vom varnish Cache kommen und die Logs weiterhin stimmen sollen, sollte im http Bereich von nginx 2 Zeilen hinzugefügt werden:

/etc/nginx/nginx.conf

http {
# forward readl IP from varnish
set_real_ip_from 127.0.0.1;
real_ip_header X-Forwarded-For;
...

Dies veranlasst nginx die IP aus der übergebenen Variable X-Forwarded-For als Reale IP anzusehen und diese in die Logs zu schreiben. Zu bemerken ist allerdings, dass dies nicht wirklich notwendig ist, da zur Logauswertung die Logs von varnish benutzt werden müssen. Allerdings erleichtert das evtl die Problemsuche.

Weiterhin muss der Port, auf dem nginx die Anfragen entgegen nimmt, geändert werden. In unserem Beispiel muss nginx auf Port 8888 lauschen.

Hierzu müssen die vhost-Konfigurationen angepasst werden:

/etc/nginx/sites-available/vhost-domain.tld

server {
listen   8888;
...

Nun muss varnish installiert werden (Anleitung hier) und konfiguriert werden.

varnish konfigurieren

Die Konfiguration der Datein /var/default/varnish kann wie in der Anleitung übernommen werden. Für WordPress kann dann diese Datei für die defauld.vcl benutzt werden:

/etc/varnish/default.vcl

backend origin {
.host = "127.0.0.1";
.port = "8888";
}

sub vcl_recv {
# only using one backend
set req.backend = origin;

# set standard proxied ip header for getting original remote address
set req.http.X-Forwarded-For = client.ip;

# logged in users must always pass
if( req.url ~ "^/wp-(login|admin)" || req.http.Cookie ~ "wordpress_logged_in_" ){
return (pass);
}

# don't cache search results
if( req.url ~ "\?s=" ){
return (pass);
}

# always pass through posted requests and those with basic auth
if ( req.request == "POST" || req.http.Authorization ) {
return (pass);
}

# else ok to fetch a cached page
unset req.http.Cookie;
return (lookup);
}

sub vcl_fetch {

# remove some headers we never want to see
unset beresp.http.Server;
unset beresp.http.X-Powered-By;

# only allow cookies to be set if we're in admin area - i.e. commenters stay logged out
if( beresp.http.Set-Cookie && req.url !~ "^/wp-(login|admin)" ){
unset beresp.http.Set-Cookie;
}

# don't cache response to posted requests or those with basic auth
if ( req.request == "POST" || req.http.Authorization ) {
return (pass);
}

# Trust Varnish if it says this is not cacheable
if ( ! beresp.cacheable ) {
return (pass);
}

# only cache status ok
if ( beresp.status != 200 ) {
return (pass);
}

# don't cache search results
if( req.url ~ "\?s=" ){
return (pass);
}

# else ok to cache the response
set beresp.ttl = 6h;
return (deliver);
}

sub vcl_deliver {
# add debugging headers, so we can see what's cached
#if (obj.hits > 0) {
#    set resp.http.X-Cache = "HIT";
#}
# else {
#    set resp.http.X-Cache = "MISS";
#}
# remove some headers added by varnish
unset resp.http.Via;
unset resp.http.X-Varnish;
}

sub vcl_hash {
set req.hash += req.url;
# altering hash so subdomains are ignored.
# don't do this if you actually run different sites on different subdomains
if ( req.http.host ) {
set req.hash += regsub( req.http.host, "^([^\.]+\.)+([a-z]+)$", "\1\2" );
} else {
set req.hash += server.ip;
}
# ensure separate cache for mobile clients (WPTouch workaround)
if( req.http.User-Agent ~ "(iPod|iPhone|incognito|webmate|dream|CUPCAKE|WebOS|blackberry9\d\d\d)" ){
set req.hash += "touch";
}
return (hash);
}

Quelle

Diese Konfiguration veranlasst den varnish Cache, alle Anfragen, die ein “wp-login” und “wp-admin” enthalten, direkt an den Webserver weiter zu geben und das Ergebnis auszugeben. Somit funktioniert das einloggen und das Admin-Bereich. Auch eingeloggt Benutzer bekommen geparste Seiten direkt vom Server. Aber im Normalfall werden das nicht viele sein, die Hauptanzahl der Besucher werden Gäste sein. Und hier werden die Seiten 6 Stunden gecacht und erst danach wieder vom Webserver neu abgefragt (set beresp.ttl = 6h;) – diese Einstellung kann nach eigenen Bedürfnissen angepasst werden.

varnish HTTP Accelerator Logging aktivieren (varnishncsa)

Da nun Abfragen, die gecacht sind, nicht mehr von nginx bearbeitet werden, kann auch das Logging von nginx nicht mehr stimmen. Es fehlen die Anfragen, die aus dem varnish Cache bedient werden. Da aber eine Web-Statistik gefahren werden sollte, muss nun das varnish Logging aktiviert werden.

Dazu har varnish das Tool “varnishncsa” mitgebracht.
Das Logging muss in der Konfigurationsdatei zunächst aktiviert werden:
/etc/default/varnishncsa

VARNISHNCSA_ENABLED=1

Fähnrich, Aktivieren

Zunächst starten wir den Varnish Log-Dämon:

# /etc/init.d/varnishncsa start

Nun muss nginx neu gestartet werden, damit er auf dem neuen Port 8888 lauscht:

# /etc/init.d/nginx restart

und zuletzte muss varnish HTTP Accelerator gestartet werden:

# /etc/init.d/varnish start

Nun sollte die Webseite normal erreichbar sein.

bisherige Suchbegriffe:

  • nginx varnish wordpress debian howto


Werbung


Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>