Nginx: PHP-Alternative HHVM

Wer in Sachen Ausführungsgeschwindigkeit von PHP-Scripten weitere Optimierungen vornehmen will, stolpert früher oder später über HHVM – ein Just-in-Time-Compiler für PHP.

nginx_logoHHVM kann einfach über die Debian-Paketverwaltung installiert werden. Ist das erledigt, kann es im Prinzip wie php5-fpm verwendet werden. Die ganze restliche Konfiguration innerhalb von Nginx habe ich gelassen – dadurch lassen sich gute Vergleiche in Bezug auf die Performance anstellen:
Weiterlesen…

Pagespeed: WordPress in unter 1s laden (Nginx + HTTP/2)

Wer WordPress richtig schnell haben will, kommt ab einem gewissen Punkt mit gängigen Caching-Plugins nicht weiter. Nginx mit HTTP2 hilft weiter.

Seit der Version 1.9.5 unterstützt auch die Open-Source-Version von Nginx das HTTP/2-Protokoll direkt – eine mühsame Konfiguration bzw. das Verwenden von Patches ist damit nicht mehr nötig.

English Version below

Die HTTP/2-Implementierung läuft – zumindest bezogen auf einen Blog wie diesen – stabil und ohne weitere Auffälligkeiten. Der größte Vorteil: herausragende Seitenladezeiten. Um PHP nicht zu sehr zu fordern, verwende ich Microcaching. Dadurch sind die meisten Seiten bereits fertig erstellt und müssen nur noch an den Client ausgeliefert werden.
Weiterlesen…

Pagespeed: combine_css mit WordPress

Wer WordPress mit mod_pagespeed bzw. ngx_pagespeed verwendet und den Filter combine_css verwendet, wird feststellen, das nichts passiert. Was ist zu tun?

Der Grund für die Probleme: Das Pagespeed-Modul berücksichtigt keine CSS-Einbindungen, die unterschiedliche IDs haben. WordPress setzt den Namen des CSS als ID bei der Einbindung, am Ende sieht es dann so aus:

link rel='stylesheet' id='wp-pagenavi-css' href='/wp-content/plugins/wp-pagenavi/pagenavi-css.css?ver=2.70' type='text/css' media='all'/

Der Lösungsansatz: die ID sowie den dazugehörigen Wert entfernen. Dafür kann man eine entsprechende Funktion in der functions.php des Themes einbinden:

function remove_style_id($link) {
        return preg_replace("/id='.*-css'/", "", $link);
}
add_filter('style_loader_tag', 'remove_style_id');

Der Hintergrund: der Filter style_loader_tag beinhaltet die Einbindung, die Funktion remove_style_id macht nichts weiter als in der fertigen Ausgabe der CSS-Einbindung in WordPress die ID-Werte zu entfernen. Das „Problem“ besteht schon länger, auf Codecentric.de wurde dieser Lösungsansatz bereits 2011 beschrieben.

Insgesamt braucht man am Ende mit den funktionierenden combine_css das WordPress W3TC-Plugin nicht mehr: Caching wird via Microcaching direkt von Nginx gelöst, alle anderen Seitenoptimierungen erledigt das Pagespeed-Modul im Webserver. Dieser Blog läuft mit einer entsprechenden Konfiguration und erreicht damit sehr gute Speed-Index-Werte.

Pagespeed: Nginx + Memcached + PHP5-FPM

Nginx mit PHP5-FPM ist schon recht schnell, werden fertige Seiten mittels Memcached gespeichert lässt sich die Ladezeit noch weiter reduzieren. Die Umsetzung ist einfach.

Dieser Beitrag ist inspiriert von einer Anleitung auf 6tech.org und auf aktuelle Software-Versionen übertragen. Folgende Voraussetzungen müssen erfüllt sein, damit das Nginx-Setup von Memcached profitieren kann:

  1. nginx mit PHP5-FPM
  2. php5-memcached-Module installiert und aktiviert
  3. memcached muss installiert sein

Die Grundidee: statt der eigentlichen index.php wird ein Zwischenscript aufgerufen, welches den Aufruf an die eigentliche index.php weitergibt und das Ergebnis im Memcache ablegt. Dadurch erhält man auf einfachem Wege eine eine Caching-Lösung ähnlich des Plugins WP Supercache, bei der die die fertig erstellten Seiten hinterlegt werden. Dadurch ist im Falle eines Cache-Hits nur ein PHP-Aufruf nötig um das Memcache-Ergebnis auszuliefern – da die Daten im RAM abgelegt werden ist dies deutlich schneller als ein regulärer Aufruf.
Weiterlesen…

Nginx: GZIP aktivieren

Um die Datenübertragung zu beschleunigen und den Datentransfer zu minimieren sollte GZIP für JavaScript, CSS und HTML-Dateien aktiviert werden.

Per default ist Gzip nicht für alle relevanten Mimetypes aktiviert, sodass dies in der nginx.conf nachgeholt werden sollte (im http-Bereich hinzufügen):

gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_proxied any;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css text/xml application/x-javascript application/xml application/xml+rss text/javascript;
gzip_vary on;

Danach sollte Googles Pagespeed-Test eine deutliche Verbesserung zeigen – fehlende GZIP-Komprimierung wird dort nach wie vor als wirklich kritisches Problem eingestuft, welches nach aktiviertem Gzip besser wird. Mein nächster Plan: Cache-Zeiten via expires zu aktivieren, was derzeit bei diesem WordPress-Blog noch dazu führt, dass kein CSS mehr geladen wird.

Mehr zum Thema nginx und php gibt es im entsprechenden Blogpost. Nginx läuft mit GZIP problemlos und vollkommen stabil.

nginx + PHP unter Debian (+ W3TC)

nginx ist ein schneller Webserver, der sich auch als Reverse Proxy oder zum Streaming von Flash-Videos einsetzen lässt. Ursprünglich entwickelt für die Anforderungen einer russischen Suchmaschine setzen auch immer mehr Webprojekte auf nginx. Anders als beim bekannten Apache-Webserver ist die Konfiguration von nginx unter Debian nicht ganz so simpel – es müssen noch Dateien von hand angepasst werden. Dieser Beitrag beschreibt die Basis-Änderungen, die nötig sind, um PHP5 mit Xcache als FastCGI-Einbindung unter Debian zum laufen zu kriegen. Die gezeigten Einstellungen sollten immer an die eigene Umgebung angepasst werden.

Installation
Mit folgendem Befehl werden die passenden Pakete installiert:

apt-get install php5-cgi php5-xcache php5-mysql nginx

Der mysql-Server ist in unserem Fall auf einem anderen Server untergebracht, ansonsten müsste zusätzliche noch das entsprechende Paket installiert werden. Der nächste Schritt ist die Einrichtung des nginx, wir behaltet dort weitgehenden den Debian-Standard bei. Mit dem Befehlt

/etc/init.d/nginx start

wird überprüft ob die Konfiguration bis hier hin funktioniert und der Webserver korrekt startet.

Konfiguration

Ist dies der Fall, müssen noch einige Anpassungen an der PHP-Einstellung für den jeweiligen Host sein (der Default-Host wird in “/etc/nginx/sites-available/default” konfiguriert).

location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000; #php läuft auf Localhost, Port 9000
#fastcgi_index index.php; #wird für diese Konfiguration nicht benötigt
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name; #legt das Verzeichnis fest
include /etc/nginx/fastcgi_params;
}

In der fastcgi_params, die von Debian unter /etc/nginx angelegt wird, muss ebenfalls noch etwas geändert werden. Folgende Zeilen müssen auskommentiert werden:

#fastcgi_param SCRIPT_NAME $document_root$fastcgi_script_name;

Jetzt kann php-cgi alleine gestartet werden, um zu schauen ob alles funktioniert:

php-cgi -b 127.0.0.1:9000

Eine php-info-Datei in /var/www sollte jetzt Informationen zum installieren PHP zurückliefern. Gibt es die Meldung “no input file specified” stimmt noch etwas mit den Verzeichnissen nicht. Funktioniert alles, kann das php-cgi-Startscript aus dem Nginx-Wiki übernommen werden und Einstellungen am XCache etc. vorgenommen werden. auch sollten wie im Wiki beschrieben Upload-Verzeichnisse geschützt werden, damit dort kein PHP ausgeführt werden kann.

Demnächst geht es hier weiter mit Redirects unter Nginx und Klartext-URLs mit WordPress (wie sie dieser Blog auch schon verwendet).
Weiterlesen…