tiny little gizmos

Onlineshops – Geschwindigkeit versus Flexibilität.

Ladegeschwindigkeiten und Spitzenlastfähigkeit sind zunehmend wichtige Eigenschaften von Onlineshops. Gründe dafür sind steigende Besucherzahlen, Änderungen am Google Pagerank, nachweislich steigende Abbruchquoten bei längeren Ladezeiten und Lastspitzen z.B. durch Fernsehwerbung.

Need for speed

In den letzten 12 Monaten sind daher viele grosse und mittlere Onlineshops dazu übergegangen, Full-Page-Chaching einzusetzen. Der Erfolg der Bemühungen kann sich sehen lassen. Noch vor einiger Zeit waren Ladezeiten von 3-6 Sekunden für eine Kategorie- oder Artikeldetailseite eines durchschnittlichen Onlineshops normal. Anbieter, die bereits die Ladezeiten ihrer Shops optimiert haben verblüffen hingegen (falls es die eigene Internetanbindung hergibt) mit Ladezeiten von zum Teil unter 1,5 Sekunden – inklusive aller Bilder und Skripte wohlgemerkt. Die HTML Seite alleine ist meist schon nach 100ms ausgeliefert.

Ist nun also alles eitel Sonnenschein?

Nicht ganz. Es gibt im Leben nichts umsonst, wie meine Oma zu sagen pflegte. Die beeindruckende Steigerung der Geschwindigkeit wird mit anderen Einschränkungen erkauft. Stellen wir die Vor- und Nachteile doch einmal kurz gegenüber:

Shops ohne Full Page Cache Shops mit Full Page Cache
Vorteile
+ Dynamische Seitenerstellung ermöglicht jede denkbare Anpassung an Client, Herkunft, Marketing etc. 

+ Änderungen an Artikeln, Kategorien und Landingpages sind sofort online

+ Extrem schnell (für cachebare Seiten) 

+ Gesteigerte Skalierbarkeit

+ weniger Anfälligkeit für Lastspitzen

Nachteile
– Langsame Antwortzeiten 

– Hohe Systemlast

– Nur bestimmte Seitentypen sind cachebar 

– Die Invalidierung von Seiten kann komplex und fehleranfällig sein

– Gecachte Seiten sind nicht mehr personalisierbar

– Gecachte Seiten können nicht mehr serverseitig auf Geräteklassen angepasst werden

– Gecachte Seiten können nicht mehr serverseitig auf Marketingmassnahmen angepasst werden

– Gecachte taugen nicht zu serverseitigen multivariatem Testing

– Tools zur Erfolgsmessung von Marketingmassnahmen werden schwieriger

In der Gegenüberstellung wird deutlich, dass man sich den Geschwindigkeitszuwachs mit einer erheblichen Einschränkung der Flexibilität erkauft. Für einige Anbieter – Je nach Sortiment und Geschäftsmodell mag das unbedeutend sein. Für andere Anbieter ist dies jedoch eine empfindliche Einschränkung. Neue Geschäftsmodelle lassen sich so zudem ebenfalls nicht einführen.

Lösungen für die goldene Mitte

Zur Zeit gibt es nur Shops die entweder in die eine oder in die andere Richtung optimiert sind. Es fehlen jedoch Lösungen für die goldene Mitte: Shops, die flexibel sind und dennoch schnell. Der Bedarf dafür ist vorhanden, wie ich in einigen Gesprächen mit Shopbetreibern in letzter Zeit feststellen durfte. Was kann man nun tun?

Im Prinzip gibt es zwei Möglichkeiten, wie man das Ziel hoher Performance bei gleichzeitiger Flexibilität erreichen kann:

  • Herausnahme von Snippets mit variablem Inhalt aus der gecachten Seite
  • Ein geschwindigkeitsoptimierter Catalogserver.

Schauen wir uns bei Möglichkeiten etwas genauer an:

1.) Caching und Snippets

Wenn eine Seite nur deshalb nicht gecacht werden kann, weil sie ein oder zwei veränderliche Element enthält, bietet es sich an, diese Elemente als separates Snippet vom Caching auszunehmen. Ein Element, an dem das sehr deutlich wird, ist der Mini-Warenkorb, der heutzutage auf fast jeder Shopseite zu finden ist.

Sobald der Kunde etwas in den Warenkorb gelegt hat, ist dieser Bereich individuell. Somit kann für diesern Kunden quasi keine Seite mehr aus dem Cache bedient werden, obwohl sich der Rest auf den Seiten überhaupt nicht verändert hat.

Daher wird dieser Bereich als Snippet definiert. Das Caching System liefert weiterhin die Seite aus dem Speicher aus, ersetzt jedoch zuvor den Mini-Warenkorb Bereich per Server Side Include durch die individualisierten Code vom Application Server.

Vorteil: Der Anteil der direkt aus dem Cache auslieferbaren Seiten erhöht sich spürbar, Gesamtperformance und Systemlast sinken.

Nachteil: Durch die zusätzlichen Regeln wird das Caching komplizierter und langsamer. Falls mehrere Snippets pro Seite definiert werden, verringert sich die Performance signifikant durch mehrfache Abfrage des Application Servers und den damit verbundenen Overhead.

2.) Optimierter Catalogserver

Um wirkliche Flexibilität zurückzugewinnen, kommt man um einen optimierten Catalogserver nicht herum. Die Geschwindigkeit erreicht er durch konsequentes Weglassen und Datenoptimierung, wie ich bereits im Artikel „Schnell, schneller, noch schneller !!!“ schrieb.

Es sollte ein radikal reduziertes, geschwindigkeitsoptimiertes Framework zum Einsatz kommen. Normale Shopframeworks haben durch die maximale Flexibilität zuviel Overhead

Die Datenstrukturen müssen auf minimierte Suchzeiten optimiert werden. Flattables sind hier normalisierten Strukturen vorzuziehen. Hier ist zu prüfen, ob Key-Value Stores, wie z.B. Couchbase signifikante Vorteile gegenüber SQL haben.

Vorteil: Eine immer noch hohe Geschwindigkeit, bei hoher Flexibilität

Nachteil: Langsamer als echte Full Page Caches, eine Anpassung von Code und Daten an das Produkte und Geschäftsmodell ist nötig, die Einbindung des eigentlichen Shopsystems als Transaktionsserver bietet einige Hürden.

Der Blick in die nahe Zukunft

Beide Wege zur Performancesteigerung haben ihr für und wieder. Je nach Angebot und Geschäftsmodell kann der eine oder der andere Weg sinnvoller sein.

Beide Wege sind nicht ohne Stolpersteine und mit den gegenwärtigen Shopsystemen nicht out-of-the-box realisierbar. Der zunehmende Druck in der Branche zu performanten und dennoch flexiblen Lösungen wird jedoch dazu führen, dass die Herausforderungen angegangen werden. Daher erwarte ich in der nächsten Zeit verstärkte Bemühungen auf beiden Wegen.

Oxid Commons 2013 – das eCommerce Klassentreffen

In dieser Woche fand am 16. und 17. Mai die Oxid Commons 2013 statt, bei der ich auch wieder zugegen war. Bei der Anreise war ich zunächst ein wenig beleidigt. Normalerweise ist das Wetter unten in Baden ja immer etwas schöner, als bei uns im Norden, aber diesmal war es andersrum: Berlin hatte 25 Grad, Freiburg aber nur 12. Die erste Enttäuschung wurde jedoch schnell durch die Veranstaltung und die persönlichen Gespräche bei weitem wieder wett gemacht.

Freiburg - kalt und regnerisch

Freiburg - kalt und regnerisch

OXID Commons - Ausstellerbereich

OXID Commons - Ausstellerbereich

Mittlerweile fühlt sich die jährlich in Freiburg stattfindende Konferenz für mich wie eine Art Klassentreffen der eCommerce Szene an. Am Vorabend haben sich bereits viele Teilnehmer in der Innenstadt zu einem gemeinsamen Hallo und ausführlichen Plausch getroffen. Am Donnerstag ging es dann richtig zur Sache. Ich konnte drei thematische Schwerpunkte ausmachen, die die Branche momentan bewegen:

  • Das Miteinander von TV und Internet
  • Performance
  • Responsive Design

Das Internet ist in der Bevölkerung alltäglich geworden. Die veränderte Mediennutzung, die Fernsehen wie zuvor bereits das Radio quasi zum medialen Hintergrundrauschen degradiert, während man gleichzeitig auf dem „second Screen“ im Internet unterwegs ist, hat nun die breiten Massen erreicht. Treiber sind der Trend weg vom PC, hin zu diversen mobilen Endgeräten.

In mehreren Veranstaltungen wurden die Wechselwirkungen zwischen TV und eCommerce beleuchtet. Das betrifft Bereiche wie Apps auf Smart TV, Erfolgsmessungen von TV Werbespots, und die technische Bewältigung von kurzfristigen, extremen Belastungsspitzen auf Shopservern, bei der Schaltung erfolgreicher Werbespots im Fernsehen. Stichworte sind hier Full Page Caching und durch Virtualisierung gut skalierbare Hosting Enviroments.

Technischer Vortrag: Codeverwaltung auf Github

Technischer Vortrag: Codeverwaltung auf Github

Die Tatsache, dass der „second Screen“ nicht mehr automatisch ein PC oder Notebook ist, sondern zunehmend Tablets und Mobiltelefone jeglicher Art und Größe, macht eine geänderte Nutzeroberfläche notwendig, die sich automatisch dem Endgerät anpasst. Das betrifft nicht nur die Auflösung und das Layout, sondern tangiert viele Details, die zunächst leicht übersehen werden: Mouseover-Effekte machen auf Geräten mit Touch-Bedienung keinen Sinn. Dafür muss man hier bedenken, dass der Nutzer jederzeit von Hoch auf Querformat wechseln kann. Viele externe Module und Dienste lassen sich aber noch nicht gut in mobile Oberflächen und responsive Layouts integrieren. Daniel Beerden von WBL Konzept hat das in einer Session während der Unconference am Freitag für mich gut auf den Punkt gebracht:

„We need to THINK responsive. It’s not just about Layout“

Und dann gab es noch etwas, worüber ich mich persönlich sehr gefreut habe (Ich mache hier mal eine Ausnahme von der Regel, dass ich nicht über Firmen schreibe, für die ich arbeite oder gearbeitet habe).

…und – GEWONNEN!

Unter den Gewinnern des „Golden Cart Award“ war dieses Jahr der Online Shop von Street One. Zwar habe ich Ende letzte Jahres meine Tätigkeit bei der CBR eCommerce GmbH beendet, aber nach über zwei Jahren harter Aufbauarbeit ist dieser Shop dennoch auch „mein Baby“. In der Ansprache wurden neben dem Fokus auf Produkt und Service auch die sehr hohe Geschwindigkeit des Shops erwähnt. Das freut mich wiederum, weil ich jetzt für den Hostingprovider SysEleven arbeite, der die technische Infrastruktur für die CBR Shops betreibt. Den Preis nahm mein ehemaliger Kollege und Nachfolger entgegen und wir haben diesen Erfolg im Nachgang zusammen gefeiert. Sehr schön!

Einstimmung auf das Abendprogramm

Einstimmung auf das Abendprogramm

Abendstimmung

Abendstimmung

Oxid User Group Berlin – Auftakt

Nachdem im letzten Jahr bereits die Oxid User Group NRW gegründet wurde und recht interessante Themen behandelt hat, trafen sich in der letzten Woche auch in Berlin Vertreter der Oxid-Szene in den Räumen von SysEleven.

Die Teilnehmer kamen überwiegend aus den Bereichen Agentur, Software und Hosting. Es waren leider nur Vertreter eines einzigen – allerdings bekannten grossen – Shopbetreibers anwesend. Für zukünftige Treffen wäre es schön, wenn mehr Vertreter von der Anwenderseite teilnehmen würden, aber für den Auftakt war die Mischung schon recht gut, wie sich im Verlauf der Diskussionen herausstellte. Ganz überraschend war das nicht, da sich die meisten ohnehin schon kannten.

eCommerce im Umspannwerk

eCommerce im Umspannwerk

Von Oxid nahmen Eric Kort (technischer Entwicklungsleiter) und Marco Steinhäuser den Weg nach Berlin auf sich um sich über die Stimmung und Interessen der Teilnehmer zu informieren. Dieses erste Treffen diente vor allem dazu, herauszufinden, ob es überhaupt Bedarf gibt und was interessante Themen wären. Gesprochen und diskutiert wurde dann über:

  • Sinn und Unsinn von verschlüsseltem Quellcode
  • Erfahrungen mit automatisierten Tests und Continuous Integration
  • Vor- und Nachteile von Modulzertifizierungen
  • Methoden zum Deployment großer, heterogener Installationen

Ich selbst habe einen Prototypen für Content-Workflow vorgestellt, an dem ich seit einiger Zeit nebenher arbeite. Das positive Feedback vermittelte mir den Eindruck, dass an einem einfachen, flexiblen Tool durchaus Bedarf besteht.

Nach den fachlichen Teil blieb man nach geraume Zeit zum Plausch beisammen, was ein schönes Zeichen ist. Ich würde mich jedenfalls sehr freuen, wenn diess Treffen eine regelmässige Einrichtung wird.

Oxid User Group Treffen in Berlin am 05.02.

Am nächsten Dienstag (05.02.2013) findet das erste Treffen der Oxid-User Group Berlin statt. Das Treffen wird von der OXID eSales AG initiiert und findet in den Räumen von Syseleven statt, einem Hostingunternehmen, das einen Schwepunkt im Bereich High Performance eCommerce hat.

Die Ankündigung der Oxid eSales AG.

Die Ankündigung der Syselven GmbH.

Interessierte sind herzlich eingeladen, um Anmeldung wird gebeten.

Onlineshops – Mehrgerätefähigkeit am Beispiel von Oxid 5.0

Im Dezember hatte ich die Muße, mir über einige grundlegende Dinge jenseits des Tagesgeschäfts Gedanken zu machen. Ein Punkt betrifft dabei, welche Anforderungen aktuell an die Nutzeroberfläche eines Onlineshops zu stellen wären. Das letzte Mal habe ich solche Requirements im Herbst 2010 geschrieben. Seitdem hat sich einiges getan.

Internet „macht“ man nicht mehr ausschliesslich am Computer. Heutzutage ist auch der Durchschnittskunde sowohl stationär per PC, semistationär per Notebook, auf dem Sofa per Tablet und auch unterwegs per Smartphone im Internet. Einige nutzen sogar Browser in Smart TVs und Spielekonsolen. Was bedeutet das für eCommerce?

One Size doesn’t fit all!

Anhand des Zoos möglicher Endgeräte bleibt die Erkenntnis: Ein Layout für alle funktioniert nicht mehr, wenn man dem Kunden ein möglichst gelungenes Einkaufserlebnis bieten möchte.

Am augenfälligsten (im wahrsten Sinne des Wortes) ist, dass sich die Bildschirmauflösungen und Pixeldichte extrem unterscheiden. An dieser Stelle kommt man langsam nicht mehr um responsive Design herum. Aber das ist längst nicht alles.

Dazu kommt, dass sich die Bedienung von ’normalen Webseiten‘ per Maus und Tastatur deutlich von der Touchscreenbedienung auf Tablets oder Smartphones unterscheidet. Als Stichworte seien hier nur „Mousover“ oder „Pinch to Zoom“ genannt.

Immer wieder unterschätzt werden auch die vollkommen unterschiedlichen Nutzungsanforderungen zwischen konzentrierter Bedienung, wenn man längere Zeit ruhig vor einem Gerät sitzt, im Gegensatz zu einer lauten, ablenkenden Umgebung, wenn man ‚mal kurz zwischendurch‘ sein Smartphone hervorholt.

Ein Layout per Gerätegattung

Beim aktuellen Stand der Gerätenutzung sollte man drei unterschiedliche Nutzeroberflächen auf seinem Onlineshop haben:

Eine „Full Feature“ Oberfläche für herkömmliche Computer. Ausgelegt auf die Bedienung per Maus und Tastatur und Bildschirmauflösungen zwischen 1024 (Netbook) und 1920 Pixel bei 26″ Monitoren. Die Nutzungsmotivation der potentiellen Kunden ist sowohl gezieltes Suchen, als auch gemütliches Herumstöbern.

Für Tablets sollte die Oberfläche aufgrund der kleinen Displaygrössen zwischen 7″ und 10″ wesentlich, strenger und reduzierter sein; die Bedienelemente wegen der Gestenbedinung mit Fingern gleichzeitig erheblich grösser. Die Nutzungsmotivation gleicht derjenigen, der ersten Variante.

Für Smartphones ergeben sich aufgrund der nochmals kleineren Displaygrösse zwischen 3,5″ und 4,7″ erheblich eingeschränkte Darstellungsmöglichkeiten. Gleichzeitig unterscheidet sich hier die Nutzungsmotivation des Kunden. Wer unterwegs „schnell mal eben“ einen Onlineshop aufruft tut das meist, weil er Preise vergleichen will oder nach einen bestimmten Artikel sucht, den er im Laden gerade nicht finden kann. Hieraus sollte die Nutzeroberfläche optimiert sein.

Ein recht gelungenes Beispiel für diese Strategie bietet die Otto-Tochter Bonprix.

Umsetzungsmöglichkeiten am Beispiel Oxid 5.0

Wer die drei Gerätegattungen Computer, Tablet und Smartphone jeweils optimal unterstützen will, muss seinen Onlineshop also mit drei eigenständigen Templates ausstatten, sowie eine Geräteweiche bauen.

Das ging bisher elegant auf dem Server.

In den letzten acht Jahren habe ich diese Anforderungen bei verschiedenen Onlinediensten so gelöst, dass beim ersten Aufruf einer Seite auf dem Server die jeweilige Gerätegattung erkannt wird und das dazugehörige Templateset in der Session gespeichert wird. Dazu gab es jeweils einen Link, mit dem der Nutzer zu einer anderen Oberfläche wechseln konnte. Der Vorteil der Lösung ist, dass Deeplinks für alle Geräte gleich sind.

Jetzt bitte schneller und anders…

In den letzten beiden Jahren hat ein Wettrüsten stattgefunden, um Publikationen und Onlineshops schneller zu machen. Die nun erwartete Ladezeit von ein- bis zwei Zehntel Sekunden für die HTML-Seite lässt sich nur noch durch den Einsatz eines Full Page Cache erreichen.

So bringt zum Beispiel auch die vor kurzem erschienene Shopsoftware Oxid 5.0 einen Varnish Full Page Cache mit. Damit ist das o.g. Verfahren nicht mehr möglich, weil fertig gerenderte Seiten ausgeliefert werden, ohne dass eine Geräteerkennung auf dem Server angesprochen werden würde.

Die Auswahl des Templatesets kann nun nicht mehr dynamisch in der Session geschehen, sondern wird über unterschiedliche Subdomains gehandelt. Bei der Eingabe von http://www.meinshop.de oder http://meinshop.de wird die normale Website aufgerufen, bei http://t.meinshop.de die Tabletversion und bei http://m.meinshop.de die Seite für Smartphones. Dieses Verhalten kann man in der Datei cust_config.inc.php durch den folgenden Code herbeiführen.

// Theme switcher
$sHost = $_SERVER['HTTP_HOST'];
$aTemp = split('\.', $sHost);
switch($aTemp[0]) {

  case 't':
    $this->sTheme = 'tablet';
    break;

  case 'm':
    $this->sTheme = 'phone';
    break;
}

Die Geräteerkennung wandert dafür vom Server in den Client. Hierzu dient ein kleines Javascript, dass den Useragent prüft, das Ergebnis in einem Cookie speichert. Entspricht der ermittelte Gerätetyp nicht der aufgerufenen Subdomain, so wird der Nutzer per Popup gefragt, ob er lieber auf die optimierte Seite umgeleitet werden möchte.

Vorteil dieser Lösung ist die sehr einfache Umsetzbarkeit und die hohe Performance.

Nachteil ist, dass die Deeplinks nicht mehr geräteunabhängig sind. Zum Ausgleich empfiehlt es sich, Landingpages für Kampagnen als nicht-cachebare Verteilerseiten anzulegen. Aber das ist ein anderer Blogartikel…

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? ;-)

Retrospect: die ideale Shopsoftware

Am Freitag schrieb ich mir mein Missvergnügen an Magento von der Seele („Mein Leben als Softwaredissident„). Dann las ich einen Artikel auf Kassenzone.de den Alexander Graf bewusst provokativ mit dem Satz „Das beste Shopsystem ist zur Zeit Shopware“ begann und in dem er Magento disste. Interessant daran sind aber vor allem, die ausufernden Kommentare.

Als Replik auf den Artikel erschien auf ecomPunk der Artikel „Roman’s Rants: Shop System Wars„. Der zentrale Satz darin lautet:

„You know what? It doesn’t bloody matter which software you use, it’s just a fucking tool!“

Genau. Bloss kein Glaubenskrieg. In den letzten 15 Jahren war ich an so einigen Online Shop Projekten beteiligt und stiess dabei stets auf die Frage:

Was ist die ideale Shopsoftware?

HA! Ideal unter welchen Voraussetzungen? ecomPunk meint, daß die zentralen Fragen sind: Unterstützt das Tool effizient Dein Geschäftsmodell und war kostet der ganze Kram?

Das würde ich glatt unterschreiben. Ich spielte in Gedanken die Onlineshops durch, die ich in den letzten 15 Jahren gebaut hatte. Die Spannbreite war recht beachtlich. Sowohl bezüglich des Artikelsortiments, der kaufmännischen Anforderungen, der Systemumgebungen, der verwendeten Techniken und des Traffics. Die Shops waren unter anderem für:

  • Computer und Zubehör
  • Mobilfunkzubehör
  • Handyverträge eines der grossen deutschen Netzbetreibers
  • Merchandisingartikel
  • Finanzdienstleistungen
  • Bekleidung

Jedes Projekt hatte dabei spezielle Herausforderungen. Mal war es ein sehr heterogenes Artikelsortiment, mal extrem marketinggetriebenes Vorgehen, das tägliche Umbauten erforderte, mal die Kombination verschiedener Layouts, Sprachen und Währungen, mal ein sehr komplexes Systemumfeld und mal der schiere zu bewältigende Traffic.

Die verwendete Technik reicht von ein paar Zeilen PERL mit CSV Dateien, über PHP/MySQL-basierte System bis hin zu Enterprise Lösungen auf der Basis von Java/Oracle. In keinen zwei Projekten kam die gleiche Basistechnologie zum Einsatz. So unterschiedlich die Anforderungen und die zur Lösung eingesetzte Technik auch war – einige zentrale Erkenntnisse bestätigen sich immer wieder:

  • Man möchte zunächst Software, die so flexibel wie möglich ist. Das Marketing träumt davon, alles ohne Programmierer machen zu können, sobald das System einmal steht. Das führt zu einer Shortlist mit den üblichen Standardsystemen.
  • Standardsysteme versuchen alle denkbaren Szenarien abzudecken und sind daher prinzipiell schwergewichtig bzw. aufgeblasen.
  • Egal was das System kann – das Marketing will es immer etwas Anderes haben. Vorzugsweise etwas, das mit den vorhandenen Datenstrukturen nicht geht. „Und die Aktion startet übrigens morgen Mittag…“
  • Der „wiederverwendbare Code“ ist häufig so allgemein gehalten und verschachtelt, daß das Anpassen länger dauert, als schlanken „Wegwerfcode“ zu bauen.
  • Shops sind nach durchschnittlich zwei Jahren so verbastelt, dass die Codebasis komplett erneuert werden muss.
  • Große Shops (also nicht der kleine Spezialversender, der seine Pakete noch selber zu DHL bringt) brauchen meist kein Shop-Backend. Sie sind direkt an Warenwirtschaft, Finanzbuchhaltung und PIM angeschlossen.
  • Aussagen wie „Mit PHP schafft man den Traffic nicht“ sind Blödsinn. Es kommt letztlich auf die Systemarchitektur an. Was Flickr und Facebook antreibt, sollte auch für Deinen Laden reichen. Ich habe vor 20 Jahren mal die weisen Worte gelesen „Ein schlechter Algorithmus ist in jeder Programmiersprache langsam“.

…to be continued…

Handel im raschen Wandel

Mir schwirren gerade ein paar Gedanken zu dem wirtschaftlichen Wandel, den das Internet so ermöglicht und in dem wir gerade mitten drin stecken durch den Kopf. Ich schreibe mit Bedacht ermöglicht und nicht verursacht. Letztlich haben ja die Kunden das (Geld)Zepter in der Hand und weisen die Richtung. Nichtsdestotrotz findet dieser Wandel in mehreren Phasen statt und jedes Mal werden die Betroffenen irgendwie kalt erwischt.

Phase I: Immaterialgüter und die Aufmerksamkeitsökonomie

Die ersten Branchen, die seit ein paar Jahren mitten im Hurrican der Veränderungen hin- und hergeworfen wurden (mein Gott, schreibe ich heute schwülstig…) sind Medienunternehmen und jede Form von vermittelnden Berufen. Plattenfirmen mussten unter Schmerzen verstehen, dass sie nicht Schallplatten, sondern den Zugang zu Musik verkauften während einige Zeitungsverleger zum Teil immer noch glauben, dass sie Papierwarenhändler sind. Makler sind im Zeitalter von Immoscout und co. eigentlich ebenfalls überflüssig geworden. Das hat sehr viele kalt erwischt. Dabei ist die Einsicht, dass Immaterialgüter perfekt über das Internet zu vertreiben sind, vergleichsweise trivial. Da die Kosten und Einstiegshürden minimal sind, ergibt sich daraus zwangsläufig ein knallharter Verdrängungswettbewerb.

Phase II: Weg mit den Katalogen

Die nächste Branche, die es gerade heftig durcheinanderwirbelt sind Versandhändler. Quelle ist bereits Geschichte, Neckermann möglicherweise auch und selbst der Gigant Otto kommt schon etwas ins Stolpern. Das ist einerseits wenig überraschend, weil aus Kundesicht onlineshops auch „irgendwie sowas ähnliches wie Kataloge“ sind und man sich deshalb gar nicht gross umgewöhnen muss. Aus Händlersicht ist der Markt aber hammerhart und da passen die traditionellen Herangehensweisen der Versandhändler nicht. Anstatt gemütlich in Jahreskatalogen zu blättern, werden mindestens tagesaktuelle Angebote verglichen. Das erfordert ein vollkommen anderes Ansprechen der Zielgruppen, extrem hohe Ansprüche an Logistik und Service bei minimalen Margen.

Phase III: Der stationäre Handel

Seit kurzem bekommt auch der traditionelle Handel immer mehr Schwierigkeiten. Görtz hat gerade beschlossen, 30 Schuhgeschäfte zu schliessen und ob das die letzten waren, sei mal dahingestellt. Immer mehr Handelsvolumen wandert ins Internet zu Onlinehändlern. Und das sind im Gegensatz zu den meisten stationären Händlern nicht unbedingt Deutsche Unternehmen, wie Amazon, Asos und Konsorten zeigen.

Bei Veränderungen, die so gross sind, dass sie die komplette Immobilienbranche auf den Kopf stellen, wird es selbst hartgesottenen eCommerce Profis etwas Flau im Magen. Einige Kommentare auf der Branchenplattform Exciting Commerce warnen vor verödeten Innenstädten, in denen man nicht mehr flanieren mag.

Phase IV: Der Tod der City und die Ödnis des Netzes

Als alter Stadtplaner sage ich: Das ist allerdings ein Trend, den man schon recht lange beobachten kann. Möbelgeschäfte sind schon in den 70er Jahren an den Stadtrand gezogen. Kinos verschwanden, als sich alle in den 80ern einen Videorekorder ins Wohnzimmer stellten. Büroartikel und Schreibwaren? Wir haben doch seit den 90ern alle PCs. Heimelektronik wird entweder im Gewerbegebiet oder bei Amazon gekauft. Schallplatten und DVD? Wird alles über das Netz gestreamt. Bücherläden? Naja, noch gibt es ein paar…

Seien wir ehrlich: In den Innenstädten gibt es schon seit längerem eigentlich nur noch Schuhgeschäfte, Klamottenläden und Imbissbuden. Wie lange sich der Pizzastand aber noch halten kann, wenn auch Bekleidung aus der Stadt verschwunden ist? Tja…

Alles virtuell – und nun?

Im Internet ist aber auch nicht alles eitel Sonnenschein. Der Wettbewerb ist gnadenlos, weil niemand einen Standortvorteil hat. Alle sind nur einen Klick vom Kunden entfernt – jedefalls theoretisch. In letzter Konsequenz wird es nur drei Typen von Händlern geben:

  • Eine Handvoll Universalhändler mit hochoptimierter Kostenstruktur nutzen die Economies of Scale. Und Scale bedeutet international.
  • Daneben werden Marken den Vertrieb zunehmend selbst durchführen.
  • Am virtuellen Rand ist dann noch Platz für ein paar Nischenanbieter.

Aus die Maus. Ziemlich trübe Aussichten.

Allein – mir fehlt der Glaube. Wo ist das schlendern? Wo die Haptik? Wo lässt man sich inspirieren? Irgendwo da draussen liegen noch ganz neue Handelskonzepte. Im Real-Life. Und sie warten auf den richtigen Zeitpunkt!

Oxid Commons 2012 in Freiburg

Am Donnerstag, den 24.05 fand in Freiburg wieder die Oxid Commons statt – die Hausmesse des Herstellers der Onlineshopsoftware Oxid eSales. Es waren fast 800 Teilnehmer anwesend, um den Vorträgen zu lauschen, und sich über die Neuerungen im Oxid Ökosystem zu informieren. Auch dieses Jahr waren wieder diverse Anbieter von Paymentsystemen, Logistiklösungen, Hosting, Suchmaschinen, Mobilanwendungen und sonstigen Diensten mit eigenen Ständen vor Ort.

Oxid Commons in der Rothaus Arena

Oxid Commons in der Rothaus Arena

Oxid Commons - Ausstellerbereich

Der Ausstellerbereich

3 grosse Themen

Die Trends, die bereits im letzten Jahr identifiziert wurden – mehr Markenshops und spezialisierte Nischenanbieter (z.B. Spazierstöcke bei www.stockshop.de) – haben sich bestätigt und der Onlinehandel hat noch immer enorme Wachstumsraten.

Für dieses Jahr kristallisieren sich drei wichtige Themen heraus:

  • Internationalisierung
  • Multichannel
  • Performance

Die fortschreitende Professionalisierung und der Trend zu Markenshops sorgt dafür, dass es immer wichtiger wird, in vielen Ländern vertreten zu sein. Neben den offensichtlichen Herausforderungen (Sprache, Währung, Steuer, Logistik, Gesetze…) für die auch teilweise Lösungsanbieter vor Ort waren, wurde in einem Vortrag darauf hingewiesen, dass man auch die Mentalitätsunterschiede in unterschiedlichen Ländern nicht unterschätzen darf. Was in einem Land hervorragend funktioniert, kann im nächsten Land durchaus ein Flop werden.

Eine weitere grosse Herausforderung, mit denen insbesondere Markenhändler zunehmend konfrontiert werden, ist die Kombination aller Vertriebskanäle. Kunden trennen nicht nach Online, Offline, Markenshop oder Multilabelanbieter. Sie werden hier aufmerksam, informieren sich dann dort und kaufen schliesslich an einer anderen Stelle. Heraus kommt ein unberechenbarer Customer Journey, bevor es (hoffentlich) zum eigentlichen Kauf kommt. Also muss man auf allen Kanälen präsent sein, um den Kunden auf seinem Weg nicht zu verlieren. Ein Fazit der Podiumsdikussion zum Schluss war, dass auch die Anbieter in den nächsten Jahren nicht mehr in unterschiedlichen Verkaufskanälen denken werden und der Begriff eCommerce obsolet sein wird.

Diese beiden Trends, die zu immer komplexeren Geschäftsabläufen führen und die ständig steigenden Online-Umsätze führen dazu, dass die Performance aller beteiligten Systeme – insbesondere des Shops selbst – beständig an Bedeutung gewinnen. Laufende Verbesserungen sowohl im Browser des Kunden, in der Shop Software, als auch beim Hosting waren daher wichtig.

Networking

So gut die Vorträge auch waren, ist für mich das abendliche Networking wichtiger. Hier konnte ich viel wertvollen Input für das Tagesgeschäft und unsere Roadmap für das nächste Jahr gewinnen. Die musikalische Untermalung und das hervorragende Catering haben den passenden Rahmen abgegeben, in dem man gepflegte und informative (teils auch einfach nur lustige) Gespräche führen konnte.

Informatives Beieinander

Informatives Beieinander

Am Freitag verbrachte ich die Wartezeit bis zur Abreise damit, die gewonnenen Erkenntnisse mit meinem Kollegen zu rekapitulieren und das schöne Wetter in Freiburg zu geniessen. Hier noch einige Eindrücke von dem malerischen Städtchen.

Park mit Aussicht

Park mit Aussicht

Typisch: Viele Fahrräder

Typisch: Viele Fahrräder

Rathaus

Rathaus

Fazit

Auch wenn An- und Abreise wie auch im letzten Jahr recht umständlich und teil wirklich ärgerlich waren (die Bahn hat mal wieder alle Vorurteile über Zuverlässigkeit und Service bestätigt), hat sich die Veranstaltung gelohnt.

Oxid Commons 2011

Die letzten beiden Tage der Woche hat es mich in den tieftsten Süden Deutschlands verschlagen – nach Freiburg. Dort fand die Hausmesse von Oxid eSales statt – einem Hersteller von Online Shopping Software. Die Vorträge am Donnerstag waren von guter Qualität und ich konnte einige gute Ideen und Anregungen mitnehmen. Auch das Visitenkartentauschspielchen lief gut. Immerhin um die 600 Teilnehmer sollen vor Ort gewesen sein. Wie im Süden nicht anders zu erwarten war das Catering sehr gut und am Abend gab es noch eine nette Party.

Messe Freiburg

Messe Freiburg

Oxid Commons

Oxid Commons

Publikum lauscht Vortrag

Publikum lauscht Vortrag

Mit Rücksicht auf die Party am Vorabend hat die Unconference am Freitag etwas später angefangen, so dass ich zuvor die Gelegenheit hatte, zu Fuss durch die Altstadt zu schlendern, um zumindest einen ersten Eindruck von Freiburg zu bekommen. Nettes, liebliches Städtchen mit Flair. Lustig ist diese winzige Bach, der durch die Altstadt fliesst – direkt in der Strasse. Sowas nannte man früher mal Gosse, glaube ich.

Die Unconference fand in deutlich kleinerem Rahmen statt: ca. 40 statt 600 Teilnehmer. Der Treffpunkt war ein Restaurant, das sehr malerisch in einem Hofgang lag. Hier ging es dann auch wesentlich deutlicher zur Sache: Shop/CMS Integration, REST API, Überrabeitung des Admin Interfaces und so weiter.

Weil das Wetter wirklich fantastisch war, wurden die Sessions am Nachmittag dann auch auf die Terrasse verlegt. Leider konnte ich nicht ganz bis zum Schluss bleiben, weil ich meinen Flieger in Basel erreichen musste.

Insgesamt war das eine recht erfolgreiche Reise, die zu vielen neuen Ideen und einigen wichtigen Einsichten bei mir geführt hat. Lediglich die Reisezeit von und nach Freiburg ist schon recht ätzend. Von Hannover mit dem Zug habe ich 6,5 Stunden gebraucht und mit dem Flugzeug nach Berlin sogar 7 Stunden (jeweils von Tür zu Tür!).

Jetzt werde ich erst mal das Wochenende zu Hause in Berlin geniessen.

Freiburg

Freiburg

Unconference

Unconference

Freiluftsession

Freiluftsession

Karma Restaurant

Karma Restaurant

« Vorherige SeiteNächste Seite »