OXID-Setups bisher

OXID-Shops bestehen bisher oftmals aus mehreren PHP-Applikation-Servern und – jetzt kommt der Knackpunkt – einem Datenbank-Server.

Warum nur ein Datenbank-Server?

Leider unterstützt OXID nativ nur eine Datenbank. Für viele kleine Shops reicht das völlig aus. Bei unseren Zöglingen jedoch wird die Datenbank zum Bottleneck. Wenn die Datenbank überlastet ist, helfen auch keine weiteren Applikation-Server mehr. Der einzige Ausweg ist dann ein größerer Datenbank-Server. Aber was, wenn es keinen größeren Server mehr gibt? Mehr als 24 CPU-Kerne gibt es heute nun mal nicht zu kaufen. Wem also der größte Datenbankserver nicht ausreicht, muss erfinderisch werden. In der Version 5.0 wird OXID dieses Problem angehen, wir freuen uns schon sehr auf diese Änderung. Für alle Performancehungrigen, die nicht bis dahin warten können (oder wollen), haben wir bereits heute eine Lösung!

Zukünftige OXID-Setups bei SysEleven

Durch eine SysEleven-Erweiterung in OXID können Datenbankanfragen des Shops nunmehr auf mehrere Server verteilt werden. Für die Echtzeit-Synchronisation der Datenbank-Server nutzen wir das altbekannte MySQL-Feature “Master-Slave-Replikation”.

In dem hier dargestellten Setup werden die Anfragen von zwei Datenbank-Servern abgearbeitet. Dadurch erhöhen wir die Gesamtkapazität (nicht die Geschwindigkeit) des Shops und kommen dem horizontalen Skalieren wieder einen Schritt näher. Einziger Nachteil der Master-Slave-Replikation ist, dass man in der Slave-Datenbank nur lesen darf (read only), Änderungen der Daten müssen immer auf dem Master erfolgen.

Wie viel bringt es?

In einer Referenzmessung konnten wir die CPU-Belastung im Datenbank-Master auf die Hälfte reduzieren, sobald Abfragen auch vom Slave abgearbeitet wurden.

Je besser die Last verteilt werden kann, umso höher ist die Kapazität des Shops, d.h. umso mehr gleichzeitige Besucher können bedient werden. Wem die zusätzliche Power von einem Datenbank-Slave nicht ausreicht, kann einfach mehrere Slaves verwenden.

Welche Queries werden auf die Slaves ausgelagert?

Wie bereits erwähnt, dürfen die Slaves nur lesen und keine Daten verändern. Zudem gibt es Queries, z.B. während des Bestellprozesses, die zwingend auf dem Master ausgeführt werden sollten. Wir müssen also aufpassen, welche Queries wir vom Master und welche von den Slaves verarbeiten lassen. Üblicherweise unterscheidet man an dieser Stelle ganz simpel zwischen lesenden (select) und schreibenden (insert, update, delete, replace) Queries. Das reicht uns jedoch nicht: Wir wollen keine gleichmäßige Verteilung, sondern den bestmöglichen Performancegewinn. Um das zu realisieren, ist es entscheidend, die richtigen Queries auf die Slaves auszulagern. Eine Query, die beispielsweise nur 5% der gesamten MySQL-Rechenzeit ausmacht, kann gerne auf dem Master bleiben, wenn dafür eine andere Query, die für 30% der Rechenzeit verantwortlich ist, verteilt werden kann. Wir suchen also die “teuren” Queries! Dazu erstellen wir ein individuelles MySQL-Profiling für Ihren Shop und ermitteln die 5 oder 10 “teuersten” Queries. Meistens machen diese Queries summiert mehr als 70% oder 80% der gesamten MySQL-Rechenzeit aus.

Wann bekommt Ihr OXID-Shop den SysEleven-Faktor?

Mach Dein Büro zur Rennstrecke!

Wir haben ein iPhone auf unseren RC Buggy geschnallt und damit ein paar Runden durchs Büro gedreht. Mit einigen Hindernissen und einem “Feature” auf der Rennstrecke haben wir den Schwierigkeitsgrad erhöht. ;-)

SysEleven-Büro-Befahrung

Outtakes

Mach mit!

Wenn Ihr Lust habt, dann macht doch einfach mit. Es ist simpel und macht sehr viel Spaß. Postet Eure Videos auf facebook.com/SysEleven oder schickt uns einen Link zum Video.

Wir bei SysEleven tun alles dafür, um Euch Shopbetreibern während dieser Zeit zumindest eine Sorge abzunehmen. Die Arbeitsteilung ist dabei ganz simpel: Ihr konzentriert Euch auf das Business, wir kümmern uns um die Server. In der SysEleven Private Cloud können wir jedem Server während des Betriebs mehr Power geben, damit wir ruckelfrei durchs Weihnachtsgeschäft kommen.

Die Erleichterung wird sofort sichtbar, so sehen glückliche Server aus:

Im Namen des gesamtem SysEleven-Teams wünsche ich Euch allen eine erfolgreiche und sorgenfreie Weihnachtszeit. Und jetzt keine Blogs mehr lesen, sondern ab an die Arbeit, die Kunden warten auf die Pakete.

Der Vollständigkeit halber möchte ich darauf hinweisen, dass es sich bei diesen Maßnahmen um die Optimierung der Renderzeit handelt. Damit ist die Zeit gemeint, die der Browser benötigt, um eine Seite vollständig, also inklusive aller Elemente, Bilder, Javascript usw. darzustellen. Es geht hierbei explizit nicht um die Zeit, die der Webserver benötigt um z.B. Datenbankabfragen auszuführen. Die Pagespeed-Regeln gelten ab dem Zeitpunkt, an dem der Webserver den HTML-Quellcode der Seite an den Browser übertragen hat.

Wie viel bringt es?

Bevor man sich die Mühe macht 31 Regeln anzuwenden, lohnt sich eine Schätzung wie viel mehr Geschwindigkeit überhaupt erreichbar ist. Das kostenlose Online-Tool “Webpagetest” bietet eine sehr ausführliche und besonders ansehnliche Vorschau auf den möglichen Geschwindigkeitsgewinn:

Für Eure Webseite könnt Ihr diesen Test hier ausführen.

So einfach ist das?

Wenn ich mich an die Regeln halte, wird meine Webseite schneller. So einfach ist das. Das heißt aber leider nicht, dass auch die Umsetzung einfach ist. Einige der Regeln sind recht anspruchsvoll, die Umsetzung ist aufwendig und wird Zeit und Geld kosten.

Automatische Anwendung der Pagespeed-Regeln

Jetzt kommt der spannende Teil dieses Blogposts: Es gibt ein kostenloses Webserver-Modul, dass die wichtigsten der Pagespeed-Regeln automagisch automatisch anwendet. Die Seite muss dafür nicht verändert werden. Oder mit anderen Worten: Es kostet weder Zeit noch Geld. ;-) Das Modul gibt es derzeit für Apache und heißt “mod_pagespeed”. Ich habe die Entwickler ein wenig ausgefragt und erfahren, dass bereits über 70.000 Webseiten dieses Modul benutzen. Dabei ist zu beachten, dass “mod_pagespeed” nicht mit jeder Webseite kompatibel ist. Die Quote liegt jedoch derzeit bei nur knapp 2%.

Los geht‘s

SysEleven hat “mod_pagespeed” getestet und unterstützt es ab sofort. Wir freuen uns darauf mit Euch zusammen auszuprobieren, wie viel schneller Eure Webseite noch werden kann.

Phase 1: Umzug auf ein stabiles und skalierbares Hosting-Konzept

In dieser Phase installieren wir Ihre Webseite ohne Änderungen auf den SysEleven Systemen. Das primäre Ziel in dieser Phase ist die Stabilisierung der aktuellen, noch nicht verbesserten Performance der Seite. Das bedeutet, dass die Geschwindigkeit auch bei Peaks konstant bleibt.

In dieser Grafik ist die Ladezeit einer Webseite dargestellt. Vor dem Umzug sieht man die übliche Berg- und Talfahrt. Je nachdem ob es grad viele oder wenige Besucher gab, war die Seite schnell oder entsprechend langsam. Seit dem Umzug ist die Ladezeit annähernd konstant.

Phase 2:Verbesserung der Geschwindigkeit

Sobald wir die Performance Ihrer Webseite stabilisiert haben, kümmern wir uns in der zweiten Phase um die Verbesserung der Ladezeiten. Hierfür ermitteln wir mit unseren Monitoring-Tools Performance-Messwerte während des Live-Betriebs. In der Regel erstellen wir in dieser Phase ein detailliertes Performance Profil Ihrer Webseite. Die daraus gewonnen Erkenntnisse bilden die Grundlage für unsere Verbesserungsvorschläge. Daraus resultiert ein konkreter Maßnahmenkatalog, der je nach Art der jeweiligen Aufgabe von uns oder in enger Zusammenarbeit von Ihrer Agentur oder Ihren Entwicklern umgesetzt wird.

Diese Grafik veranschaulicht die zweite Phase des Umzugs zu SysEleven anhand eines konkreten Beispiels: Die Ladezeit lag vor der Umsetzung der von uns vorgeschlagenen Maßnahmen bei durchschnittlich einer Sekunde und konnte auf unter 0,2 Sekunden verbessert werden.

Wann bekommt Ihre Webseite den SysEleven-Faktor?

Wirkungsweise

Der OXID Super Cache wird vor die eigentlichen Shop-Server geschaltet und kann dort einen wesentlichen Teil des Traffics abfangen und beschleunigen. Die Lastverteilung und Wirkungsweise ist in den beiden folgenden Grafiken dargestellt.

Alle Anfragen an den Shop werden von PHP und MySQL bearbeitet und bei jedem einzelnen Seitenaufruf aufs Neue berechnet, zusammengebaut und zum Schluss ausgegeben. Web- und Datenbankserver sind ständig belastet.

Der OXID Super Cache speichert das fertige HTML und liefert es ab dem zweiten Aufruf derselben Seite direkt aus. Nur noch ein Bruchteil der Anfragen schlagen auf Web- und Datenbank-Server durch. Das entlastet die Systeme und sorgt für mehr Performance und steigert die Kapazität.

Zahlen und Fakten

Durch den OXID Super Cache werden die Server nicht nur entlastet, der Cache ist auch sehr viel performanter als ein Webserver und kann die Seiten um ein Vielfaches schneller ausliefern. Die spezielle Abstimmung auf höchste Performance macht den Super Cache sogar noch schneller als den OXID Dynamic Content Cache in der Enterprise Edition.

Durch den Einsatz des OXID Super Caches können Sie die Seitenladezeit auf ca. 0,1 Sekunde verringern. Dieser Wert wird hauptsächlich durch die Geschwindigkeit der DSL-Verbindung begrenzt, direkt am Cache gemessen beträgt die Seitenladezeit sogar nur 0,01 Sekunde.

Alle Seitenaufrufe, die direkt vom Super Cache ausgeliefert werden, verursachen keine einzige Abfrage in der Datenbank.

Der Super Cache ist auf hohen Durchsatz optimiert und kann im Vergleich zu Webservern ein Vielfaches an Seiten pro Sekunde ausliefern. Das ist besonders wichtig bei High-Traffic-Kampagnen wie zum Beispiel TV-Werbung, sehr großen Newsletter-Verteilern oder Ein-Tages-Gutscheinaktionen.

Wie viel bringt der Super Cache?

Die folgende Grafik zeigt die Erfolgsquote des Cachings bei einem unserer Kunden. 64% aller Seitenaufrufe werden aus dem Cache ausgeliefert. Das bedeutet, mehr als die Hälfte aller Zugriffe sind rasend schnell und verursachen keine Last auf den Servern. Die Shop-Server müssen sich nur noch um die Hälfte der Zugriffe kümmern.

Intelligentes Caching

Die Idee einzelne Elemente nicht jedes mal neu zu berechnen, sondern zwischenzuspeichern ist nicht neu. Ganz im Gegenteil, simples Caching kann heutzutage fast jede Software. Das besondere am OXID Super Cache ist die intelligente Cacheverwaltung. Wenn sich ein Artikel ändert oder ausverkauft ist, werden automatisch alle Seiten aus dem Cache entfernt, auf denen der Artikel zu sehen ist. Dadurch sind Sie nicht mehr wie bisher üblich an Cache-Laufzeiten gebunden, sondern Änderungen werden sofort sichtbar.

Referenz-Installation

Überzeugen Sie sich selbst von der Performance des OXID Super Cache. Bei unserem Kunden http://www.schuhtempel24.de/ können Sie ausprobieren wie schnell Ihr Shop sein könnte. Mit über 1 Million Seitenaufrufen pro Tag zählt Schuhtempel24 zu den High-Traffic OXID Installationen. Unser Super Cache macht den Shop schneller als die Konkurrenz erlaubt.

Im heutigen Teil dieser Reihe geht es um die Steigerung der Performance von Webseiten oder E-Commerce Shops. Manche unserer Kunden nennen das „Serverpower“ oder gerne auch „Vollgas Hosting“. Und da haben wir auch schon das Missverständnis: Natürlich gehören zu einer schnellen Webseite auch schnelle Server – aber nicht nur. Die Performance der Software ist ebenso wichtig. Die besten und schnellsten Server machen Ihre Webseite nicht schneller, wenn die Software mit angezogener Handbremse fährt – und umgekehrt genauso.

Die Performance einer Webseite wird durch das schwächste Glied der Kette bestimmt und nicht etwa durch die schnellste Komponente des Setups, wie viele irrtümlich glauben.

Die erste und wichtigste Teilaufgabe bei der Optimierung von Webperformance lautet also: Finde das schwächste Glied der Kette. Fachleute nennen das den Flaschenhals bzw. das Bottleneck. Je mehr Änderungen es beispielsweise an einem Online-Shop gab und je mehr Köche den Brei gerührt haben, umso komplexer und schwieriger wird die Suche nach dem Bottleneck. Erschwerend kommt hinzu, dass es laut unserer Erfahrung im Grunde nie ein einzelnes, sichtbares Bottleneck gibt. Meistens finden wir eine Verkettung „unglücklicher Umstände“ und „gewachsener Strukturen“, die gemeinsam die Performance in den Keller ziehen. Nicht selten finden wir sogar Features, die schon lange nicht mehr benutzt werden, aber immer noch aktiv sind und Last erzeugen.

Was ist das Ziel?

Das Ziel des Performance-Profilings ist die Identifikation der Bottlenecks. Als Ergebnis dieser Analyse sollte ein Maßnahmenkatalog mit konkreten Verbesserungsvorschlägen und Aufgaben vorliegen. Im Übrigen gehört zum SysEleven Faktor auch, dass es an dieser Stelle eine strikte Trennung gibt: Wir helfen dabei die Bottlenecks zu finden und liefern eine Anleitung wie sie behoben werden können. Die hardware- bzw. serverseitige Umsetzung erfolgt direkt durch uns und die softwareseitige Umsetzung erfolgt durch die Agentur des Kunden bzw. durch die Entwickler, die das jeweilige Setup viel detaillierter kennen. Das beste Ergebnis lässt sich erzielen, wenn Hostinganbieter, Agentur und Entwickler zusammenarbeiten.

Wie finden wir die Bottlenecks?

Zunächst erfolgt eine Bestandsaufnahme: Server, Software, Versionsnummern, Konfigurationen, aktuelle Auslastung, Besonderheiten. Für die detaillierte Untersuchung der Performance unterteilen wir das Setup in zwei Kategorien: Komponenten und Seitentypen. Die einzelnen Komponenten etwa eines Shops sind die Shopsoftware (z.B. PHP), die Datenbank (z.B. MySQL) und externe Webservices (z.B. Suchanbieter). Jede dieser Komponenten kann Bottlenecks verursachen und wird deshalb einzeln analysiert und getestet. Im zweiten Schritt unterscheidet man zwischen verschieden Seitentypen, bei einem Shop sind das meist die Startseite, Kategorieseite, Produktseite und die Suche. Jeder dieser Seitentypen hat individuelle Funktionen und Anforderungen – und damit auch potentiell individuelle Bottlenecks.

Seitenladezeit

Einer der sichtbarsten Indikatoren für die Performance der Webseite ist die Seitenladezeit. Als Referenzwerte für eine spätere Erfolgsmessung wird die Ladezeit jedes Seitentyps einzeln gemessen:

Bottlenecks in MySQL finden

Bei der Analyse von MySQL unterscheiden wir im Wesentlichen zwischen zwei Arten von Last:

• Den Datenbankabfragen, die ein einzelner Aufruf eines Seitentyps verursacht.
• Der Gesamtauslastung aller Datenbankabfragen während des Livebetriebs.

Für jeden der ermittelten Seitentypen wird analysiert, welche Datenbankabfragen bei einem einzelnen Seitenaufruf ausgeführt werden. Die „teuersten“ Queries kommen auf die Merkliste für eine genauere Untersuchung. Ich habe schon so Einiges gesehen und bin dennoch immer wieder überrascht wie viele Datenbankabfragen von einem einzigen Seitenaufruf verursacht werden können. Mehrere Hundert sind hier leider keine Seltenheit! Da gibt es oft – ich formuliere es mal so – Verbesserungspotential. ;-)

In diesem Beispiel hat ein einzelner Aufruf der Startseite eines Online Shop 296 Datenbankabfragen verursacht, hier gibt es sicher den einen oder anderen Ansatzpunkt für eine genauere Untersuchung.

Die Gesamtbelastung der Datenbank wird untersucht, indem alle Datenbankabfragen, idealerweise während einer Lastspitze, in einem Logfile protokolliert werden. Aus diesem Logfile wird ein Query-Profil erstellt. Das ist eine nach Rechenzeit sortierte Liste ähnlicher Queries. Dabei ist die Verteilung der verbrauchten Rechenzeit relevant und nicht etwa die Ausführungszeit der einzelnen Queries. Dauert eine Abfrage beispielsweise sehr lange, wird aber nur selten ausgeführt, hat sie wenig Einfluss auf die Gesamtperformance. Uns interessiert also vielmehr, wieviel Anteil an der gesamten Datenbankrechenzeit auf ähnliche Queries entfallen.

Hier sieht man zum Beispiel, dass die obere Query (nur der Anfang ist dargestellt) 32,5% der gesamten MySQL-Rechenzeit ausgemacht hat. Diese Query ist somit unser Kandidat #1 auf dem Prüfstand ist. Ob es zusätzlich auch Queries gab, die 10 Sekunden gedauert haben, im Testzeitraum aber nur dreimal aufgerufen wurden, ist in der Gesamtbetrachtung der Performance unerheblich.

Zwischenstand

Bevor es an das PHP-Profiling geht, lohnt sich an dieser Stelle eine Zwischenrechnung, die für jeden der anfangs ermittelten Seitentypen einzeln angewendet wird:

Seitenladezeit – Summe der Zeit aller MySQL-Queries ≈ Ausführungszeit in PHP

Das Ergebnis entspricht nur sehr grob der PHP-Ausführungszeit, dennoch können wir den Wert an dieser Stelle als Entscheidungsgrundlage benutzen, ob sich jeder weitere Aufwand überhaupt noch lohnt oder ob die Bottlenecks bereits gefunden sind.

Bottlenecks in PHP finden

Für das Profiling in PHP gelten im Grunde dieselben Regeln wie für MySQL. Jeder Seitentyp wird einzeln untersucht. Auch hier ist besonders die Verteilung interessant. Welche Klasse oder Methode verursacht wie viel Prozent der gesamten Ausführungszeit?

Fazit

Die Performance einer Webseite zu steigern ist einfach – wenn man vorher die tatsächlichen Bottlenecks gefunden hat. Sehr oft begegnen uns Projekte, bei denen alle möglichen Best-Practices angewendet wurden und die Seite dennoch unbefriedigend langsam ist. Kein Wunder, wenn an den echten Bottlenecks vorbei-optimiert wurde. Der Erfolg bleibt aus und der Frust ist groß. Ein detailliertes Performance-Profiling ist zwar sehr komplex und aufwendig, es rentiert sich aber sehr schnell durch echte Ergebnisse.

Wann bekommt Ihre Webseite den SysEleven Faktor?

SysEleven ist spezialisiert auf High-Performance-Webseiten und wir sind stolz auf jedes einzelne bei uns betreute Projekt. Wir freuen uns persönlich über jede neue Herausforderung. Derzeit liegt der Rekord bei 1440 MySQL Queries für einen einzigen Seitenaufruf.

Wer bietet mehr? ;-)

Nach fast 9 Jahren wurde es Zeit für eine Veränderung. Vor allem der steigende Platzbedarf hat uns dazu bewegt nach neuen, größeren Büroräumen zu suchen. Nach zahlreichen Besichtigungen fiel die Wahl auf das alte Umspannwerk in Kreuzberg. Vielleicht weniger zentral gelegen bietet es uns doch eine schöne und großzügige Fläche für all unsere aktuellen und zukünftigen Mitarbeiter.

Das Umspannwerk wurde 1924 bis 1928 erbaut. Es befindet sich direkt am Paul-Linke-Ufer.

Die Fassaden der Stahlskelettbauten wurden im expressionistischen Stil bzw. im Stil der Neuen Sachlichkeit gestaltet und mit buntglasierten Eisenklinkern versehen. Der seitliche Turmbau brachte dem Gebäude den Beinamen “Kathedrale der Elektrizität” ein.

Zur Jahrtausendwende wurde das Gebäude kernsaniert und enthält neben modernen Büroflächen auch eine loungige Bar im Souterrainbereich sowie eine Eventhalle.

Das Hosting für Fortgeschrittene operiert nun also aus der Ohlauer Str. 43 in 10999 Berlin Kreuzberg. Nahegelegene U-Bahnstationen sind die Schönleinstraße (U8) und der Görlitzer Bahnhof‎ (U1). Sie erreichen uns ab sofort unter der Telefonnummer 030/233 2012 -0. Der technische Support hat die Durchwahl 30.

PS: Du willst auch bei uns arbeiten? Bewirb Dich!

Zuordnung zu URLs

In der Prozessliste fehlt uns jedoch eine entscheidende Information: Welche URL hat diesen Prozess ausgelöst, der außergewöhnlich viel Arbeitsspeicher verbraucht? Was wir suchen ist eine Zuordnung zwischen dem Prozess und der im Browser aufgerufenen URL. Da alle Zugriffe auf die Webseite im Apache Logfile protokoliert werden, liegt Nahe an dieser Stelle anzusetzen.

Unser Ziel ist also, innerhalb der Applikation den maximal verbrauchten Arbeitsspeicher zu ermitteln und den Wert an Apache zu übergeben, damit dieser im Logfile protokoliert werden kann. Wir nutzen hierfür die beiden PHP Funktionen memory_get_peak_usage() und apache_note():

# get the maximum ram
$debug_ram = memory_get_peak_usage();

# make it visible to apache
apache_note("x-php-ram", $debug_ram);


Implementierung in die Applikation

Wir wollen natürlich nicht in der Applikation suchen, an wie vielen Stellen wir den Code einfügen müssen, damit wir bei jedem Aufruf den RAM-Verbrauch messen können. Für unsere Debugzwecke machen wir uns eine globale Funktion zu nutze: In der php.ini können wir definieren, dass am Ende von jedem PHP Aufruf zusätzlicher Code ausgeführt wird:


; Automatically add files
;auto_prepend_file =
auto_append_file = /var/www/x-php-ram.php


Implementierung in Apache

Um die Werte auch wirklich im Logfile zu sehen, verändern wir das Logfileformat in Apache:


LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" PHP-RAM: %{x-php-ram}n" combined_memory

CustomLog /var/log/apache2/access.log combined_memory


Ergebnis

Jetzt sehen wir wie viel Arbeitsspeicher jeder einzelne Aufruf einer Webseite verbraucht hat:


/ PHP-RAM: 91106128
/fotos/deutschland-besiegt-kanada PHP-RAM: 110486240
/page/hitfinder PHP-RAM: 81736024
/fotos/wetten-dass-abschied PHP-RAM: 96412776
/shows/schreckliche-urlaubsmode PHP-RAM: 98604800
/musik PHP-RAM: 95526032


In diesem konkreten Fall hat uns diese Debug-Information leider nicht weitergeholfen. Es gab keine Ausreißer, im Grunde haben alle Aufrufe ungewöhnlich viel Arbeitsspeicher verbraucht. In dieser Drupal-Installation sind sehr viele Module installiert, so dass tatsächlich viel RAM verbraucht wird. Durch den Einsatz von APC konnten wir letztendlich den RAM-Verbrauch auf die Hälfte reduzieren und das Problem entschärfen. Dazu aber mehr in einem anderen Blogpost…

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.