Skip to content

de Caching Methoden

timse201 edited this page Jan 31, 2017 · 51 revisions

Language: en, de

Cachify kann den Webseiten-Cache mithilfe von 4 unterschiedlichen Cache-Techniken verwalten: Datenbank, APC, Memcached (nur unter Nginx) und Festplatte. Nachfolgend werden notwendige Anpassungen an Server-Systemdateien ausführlich beschrieben.

Inhaltsverzeichnis:


Datenbank

Keine Erweiterung der Systemdatei vonnöten.


APC (Alternative PHP Cache)

Ist APC (3.1.4 oder höher) als PHP-Erweiterung auf dem Server installiert, so steht innerhalb der Plugin-Einstellungen eine entsprechende Option zur Auswahl bereit. Nach der Aktivierung legt Cachify die generierten HTML-Ansichten der aufgerufenen Blogseiten im Cache der PHP-Extension (Shared Memory) ab und benötigt beim Aufruf der Blog-Seiten keinerlei Datenbankanfragen sowie dynamische PHP-Befehle. Beim Abruf der Blogseiten aus dem APC-Cache ist die Reaktions- und Rückgabezeit des Servers überdurchschnittlich schnell.

Für den Zugriff auf den APC-Zwischenspeicher bringt Cachify eine Vermittlungsdatei – liegend unter plugins/cachify/apc/proxy.php – mit. Diese sogenannte Proxy-Datei analysiert den Cache-Vorrat auf die Existenz der aktuell aufgerufenen Webseite, liest den Inhalt im Erfolgsfall ein und sendet ihn direkt an den Browser.

Die Ausgabedateien speichert Cachify in GZIP-komprimierter Form ab, sodass keinerlei Prozesse für zusätzliche GZIP-Komprimierungen und DEFLATE-Vorgänge seitens Webserver notwendig sind. Das Caching-Plugin übernimmt die Kompression und die korrekte Ausgabe an den Server. Prozessor- und Speicherplatz-schonend.

Die Einbindung der Proxy-Datei unterscheidet sich je nach Webserver. Im Grunde handelt es sich um einen auto_prepend_file Aufruf für PHP-Dateien, welcher abhängig vom Hoster und vergebenen Privilegien in .htaccess oder php.ini eingebunden wird.

Beispiel für .htaccess (Apache):

<Files index.php>
    php_value auto_prepend_file /absoluter pfad zu/plugins/cachify/apc/proxy.php
</Files>

Beispiel für nginx-Instanzen:

location ~ .php {
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param PHP_VALUE auto_prepend_file=/absoluter pfad zu/plugins/cachify/apc/proxy.php;

    location ~ /wp-admin/ {
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param PHP_VALUE auto_prepend_file=;
    }
}

Die Dateieinbindung dieser Art umgeht die zeitraubende Ausführung des nicht ganz “leichten” WordPress-Cores und spart alle Datenbankzugriffe ein. Positiver Nebeneffekt: Der WordPress-Quelltext bleibt unberührt und bleibt somit nach wie vor Upgrade-fähig.


Memcached (nur für Nginx)

In Verbindung mit dem Webserver stellt Cachify eine weitere Caching-Methode zur Verfügung: Memcached. Nach der Auswahl der Plugin-Option (soweit verfügbar) und der Anpassung der Nginx-Konfigurationsdatei glänzt die Technik mit ihrer überragenden Geschwindigkeit, da der Cache vom Plugin im Arbeitsspeicher (RAM) des Servers ablegt und vom Webserver (Nginx) direkt an den Browser ausgeliefert wird.

Geschwinder und unkomplizierter kann eine Cache-Ausliferung nicht funktionieren. Perfektes Zusammenspiel zwischen Webserver und Memcached.

Erweiterung der Nginx-Konfigurationsdatei (https://gist.github.com/sergejmueller/6113816#file-gistfile1-txt)

## GZIP
gzip_static on;

## CHARSET
charset utf-8;

## INDEX LOCATION
location / {
	error_page 404 405 = @nocache;
 
	if ( $query_string ) {
		return 405;
	}
	if ( $request_method = POST ) {
		return 405;
	}
	if ( $request_uri ~ "/wp-" ) {
		return 405;
	}
	if ( $http_cookie ~ (wp-postpass|wordpress_logged_in|comment_author)_ ) {
		return 405;
	}

	default_type text/html;
	add_header X-Powered-By Cachify;
	set $memcached_key $host$uri;
	memcached_pass localhost:11211;
}

## NOCACHE LOCATION
location @nocache {
	try_files $uri $uri/ /index.php?$args;
}

Hinweise zu Nginx-Anpassungen

  • Bei Domains mit FQDN muss die Nginx-Variable $host gegen $http_host getauscht werden.
  • Wenn Sie Fehler haben, versuchen Sie bitte memcached_pass localhost:11211; zu memcached_pass 127.0.0.1:11211; zu ändern. Dies erzwingt IPv4, da einige Server, die ipv4 und ipv6 zulassen, so konfiguriert sind, dass sie memcached nur an ipv4 binden.

Warum nur für Nginx?

  • Apache bringt keine direkte Verknüpfung zu Memcached mit – ein Umweg über eine PHP-Datei müsste erfolgen (Analog zu Cachify APC), um von dort aus auf Caching-Daten zuzugreifen und auszugeben. Manko: Der PHP-Interpreter wird gestartet und beansprucht zeitintensive Ausführungszeit.
  • Die Ausführungszeit verlangsamt sich zusätzlich, da ausgelesene Memcached-Daten vom PHP-Skript zunächst GZIP-komprimiert werden müssten, falls die Kompression auf der Serverebene abgestellt ist.
  • Memcached (nicht Memcache) ist auf kaum einem Apache-Webserver installiert. Selbst große Hoster bieten das Modul nicht an, da zuverlässige und Nutzer-separierte Speicherverwaltung nicht sichergestellt werden kann.

Nach zahlreichen Tests und Analysen steht fest, dass die Speicherung der Webseiten in Memcache in Verbindung mit einem Apache-Webserver keinen erwarteten Performance-Gewinn mit sich bringt – Cachify HDD als Caching-Art ist in diesem Fall viel effizienter.

Auf Webservern mit Nginx sieht es ganz anders aus: Nginx ist in der Lage auf den Memcached-Bestand zuzugreifen und komprimiert auszuliefern. Ohne Zwischenschritte und in erwarteter Performance. Das Nginx-Modul HttpMemcachedModule gehört stets zum Lieferumgang des Webservers (Nginx).

Warum kein Memcache?

Die Binary-Implementierung von Memcache (also nicht Memcached) ist extrem fehlerhaft, so dass Daten nicht zuverlässig aufbewahrt werden können.


Festplatte (HDD Cache)

Ist die Festplatte als Aufbewahrungsort für den Cache ausgewählt, legt Cachify die generierten HTML-Ansichten der angeforderten Blogseiten auf der HDD des Webservers ab – pro Webseite eine HTML-Datei. Der Server übernimmt dabei die Umleitung auf die zuständige Cache-Datei. Der Start des PHP-Interpreters entfällt dabei gänzlich und sorgt somit für einen zusätzlichen Performance-Schub.

Bevor die Option in den Cachify-Einstellungen ausgewählt wird, sollte im WordPress-Verzeichnis wp-content ein neuer Ordner namens cache mit 777 als Rechte angelegt werden (später auch gerne restriktiver, falls die Funktionsweise des Plugins nicht beeinträchtigt wird). Existiert dieser Pfad bereits sind nur die Berechtigungen zu kontrollieren. Das Plugin wird zwar versuchen, den Ordner selbst zu anzulegen, doch im Fehlerfall würde das Skript mit einem Hinweis aussteigen. Aus diesem Grund lieber vorsorglich selbst Hand anlegen.

Die Vermittlung zwischen dem Seitenaufruf im Browser und der existierenden Cache-Datei steuert der Webserver: Apache oder Nginx. Entsprechend gehört diese Aufgabe an den Server delegiert. Dies geschieht durch eine Erweiterung der Apache-Datei .htaccess oder der Nginx-Konfigurationsdatei. Beispiele für Implementierungen folgen weiter unten.

Zusätzlich zu einer HTML-Variante der Webseiten fertigt Cachify eine GZIP-komprimierte Version an. Der Server greift auf die komprimierte Datei zurück und verzichtet dabei auf die eigene, zeitaufwändige Kompression der Inhalte. Man spart dabei CPU-Last, da Dateien bereits (vor)komprimiert sind.

Eine Beschreibung für nur https und Websites, die sowohl unter https und http erreichbar sind folgt weiter unten.

Erweiterung der .htaccess (Apache), wenn die Website nur über http erreichbar ist: (https://gist.github.com/sergejmueller/2027249#file-htaccess)

# BEGINN CACHIFY
<IfModule mod_rewrite.c>
    # ENGINE ON
    RewriteEngine On

    # GZIP FILE
    <IfModule mod_mime.c>
        RewriteCond %{REQUEST_URI} /$
        RewriteCond %{REQUEST_URI} !^/(wp-admin|wp-content/cache)/.*
        RewriteCond %{REQUEST_METHOD} !=POST
        RewriteCond %{QUERY_STRING} =""
        RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
        RewriteCond %{HTTP:Accept-Encoding} gzip
        RewriteCond %{DOCUMENT_ROOT}/pfad zu/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz -f
        RewriteRule ^(.*) /pfad zu/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz [L]

        AddType text/html .gz
        AddEncoding gzip .gz
    </IfModule>

    # HTML FILE
    RewriteCond %{REQUEST_URI} /$
    RewriteCond %{REQUEST_URI} !^/(wp-admin|wp-content/cache)/.*
    RewriteCond %{REQUEST_METHOD} !=POST
    RewriteCond %{QUERY_STRING} =""
    RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
    RewriteCond %{DOCUMENT_ROOT}/pfad zu/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html -f
    RewriteRule ^(.*) /pfad zu/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html [L]
</IfModule>
# END CACHIFY

.htaccess-Erweiterung für Websites, die sowohl unter http als auch https erreichbar sind: (https://gist.github.com/mcguffin/31f80070d631d56da23cefb4ef1b6649)

Hinweise zu .htaccess Anpassungen

  • Innerhalb der .htaccess besitzt die obige Erweiterung eine höhere Priorität und muss daher oberhalb der WordPress Rewrite-Regeln (markiert meist durch # BEGIN WordPress … # END WordPress) platziert werden.
  • Ist die Website nur über SSL/TLS erreichbar, so muss /wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html in /wp-content/cache/cachify/https-%{HTTP_HOST}%{REQUEST_URI}index.html abgeändert werden.
  • Einige (wenige) Hoster (domainFACTORY und 1und1 gehören dazu) stellen die Apache-Variable %{DOCUMENT_ROOT} nicht zur Verfügung. Das führt zu einem unvollständigen Datei-Pfad. In solchen Fällen bitte den Document-Pfad manuell (statt Variable) voranstellen, siehe Anleitung DOCUMENT_ROOT in .htaccess durch Serverpfad ersetzen.
  • Änderungen an der Datei .htaccess können nicht vorgenommen werden, wenn PHP als fcgi ausgeführt wird.
  • Kommt es teilweise zu fehlerhaften Weiterleitungen innerhalb des Blogs, so kann die Abschaltung des Apache Content Cache Abhilfe schaffen.
  • Ist in WordPress das WPTouch-Plugin (oder ein anderes Mobile-Plugin) installiert, müssen RewriteRules erweitert werden, siehe Gist.

Erweiterung der Nginx-Konfigurationsdatei (https://gist.github.com/sergejmueller/1939164#file-gistfile1-nginxconf)

## GZIP
gzip_static on;
 
## CHARSET
charset utf-8;
 
## INDEX LOCATION
location / {
    if ( $query_string ) {
        return 405;
    }
    if ( $request_method = POST ) {
        return 405;
    }
    if ( $request_uri ~ /wp-admin/ ) {
        return 405;
    }
    if ( $http_cookie ~ (wp-postpass|wordpress_logged_in|comment_author)_ ) {
        return 405;
    }

    error_page 405 = @nocache;

    try_files /wp-content/cache/cachify/https-${host}${uri}index.html /wp-content/cache/cachify/${host}${uri}index.html @nocache;
}
 
## NOCACHE LOCATION
location @nocache {
    try_files $uri $uri/ /index.php?$args;
}
 
## PROTECT CACHE
location ~ /wp-content/cache {
    internal;
}

Hinweise zu Nginx-Anpassungen

  • Bei Domains mit FQDN muss statt ${host} die Variable ${http_host} verwendet werden.

Allgemeine Hinweise zu Cachify HDD

  • Das HDD-Caching in Cachify kann nur bei aktivierten WordPress-Permalinks ausgewählt und genutzt werden. Ein Schrägstrich am Ende des Permalinks wird ebenfalls vorausgesetzt. Für Permalinks ohne Slash am Ende ist die Nutzung eines speziellen .htaccess-Snippets vonnöten. Der Snippet-Code ersetzt den oben vorgestellten .htaccess-Eintrag.
  • Befindet sich der Blog in einem Unterverzeichnis und die dazugehörige .htaccess außerhalb des Blog-Verzeichnisses, gehört der Pfad zum Cache-Ordner angepasst. Beispiele als Gist.
  • Aus technischen Gründen kann bei dieser Caching-Methode die Plugin-Einstellung Kein Cache-Aufbau durch angemeldete Benutzer nicht automatisch berücksichtigt werden. Soll in WordPress angemeldeten und kommentierenden Nutzern ebenfalls die Cache-Version der Blogseiten angezeigt werden, müssen die beiden Zeilen mit der Cookie-Abfrage (RewriteCond %{HTTP_COOKIE}) im obigen Code einkommentiert werden (Raute davor stellen). Die Option Kein Cache-Aufbau durch angemeldete Benutzer muss dennoch aktiviert bleiben.
  • Die eingestellte Cache-Gültigkeitsdauer kann nicht einbezogen werden. Muss der Cache-Bestand in bestimmten Zeitabständen geleert werden, so empfiehlt sich der Aufruf einer präparierten PHP-Datei per Cronjob.
  • Dadurch, dass Cachify HDD auf PHP verzichtet und die WordPress-Ausführung umgeht, können bei dieser Methode keine geplanten WordPress-Beiträge ausgeführt werden. Eine brauchbare Alternative wäre der Aufruf der WordPress-Datei wp-cron.php (zu lokalisieren im Hauptverzeichnis der WordPress-Instanz) mithilfe eines Server-Cronjobs (Hoster fragen) oder eines Dienstleisters wie z.B. cronjob.de.

Steuerung der Cache-Leerung bei Artikel-Updates

Bei der Aktualisierung von Artikeln kann die notwendige Cache-Leerung manuell beeinflusst werden. Autoren können die Entscheidung treffen, ob nach der Speicherung der Artikeländerung der komplette Cachify-Cache oder nur der Cache der betroffenen Seite entfernt werden soll – praktisch, wenn die getätigte Änderung nur die eine Seite betrifft und keinerlei (optische) Auswirkungen auf die restlichen Webseiten haben.

Cachify Publish-Status Cachify Cache-Status beim Update der Artikel

Verfügbare Optionen in der Auswahlbox:

  • Gesamtcache löschen – leert den gesamten Cachify-Cache
  • Seitencache löschen – entfernt lediglich den Cache des Artikels

Die Auswahl ist nur bei bereits veröffentlichten Artikeln, Seiten und Post Types zugänglich. Die zuletzt selektierte Option wird Benutzerabhängig gespeichert und beim nächsten Aufruf der Artikel-Bearbeitungsseite vorausgewählt.


Wissenswertes

Einige Zusatzinformationen für die Arbeit mit dem Caching-Plugin.

Cachify-Größe auf dem Dashboard Cachify Cache-Größe auf dem Dashboard


Nutzung des Browser-Cache

Auf Wunsch kann die HTML-Ausgabe der Blogseiten zusätzlich im Cache der Browser aufbewahrt werden – für einen frei wählbaren Zeitraum. Diese Technik eignet sich dann, wenn ein Projekt über wenig Dynamik verfügt (keine Kommentare, selten Artikel etc.). In solchen Fällen verfügt der Browser über eine lokale Kopie einer Blogseite, die nach definierter Zeit abläuft.

Für beispielsweise einen einstündigen Browser-Cache muss die .htaccess bzw. Nginx-Serverdatei wie abgebildet komplettiert werden:

Browser-Cache in .htaccess (Apache)

<IfModule mod_expires.c>
    <FilesMatch ".(html|html.gz)$">
        ExpiresActive On
        ExpiresDefault "access plus 1 hour"
    </FilesMatch>
</IfModule>

Browser-Cache bei Nginx (platziert zwischen error_page und try_files)

expires 1h;

Anpassung der robots.txt

Damit Google und andere Suchmaschinen den statischen Inhalt des Cache-Ordners nicht indexieren (führt sonst zum doppelten Content), sollte die im Hauptverzeichnis einer WordPress-Installation befindliche Datei robots.txt erweitert werden, indem der Pfad zum Ordner mit Cache-Dateien gesperrt (disallow) wird. Und so könnte eine robots.txt aussehen:

User-agent: *
Disallow: /wp-content/cache/cachify/
Allow: /

Cache-Leerung aus Drittanwendungen

Für den Fall, dass der Cachify Cache aus WordPress-Drittanwendungen geleert werden soll, stehen innerhalb des Plugins (ab Cachify 2.0.3) ausführbare Aktionen zur Verfügung:

if ( has_action('cachify_flush_cache') ) {
    do_action('cachify_flush_cache');
}

if ( has_action('cachify_remove_post_cache') ) {
    do_action('cachify_remove_post_cache', 123); // postID
}

Weiterführende Links mit Analysen


Sprungmarken

You can’t perform that action at this time.