{"id":1834,"date":"2012-09-27T22:13:03","date_gmt":"2012-09-27T22:13:03","guid":{"rendered":"http:\/\/www.ollmetzer.com\/?p=1834"},"modified":"2013-05-20T10:10:13","modified_gmt":"2013-05-20T10:10:13","slug":"schnell-schneller-noch-schneller","status":"publish","type":"post","link":"https:\/\/www.ollmetzer.com\/?p=1834","title":{"rendered":"Schnell, schneller, noch schneller !!!"},"content":{"rendered":"

Ich war eben in Hamburg um Marco zu treffen. Marco ist als Webentwickler in San Francisco t\u00e4tig und gerade f\u00fcr kurze Zeit in Deutschland zu Besuch. Wir kennen uns seit zw\u00f6lf Jahren und sind beide seit geraumer Zeit f\u00fcr grosse E-Commerce Websites zust\u00e4ndig. Er im Bereich Publishing und Buchungssysteme und ich f\u00fcr Onlineshops. Den halben Nachmittag haben wir unter anderem f\u00fcr einen Erfahrungsaustausch genutzt. Obwohl „unsere“ Systeme v\u00f6llig unterschiedlich sind, \u00e4hneln sich die Herausforderungen, mit denen wir konfrontiert werden. Zwei der wichtigsten Kriterien sind Belastbarkeit mit vielen Besuchern und Transaktionen sowie Geschwindigkeit.<\/p>\n

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\u00f6nnen 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\u00fchrt, die in Summe wirklich sehr viel gebracht haben.<\/p>\n

Im Groben gibt es drei Bereiche, die f\u00fcr die Geschwindigkeit der Website verantwortlich sind:<\/p>\n

    \n
  1. Der Client<\/strong>
    \nLetztlich z\u00e4hlt, 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\u00f6glichst wenig M\u00fche mit dem Rendern hat. Stichworte sind: Weniger komplexe Seiten, Reduzierung der Requests, mehr parallele Downloads.<\/li>\n
  2. Das Netzwerk<\/strong>
    \nHiermit 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\u00fcgbarer Bandbreite achten. Wenn die Zielm\u00e4rkte global verteilt sind, sollte die Nutzung eines spezialisierten Content Delivery Networks in Erw\u00e4gung gezogen werden.<\/li>\n
  3. Die Systemarchitektur<\/strong>
    \nWie baut man ein komplexes Setup aus unterschiedlichen Servern und Netzwerkger\u00e4ten im Rechenzentrum um die Inhalte m\u00f6glichst schnell ausliefern zu k\u00f6nnen? Genau das war der Schwerpunkt unseres Erfahrungsaustauschs.<\/li>\n<\/ol>\n

    Interessanterweise sahen wir beide einige der momentan angesagten Methoden zur Realisierung von E-Commerce Sytemen eher etwas kritisch. Wir sind zum Beispiel beide f\u00fcr m\u00f6glichst schlanke Systeme zu haben, weil diese sowohl Ressourcen sparen, als auch Geschwindigkeit bringen.<\/p>\n

    Problembereich Frameworks<\/strong><\/p>\n

    Komplexe Frameworks f\u00fcr eCommerce Systeme, auf die potentiell unbegrenzt viele Nutzer zugreifen k\u00f6nnen, sind unter den Aspekten Geschwindigkeit und Ressourcen eher schwierig. Zumal die Erfahrung zeigt, dass die damit beabsichtigte Beschleunigung von Entwicklungszyklen in der Realit\u00e4t oftmals nicht eintritt. Teilweise wird die Entwicklung sogar langsamer und fehleranf\u00e4lliger.<\/p>\n

    Cache as cache can<\/strong><\/p>\n

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

    Im eCommerce Umfeld macht aber genau die daraus resultierende geringe Flexibilit\u00e4t Probleme, wie ich am Beispiel einer Kategorieseite eines Onlineshops erl\u00e4utern m\u00f6chte.<\/p>\n

    Problemfeld Caching \u2013 ein einfaches Beispiel<\/strong><\/p>\n

    Eine Kategorieseite besteht aus vielen Elementen, die erst aus der Datenbank zusammengesucht und dann zusammengebaut werden m\u00fcssen. 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.<\/p>\n

    Um solch eine Seite aufzubauen k\u00f6nnen durchaus hunderte einzelne Datenbankabfragen n\u00f6tig sein. Klar, das sowas dauert. Die Seite nur einmal zusammenzubauen und dann immer wieder fertig auszuliefern ist doch toll, oder?<\/p>\n

    Darauf kann ich nur mit einem beherzten \u201ejein<\/em>\u201c antworten. Die Seiten werden aus dem Cache teilweise 5-10 mal schneller ausgeliefert und belasten die Applicationserver nicht mehr. So weit so toll.<\/p>\n

    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\u00e4t, Beliebtheit oder sonstwas, auf- oder absteigend) \u00e4ndert oder sogar Filter setzt, greift das tolle Caching nicht mehr, weil man derart viele m\u00f6gliche Seiten nicht mehr sinnvoll vorhalten kann.<\/p>\n

    Ein weiteres Problem ist die Invalidierung der gecachten Seiten. In einem hochdynamischen System m\u00fcssen die erzeugten Seiten genauso schnell gel\u00f6scht und neu erzeugt werden, wie sich die zugrundeliegenden Daten \u00e4ndern. Ansonsten bekommt der Nutzer unentwegt veraltete und inkonsistente Daten angezeigt, wie z.B. Artikel, die gerade ausverkauft wurden.<\/p>\n

    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\u00e4ndert hat.<\/p>\n

    Dieses noch recht einfache Beispiel zeigt bereits viele potentielle Fehlerquellen. Hinzu kommt, dass sich personalisierte Seiten, die individuell f\u00fcr den Nutzer zusammengebaut werden, prinzipiell \u00fcberhaupt nicht cachen lassen. Von Problemf\u00e4llen wie mitgef\u00fchrten Sessions (Warenk\u00f6rben, personalisierten Einstellungen, Logins, Kampagnentracking) und so weiter ganz zu schweigen. Alles l\u00f6sbar, aber bei weitem nicht trivial und zum Teil hebelt man damit den Geschwindigkeitsvorteil des Full Page Caches wieder aus.<\/p>\n

    Less is more<\/strong><\/p>\n

    Bleibt die Frage offen „…und wie bekommen wir das Ding nun schnell?“
    \nPlatt gesagt durch Weglassen und Datenoptimierung.<\/p>\n