Lastverteilung

Als klassischer Loadbalancer wird Nginx an vorderster Front der Serverarchitektur eingesetzt und erhält somit alle eingehenden Anfragen der Webseitenbesucher. Die Verteilung auf die dahinter liegenden Anwendungsserver erfolgt im Rundlauf-Verfahren (Round Robin) oder unter Berücksichtigung von Parametern wie der Gewichtung.

upstream appserver {
  server app1.webseite.tld weight=5;
  server app2.webseite.tld weight=5;
}

location / {
  proxy_pass http://appserver;
}

Zwischenspeicherung

Die Anwendungsserver sind meist mit PHP-Modulen dick bepackt und haben daher einen großen Speicher-Fußabdruck. 20 bis 30 MB sind da keine Seltenheit. Der Nginx im Vergleich dazu hat meist nur rund 5 MB. Es macht daher Sinn vor allem statische Dateien wie Bilder, CSS und Javascripte für mind. 24 Stunden zwischenzuspeichern und die Anwendungsserver damit zu entlasten. Über die location-Anweisung kann gesteuert werden, welcher Teil der Webseite wie gecached werden soll.

proxy_cache_key $host$request_uri;
proxy_cache_path /var/www/cache/images  levels=1:2 keys_zone=images:500m;

location /images {
  proxy_cache images;
  proxy_cache_valid 24h;
  proxy_pass http://appserver;
}

Möchte man einen Eintrag im Zwischenspeicher vorzeitig löschen, etwa um eine neue CSS-Datei zu veröffentlichen, benutzt man entweder Versionsnummern, die an die URL per GET angehängt werden, oder das “ngx_cache_purge“-Modul und eine spezielle Lösch-URL nach dem Schema “http://www.webseite.tld/cache-purge/?url=www.webseite.tld/images/bild1.jpg”.

location ^~ /cache-purge/ {
  allow 127.0.0.1;
  deny all;
  proxy_cache_purge images $arg_url;
}

Auswertung

Um eine Hit Rate, also die Anzahl der Anfragen, die direkt aus dem Zwischenspeicher bedient werden konnten, im Verhältnis zur Summe aller Anfragen zu berechnen, sollte das Protokoll im Nginx aktiviert und weitere Infos ergänzt werden: Konnte die Anfrage aus dem Cache bedient werden? Welcher Anwendungsserver hat die Anfrage verarbeitet und wie lange hat er dafür benötigt.

log_format proxy '[$time_local] Cache: $upstream_cache_status $upstream_addr $upstream_response_time $status $bytes_sent $proxy_add_x_forwarded_for $request_uri';

access_log /var/log/nginx/webseite.tld.access_log proxy;

Nginx, Cache-Hits pro Sekunde

Schmankerl

Nutzt die Webseite SSL macht es Sinn auch diesen Prozess in den Proxy auszulagern. So entfällt auf allen Anwendungsserver die SSL-Konfiguration, das Laden des SSL-Moduls und natürlich auch der Aufwand durch die Aushandlung der SSL-Verbindung.

ssl on;
ssl_certificate /etc/ssl/private/webseite.tld.crt
ssl_certificate_key /etc/ssl/private/webseite.tld.key;

Die Komprimierung von Text-Dateien spart erheblich Übertragungszeit und Netzwerktraffic, belastet allerdings auch den Prozessor und sollte daher ebenfalls auf den Proxy ausgelagert werden. Denn dieser benötigt selbst kaum Rechenleistung.

gzip on
gzip_types text/plain application/xml;
gzip_disable "MSIE [1-6]\."

Nginx, CPU-Auswertung, 2x Xeon @ 2.33GHz

Fazit

Der Nginx hat sich als bei SysEleven als Proxy bewährt. Er ist robust und vielseitig konfigurierbar. Statische Dateien kann er leicht und effektiv zwischenspeichern und selbst ausliefern. Mit weiteren Modulen wie FastCGI, Memcached und SSI kann er zum wahren Multi-Talent werden. Doch dazu später mehr.

APC ist ein so genannter “Opcode Cache”. Die Aufgabe von APC ist es, sich den aufwendigen Kompiliervorgang für spätere Zugriffe zu merken, damit dieser nur einmal ausgeführt werden muss. Bei jedem weiteren Aufruf der Datei liegt diese bereits vorkompiliert im Arbeitsspeicher.

Wie viel schneller wird meine Webseite?

Als Beispiel habe ich die Performance einer unserer WordPress-Installationen gemessen. Mit dem Tool Apache Bench (alternativ http_load oder jmeter) kann man ermitteln wie oft eine Webseite in einem festgelegten Zeitraum aufgerufen werden kann. Daraus ergibt sich die Geschwindigkeit der Webseite in der Einheit “Aufrufe pro Sekunde” (Requests per second). Je höher diese Zahl, desto schneller ist die Webseite. Oder anders herum, desto mehr Anfragen können je Zeiteinheit bearbeitet werden.

Test 1: WordPress mit standard PHP

Test 2: WordPress mit aktiviertem APC

Ein Fazit

WordPress ist mit APC knapp viermal schneller als ohne. Aber: Wie viel schneller eine Webseite tatsächlich wird, hängt von der verwendeten Software ab. Wichtig: Nicht jede Software ist kompatibel zu APC, aber ein Versuch lohnt sich allemal.

Die Auslastung des Caches und die Erfolgsquote (Hits/Misses) ist, stellt APC in Diagrammen dar:

Alternativen

Neben APC gibt es noch eAccelerator und XCache. Performancemäßig nehmen die drei sich wenig, welche Software man einsetzt ist eher Geschmacksache bzw. eine Frage der Kompatibilität – was mit dem einen Cache nicht kompatibel ist, wird mit einem anderen vielleicht doch funktionieren. Das hartnäckige Gerücht, Zend Optmizer gehöre auch dazu, ist übrigens falsch. Zend Optimizer “optimiert” zwar den Quellcode, ist aber kein Cache und merkt sich diese Verbesserungen nicht. Im Gegenteil: Die gleiche Arbeit wird bei jedem Aufruf erneut ausgeführt. Aus Sicht der Performance ist das wenig förderlich, weil es durch die ständige Mehrarbeit die Ausführung von PHP sogar noch verlangsamen kann.

Links

http://de.php.net/manual/de/book.apc.php
http://www.zend.com/de/community/php
http://eaccelerator.net/
http://xcache.lighttpd.net/
http://httpd.apache.org/docs/2.2/programs/ab.html