Schnell, schneller, noch schneller !!!

Ich war eben in Hamburg um Marco zu treffen. Marco ist als Webentwickler in San Francisco tätig und gerade für kurze Zeit in Deutschland zu Besuch. Wir kennen uns seit zwölf Jahren und sind beide seit geraumer Zeit für grosse E-Commerce Websites zuständig. Er im Bereich Publishing und Buchungssysteme und ich für Onlineshops. Den halben Nachmittag haben wir unter anderem für einen Erfahrungsaustausch genutzt. Obwohl “unsere” Systeme völlig unterschiedlich sind, ähneln sich die Herausforderungen, mit denen wir konfrontiert werden. Zwei der wichtigsten Kriterien sind Belastbarkeit mit vielen Besuchern und Transaktionen sowie Geschwindigkeit.

Zeit ist Geld. Nutzer warten nicht gerne. Ist die Website zu langsam, ziehen sie weiter. Google straft seit einiger Zeit ebenfalls Seiten im Pagerank ab, die langsam laden. Daraus folgern nochmals weniger Besucher. Wenige Zehntelsekunden können auf diese Weise durchaus einige tausend Euro ausmachen. Es lohnt sich also, Zeit und Geld in die Beschleunigung der Website zu investieren. Wir haben in unserer Firma in den letzten zehn Monaten sehr viele kleine und grosse Massnahmen zur Beschleunigung der Shops durchgeführt, die in Summe wirklich sehr viel gebracht haben.

Im Groben gibt es drei Bereiche, die für die Geschwindigkeit der Website verantwortlich sind:

1. Der Client
   Letztlich zählt, wie schnell der Browser des Nutzers reagiert. Es geht also um die Zeit zwischen Klick und fertiger Seite. Gegen langsame Rechner und Browser kann man als Websitebetreiber nichts machen. Aber man kann die Seiten so ausliefern, dass der Browser möglichst wenig Mühe mit dem Rendern hat. Stichworte sind: Weniger komplexe Seiten, Reduzierung der Requests, mehr parallele Downloads.
2. Das Netzwerk
   Hiermit ist alles zwischen Rechenzentrum und Nutzer gemeint. Hier hat man als Betreiber jedoch wenig Einfluss. Bei der Auswahl des Rechenzentrums sollte man auf redundante Anbindung aller relevanten Backbones und ausreichend verfügbarer Bandbreite achten. Wenn die Zielmärkte global verteilt sind, sollte die Nutzung eines spezialisierten Content Delivery Networks in Erwägung gezogen werden.
3. Die Systemarchitektur
   Wie baut man ein komplexes Setup aus unterschiedlichen Servern und Netzwerkgeräten im Rechenzentrum um die Inhalte möglichst schnell ausliefern zu können? Genau das war der Schwerpunkt unseres Erfahrungsaustauschs.

Interessanterweise sahen wir beide einige der momentan angesagten Methoden zur Realisierung von E-Commerce Sytemen eher etwas kritisch. Wir sind zum Beispiel beide für möglichst schlanke Systeme zu haben, weil diese sowohl Ressourcen sparen, als auch Geschwindigkeit bringen.

Problembereich Frameworks

Komplexe Frameworks für eCommerce Systeme, auf die potentiell unbegrenzt viele Nutzer zugreifen können, sind unter den Aspekten Geschwindigkeit und Ressourcen eher schwierig. Zumal die Erfahrung zeigt, dass die damit beabsichtigte Beschleunigung von Entwicklungszyklen in der Realität oftmals nicht eintritt. Teilweise wird die Entwicklung sogar langsamer und fehleranfälliger.

Cache as cache can

Auch der gerade sehr angesagte Einsatz von Full-Page Caches hat nicht nur Vorteile. Bei Publikationen (Onlinemagazine o.ä.) sind sie voll in ihrem Element, können enorme Geschwindigkeitsvorteile bringen und die Content Management System entlasten. Ihre Geschwindigkeit kommt daher, dass sie fertige Seiten vorhalten und ohne grosse Verzögerung an jeden Nutzer ausliefern können.

Im eCommerce Umfeld macht aber genau die daraus resultierende geringe Flexibilität Probleme, wie ich am Beispiel einer Kategorieseite eines Onlineshops erläutern möchte.

Problemfeld Caching – ein einfaches Beispiel

Eine Kategorieseite besteht aus vielen Elementen, die erst aus der Datenbank zusammengesucht und dann zusammengebaut werden müssen. Die Daten der Produkte, die in der Kategorie sind und der aktuellen Seitenzahl entsprechen, weitere Daten zur Kategorie selber (Titel, Beschreibungen, Links auf Headergrafiken usw.) und weitere Elemente, wie Kategoriebaum, Breadcrumbnavigation usw.

Um solch eine Seite aufzubauen können durchaus hunderte einzelne Datenbankabfragen nötig sein. Klar, das sowas dauert. Die Seite nur einmal zusammenzubauen und dann immer wieder fertig auszuliefern ist doch toll, oder?

Darauf kann ich nur mit einem beherzten „jein“ antworten. Die Seiten werden aus dem Cache teilweise 5-10 mal schneller ausgeliefert und belasten die Applicationserver nicht mehr. So weit so toll.

Das gilt allerdings nur, solange die Standardseiten angezeigt werden. Sobald der Nutzer die Anzahl der anzuzeigenden Artikel pro Seite oder die Sortierung (nach Preis, Aktualität, Beliebtheit oder sonstwas, auf- oder absteigend) ändert oder sogar Filter setzt, greift das tolle Caching nicht mehr, weil man derart viele mögliche Seiten nicht mehr sinnvoll vorhalten kann.

Ein weiteres Problem ist die Invalidierung der gecachten Seiten. In einem hochdynamischen System müssen die erzeugten Seiten genauso schnell gelöscht und neu erzeugt werden, wie sich die zugrundeliegenden Daten ändern. Ansonsten bekommt der Nutzer unentwegt veraltete und inkonsistente Daten angezeigt, wie z.B. Artikel, die gerade ausverkauft wurden.

Wenn z.B. ein Artikel, der auf der ersten von 50 Kategorieseiten steht, gerade ausverkauft wurde, muss nicht nur seine Detailseite aus dem Cache entfernt werden, sondern ausserdem 50 Kategorieseiten neu erzeugt werden; die erste, weil er dort nicht mehr enthalten sein darf, und die 49 folgenden, weil sich die Position aller nachfolgenden Artikel geändert hat.

Dieses noch recht einfache Beispiel zeigt bereits viele potentielle Fehlerquellen. Hinzu kommt, dass sich personalisierte Seiten, die individuell für den Nutzer zusammengebaut werden, prinzipiell überhaupt nicht cachen lassen. Von Problemfällen wie mitgeführten Sessions (Warenkörben, personalisierten Einstellungen, Logins, Kampagnentracking) und so weiter ganz zu schweigen. Alles lösbar, aber bei weitem nicht trivial und zum Teil hebelt man damit den Geschwindigkeitsvorteil des Full Page Caches wieder aus.

Less is more

Bleibt die Frage offen “…und wie bekommen wir das Ding nun schnell?”
Platt gesagt durch Weglassen und Datenoptimierung.

• Full Page Caches sind toll für Publikationen, aber problematisch bei Transaktionssystemen. Nehmen wir diesen Komplexitätslayer lieber aus dem System raus.
• Optimieren wir stattdessen den Applicationserver. Die verwendeten Frameworks müssen schlank und schnell sein. Wenn für die Initialisierung der Anwendung mit Konfiguration und Aufbau der Datenbankverbindung schon 200ms draufgehen, brauchen wir gar nicht erst weitermachen.
• Pro anzuzeigender Seite dürfen nur wenige und einfache Datenbankabfragen nötig sein. Es kann sinnvoll sein, hochgradig normalisierte Datenstrukturen für die Anzeige zu Flattables zusammenzufassen.

Der Erfolg eines solchen Vorgehens ist spürbar. Marco meinte zu einem Kunden, der den Einsatz eines Full-Page-Chaches anregte, sinngemäss:

„Die Seite in 200 Millisekunden fertig. Was willst Du da noch beschleunigen?“

Nebenbei sei bemerkt, dass dieses System nicht nur pfeilschnell ist, sondern zudem mit sehr wenig Hardware betrieben wird.

Und? Wie ist Euer Shopsystem so? ;-)