Da der neue Server genug RAM für memcached übrig hat, habe ich das heute mal getestet. Dabei bin ich über 2 Probleme gestolpert.
memcached und ipv6
Memcached bindet sich standardmäßig nur an localhost-ipv4. Wenn der Server jedoch auch für ipv6 konfiguriert ist, kann das zu einem Fehler führen:
[error] 16246#16246: *42947 connect() failed (111: Connection refused) while connecting to upstream, client: 217.85.96.157, server: test.gettoweb.de, request: "GET / HTTP/1.1", upstream: "memcached://[::1]:11211", host: "test.gettoweb.de"
Daher müssen wir in der vHost den memcached-Connect auf IPv4 erzwingen. Dafür ändern wir:
memcached_pass localhost:11211;
zu
memcached_pass 127.0.0.1:11211;
In einem Kommentar hab ich gelesen, dass es keine gute Idee wäre, memcache an ipv6 zu binden, da diese IP immer auch öffentlich wäre. Hier müsste mit einer Firewall der Zugriff von extern geblockt werden. Das scheint auch der Grund zu sein, warum der Support für ipv6 nicht standardmäßig aktiviert ist.
404-Bug
Und dann ist da noch ein hässlicher 404 Bug. Dieser verhindert, dass eine Seite die nicht im Cache zu finden ist, über den PHP-Weg geschickt wird. Wir bekommen einfach eine 404-Seite. Um den Bug zu beheben ändern wir die nocache-Weiche:
error_page 405 = @nocache;
um den Fehler 404:
error_page 404 405 = @nocache;
Nun sollte Cachify laufen. Ob das auch so ist, sieht man im Quelltext Webseite ganz unten. Da sollte jetzt eine Cachify-Info zu sehen sein:
<!-- Cachify | http://cachify.de Memcached @ 01.11.2016 21:38:41 -->
hier jetzt der berichtigte vhost-Eintrag zum Kopieren:
## INDEX LOCATION
location / {
if ( $query_string ) {
return 405;
}
if ( $request_method = POST ) {
return 405;
}
if ( $request_uri ~ /wp-admin/ ) {
return 405;
}
if ( $http_cookie ~ (comment_author|wp-postpass|wordpress)_ ) {
return 405;
}
error_page 404 405 = @nocache;
default_type text/html;
add_header X-Powered-By Cachify;
set $memcached_key $http_host$uri;
memcached_pass 127.0.0.1:11211;
#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;
}
Es wird Zeit, das die Cachify-Webseite mal aktualisiert wird!
Cachify-Info fehlt und baut kein Cache auf
Und schon sind wir bei einem weiteren Bug. Firefox und Chrome-Browser zeigen die Cachify-Info im Quelltext nicht an. Der Opera-WebBrowser jedoch schon. Scheinbar tritt der Bug aber nur unter Ubuntu auf, denn unter Windows konnte ich das Phänomen gerade nicht beobachten. Hier saß das Problem eindeutig vor dem Rechner. Der „wordpress_test_cookie“-Cookie von Worpress verhindert zuverlässig, dass Cachify den Cache aufbaut. An diesem Cookie erkennt Cachify „eingeloggte Nutzer“ Genau das habe ich natürlich in den Einstellungen auch aktiviert. Dumm nur, dass das Cookie nach dem abmelden nicht gelöscht wird. Der Cache wird dann natürlich weiterhin nicht aufgebaut.
weiteres Optimierungspotential js
Jetzt bleibt eigentlich nur noch die Optimierung der js-Datein übrig. Da ist die Ladezeit noch deutlich zu hoch.
Update: da habe ich noch ein Fehler berichtigen können:
Hier habe ich den Eintrag in der nginx.con gzip_types = um „application/javascript“ erweitert. Jetzt wird auch das javaScript mit gzip komprimiert ausgeliefert.