tiny little gizmos

1000. Jubiläum!

Zum Abschluss des ersten warmen und schönen Wochenende des Jahres möchte ich ein (für mich) bemerkenswertes Jubiläum verkünden:

Dies ist der 1000. Artikel in meinem Blog.
(Wie Kermit sagen würde: „Applaus, Applaus, Applaus!“)

Als ich mit dem Bloggen angefangen hatte, dachte ich, dass ich das drei oder vier Monate lang machen würde. Mein Plan war, begleitend zu meiner Diplomarbeit immer mal wieder den aktuellen Zwischenstand öffentlich zu verkünden (siehe meinen ersten Eintrag „Jetzt geht’s loooos… vom 16. Juli 2006″. Der Subtitel des Blogs ist „tiny little gizmos“, weil mein Diplomthema seinerzeit „Mobile Virtual Communities“ waren. Ich vermutete, mich daher viel mit mobilen Endgeräten auseinandersetzen zu müssen. Das war noch vor der Einführung des ersten iPhone und Facebook war in Europa noch kein Thema.

Mein Plan ging nicht auf.

In die Diplomarbeit habe ich soviel Zeit und Energie investiert, dass kaum etwas davon für den Blog übrigblieb. Andererseits habe ich anschließend Gefallen daran gefunden, mich immer mal wieder über das eine oder andere Thema, das mich gerade beschäftigte, zu schreiben.

Für eine Weile wird das sicher auch noch so bleiben.

eCommerce ist Scheisse

Ich verdiene mein Geld seit 20 Jahren im Bereich eCommerce. Hauptsächlich dadurch, dass ich Onlineshops entwickele. Und jetzt kommt der Witz:

Ich kaufe selber fast nie online ein. Ich hasse es.

Dafür gibt es Gründe:

Einerseits die unfassbare Datenschnüffelei durch das Onlinemarketing und die totale Nachverfolgbarkeit meiner Interessen und Geldflüsse. Gut – damit oute ich mich als Dinosaurier aus dem letzten Jahrhundert, der noch an das Konzept von Privatsphäre glaubt. Ich verwirrter alter Mann. Aber lassen wir den Punkt einfach mal außen vor.

Das wirklich Killerkriterium gegen Onlineshopping ist für mich, dass es zu umständlich, nervenaufreibend und zeitfressend ist.

Nanu?

Soll nicht gerade der Vorteil von Onlineshopping sein, dass es so fürchterlich spontan, praktisch und zeitsparend ist?

Was die Shops selbst betrifft, stimmt das mittlerweile auch. Es haben sich bestimmte Standards durchgesetzt und die Benutzbarkeit ist in der Regel recht gut.

Das Problem ist die Logistik. Ich kann mir nichts nach Hause bestellen, weil ich in der Regel nicht zu Hause bin, wenn der Paketdienst kommt. Das bedeutet, dass ich mir Dinge ins Büro liefern lassen muss, was in den meisten Firmen aus gutem Grund nicht gerne gesehen wird.

Oder ich muss mir die Lieferung aus den verwegensten Teilen der Stadt zusammensuchen, weil irgendwo ein obskures Geschäft so freundlich war, die Lieferung anzunehmen. Leider haben diese Geschäfte meist recht eigenwillige Öffnungszeiten. Jetzt habe ich dasselbe Problem: Dieser Laden hat vermutlich nur dann geöffnet, wenn ich im Büro sitze.

Wenn ich Mittags ausnahmsweise mal in die DHL Filliale im nächsten Shopping Center gehe, steht da schon eine 50m lange Schlange von Frauen, die ihre Zalando Retouren abgeben wollen.

Im Moment kommt für mich der Online-Einkauf nur in folgenden Fällen in Frage:

  • Digitale Einkäufe. Auswählen, bezahlen, runterladen, fertig.
  • Flugtickets direkt bei der Airline
  • Spezialprodukte, die in der eigenen Gegend nicht zu haben sind.

Ein komplettes No-Go hingegen in folgenden Fällen:

  • Kleidung, Schuhe und andere Dinge, die ich mit hoher Wahrscheinlichkeit noch mal umtauschen muss.
  • Waren des täglichen Bedarf, die ich überall auf dem Heimweg bekomme – insbesondere Essen.
  • Komplette Reisen. Unfassbar schlechte Websites, totales Chaos bei Sortiment und Preisen.

Bevor ich es vergesse – bei den Reiseportalen kommt noch der Nagativpunkt „heftige Verarsche“ hinzu. Beispiele:

  • Ich sehe das selbe Hotel bei drei verschiedenen Anbietern für drei verschiedene Preise. Dann kehre ich zum ersten Anbieter zurück und der Preis ist um 100,- gestiegen – in zwei Minuten. Wie bitte?
  • Ich möchte mit einer Freundin verreisen. Sie surft bei sich zuhause auf ihrem Mac durch die Angebote, ich bei mir zu Hause auch und wir chatten derweil. Sie findet ein gutes Angebot, und schickt mir den Link und ich bekomme einen anderen Text und einen anderen Preis angezeigt. Ach so…?
  • Ich gebe im Filter genau an, in welchem Zeitraum die Reise liegen darf (7 Tage in der Zeitspanne von X bis y). Als Ergebnis eine Liste von 100 Angeboten,die zu 2/3 außerhalb dieses Zeitraums liegen. Hallo Mc Fly – irgendjemand zu Hause?
  • Ich finde ein passendes Angebot und will es buchen – plötzlich heißt es „Wir können nicht garantieren, dass das Angebot zum Angegebenen Zeitpunkt für den genannten Preis verfügbar ist. Zur verbindlichen Reservierung hier klicken“. Euch habe Sie doch wohl ins Gehirn…

Das letzte Mal habe ich 2011 versucht eine Reise online zu buchen und dabei sind mir alle o.g. Dinge passiert. Insgesamt habe ich zwei Abende ergebnislos am Rechner verbracht. Danach hatte ich die Nase voll und die Reise war in 30 min im Reisebüro gebucht. Sie war nicht teuer, das Hotel in Ordnung, die Lage super. Klasse Urlaub. Seitdem buche ich nur noch im Reisebüro.

2 Tage down

Ich habe gerade gesehen, dass mein Webserver 2 Tage down war. Mist!
Daran nerven mich zwei Dinge:

1. ist das ungefähr schon 20 mal passiert. Ich weiss nicht, weshalb der Apache derart wackelig ist.

2. Scheinbar hat der Hoster darauf kein Monitoring laufen, weil ich niemals über Probleme informiert werde, sondern immer durch Zufall darauf komme. Ich schaue ja nicht dreimal am Tag meine Website an.

3. Könnte man das durch ein Skript, welches den Dienst automatisch neu startet noch vereinfachen, aber was verlange ich da…

Okay, ich bezahle vergleichsweise schmales Geld für die Kiste und mein Wohlergehen hängt nicht von meinem privaten Blog ab, aber so ein Servermonitoring ist heute eigentlich Standard und frisst kein Brot.

Genau sowas ist eben der Unterschied zwischen einem echten Hoster und einem Spielzeugprovider.

*grummel*

Store and Forward, Offlinenetz… was bitte?

Berufsbedingt setze ich mich momentan verstärkt mit Netzwerkthemen auseinander – auch ausserhalb der Arbeit. In den letzten Wochen habe ich mich mit einigen Leuten getroffen, die nicht nur mit dem aktuellen Internet arbeiten, sondern sich in der Freizeit auch mit Alternativen für bestimmte Spezialanwendungen auseinandersetzen.

Nun habe ich in zwei Gesprächen – immerhin unter wirklichen Nerds – das Thema „Store-and Forward in Netzen in denen Knoten nicht ständig verbunden sind“ angesprochen und ergänzt „so ähnlich, wie damals das Fido Net“. Beide Male habe ich in ratlose Gesichter geblickt. „Was war denn das Fido-Net?“

Ich hätte genausogut von Aufstieg und Fall des Osmanischen Reiches erzählen können. Kein Plan, kein Geschichtsbewusstsein. Das hatte ich nicht erwartet, weil Retrocomputing ja gerade ziemlicher Trend ist. Immerhin waren Mitte der 90er weltweit fast 40.000 Systeme mit mehreren 100.000 Nutzern vernetzt – alles von Privatpersonen betrieben.

Wer sich für die Vernetzung zwischen Ende der 70er bis Mitte der 90er Jahre, bevor es das Internet für Privatpersonen gab interessiert, dem kann ich die wirklich gute Dokumentation „BBS The Documentary“ ans Herz legen. Dankenswerterweise sind die Folgen bei Youtube zu sehen, da die DVDs nur in USA erhältlich waren.

Die Folge in der das Fidonet behandelt wird, ist diese. Viel Spass!

 

VirtualBox komplett löschen (Apple Mac)

HINWEIS: Der Artikel bezieht sich auf eine Version von Virtual Box, die im Januar 2013 aktuell war. Änderungen, die seitdem an dem Produkt vorgenommen wurden, finden sich hier nicht wieder, da ich es seit damals nicht mehr benutzt habe.

Ich bin frustriert. Heute habe ich meinen kompletten Tag weggeworfen. Anstatt am Rechner zu tun, was ich zu tun habe, habe ich mich den kompletten Tag mit den Zickigkeiten von VirtualBox rumgeärgert. Mit VirtualBox kann man einen kompletten Rechner in einem anderen Rechner emulieren. Der Sinn darin kann – wie im vorliegenden Fall – darin liegen, eine fertig eingerichtete Entwicklungsumgebung für eine komplexe Webapplikation (also einen Webserver) auf seinem Arbeitsplatzrechner zu installieren.

Normalerweise geht das recht schmerzfrei. Heute hätte ich aber schreien können, so sehr hat mich der Mist geärgert. Da ich dabei durchaus einiges gerlernt habe, möchte ich mein frisch erworbenes Wissen der Allgemeinheit zur Verfügung stellen.

Vorgestern habe ich eine (fast) fertig konfigurierte VM (Virtuelle Maschine) zur Verfügung gestellt bekommen. Es ist ein Debian Linux mit einer komplexen Webapplikation und vier Netzwerkschnittstellen. Es war schon etwas hakelig, das Ding so zum Laufen zu bekommen, dass man von aussen – also vom Gastsystem, einem Apple Mac – den Webserver, den Datenbankserver und den SFTP Server ansprechen kann. Aber es lief dann irgendwann zufriedenstellend.

Bis heute Morgen.

Da hat sich die komplette VM zerlegt. Weshalb auch immer. War nicht wieder in Gang zu bringen. Ganz klarer Fall – neu installieren. Beim zweiten Mal weiss man ja, worauf man zu achten hat.

Denkste!

Neu installieren gerne – aber die Netzwerkadapter liefen trotzdem nicht. Selbst die radikale Variante, VirtualBox neu zu installieren und dann die VM darauf neu aufzuspielen brachte keine Besserung. Um ein paar Stunden suchen und Fluchen abzukürzen: VirtualBox lässt sich nicht komplett deinstallieren sondern behält tonnenweise Mist auf der Festplatte, der bei der nächsten Neuinstallation „freundlicherweise“ wieder eingelesen wird. Das führt direkt zu der Frage:

Wie kann man VirtualBox denn nun vollständig deinstallieren?

  • Zunächst löscht man die alle Maschinen in dem Programm
  • Dann fährt man VirtualBox herunter
  • Dann löscht man tatsächlich die ganzen VM-Dateien auf der Platte
  • Jetzt öffnet man das DMG Installationsimage aus dem man die Software dereinst installiert hatte. Aber bitte exakt dieselber Version. Das habt Ihr doch sicherlich gut aufgehoben, oder? ;-)
  • In dem Image liegt ein Deinstallationsskript – aber draufklicken nützt nicht. Stattdessen öffnet man jetzt ein Terminalfenster und begibt sich auf der Kommandozeile in das Installationsimage:
    cd /Volumes/VirtualBox/

    Nun muss man das Uninstall Skript mit Administratorrechten starten. Dazu gibt man ein:

    sudo ./VirtualBox_Uninstall.tool

    Pukt und Slash müssen vor den Skriptname, weil die Shell das Skript sonst in allen möglichen Verzeichnissen sucht, ausser im aktuellen.

  • Nun muss man noch eine Frage mit ‚yes‘ beantworten und schon geht die Löschorgie los.

Wer nun aber glaubt, damit sei alles erledigt liegt falsch. Jetzt kommt noch ziemlich viel Handarbeit. Innerhalb des eigenen Homeverzeichnisses (~/ bzw. /Users/username/) muss noch in den folgenden Verzeichnissen nach Überresten gesucht werden, die zu entfernen sind (alles in dem virtualbox vorkommt):

  • ~/Library/
  • ~/Library/Application Support/
  • ~/Library/Caches/
  • ~/Library/LaunchAgents/
  • ~/Library/PreferencesPanes/
  • ~/Library/Preferences/

Es kann natürlich auch nichts schaden, dieselben Verzeichnisse noch mal auf Systemebene zu durchsuchen:

  • /Library/Extensions/
  • /Library/StartupItems/

Ist doch alles fast selbsterklärend, oder? Nein, nicht wirklich. Ich könnte ausrasten. Wenn man schon ein Skript zur Deinstalltion schreibt, wieso vergisst das Ding dann 50% der Arbeit?

Die Erkenntnis hat mich mit dem vielen hin- und herprobieren, suchen usw. fast einen kompletten Tag gekostet. Ich hoffe, dass ich jemand anderem mit dem Beitrag das Leben ein bischen erleichtern kann.

Instagram? Muhahaha…

Letzte Woche gab es einen Sturm im Wasserglas: Instagram verkauft DEINE Bilder.

Zunächst mal stimmte das so nicht ganz. Deutscher „Qualitätsjournalismus“ eben. Instagramm hat sich bestimmte Nutzungsrechte eingeräumt – was auch schon nicht nett ist und sicherlich auch nicht gerichtsfest. Aber Leute – hey – der Laden gehört zu Facebook. ’nuff said.

Zudem: Ich habe nie kapiert, was an dem Ding toll sein soll. Ein Service, der schlechte Schnappschüsse vergilbt aussehen lässt. Toll! Nicht.
Ansonsten gilt wie immer bei Diensten im Internet:

Wenn Du für einen Dienst nicht zahlst, bist Du nicht der Kunde, sondern die Ware.

In diesem Sinne möchte ich mal wieder auf den hervorragenden Webcomic von XKCD verweisen, der das Thema mal wieder voll auf den Punkt bringt:

Zwei niedliche Browserspielchen für zwischendurch

Gerade habe ich zwei tolle kleine Browser Spiele für zwischendurch gefunden:

Reaching Finality ist ein süsses kleines RPG im Zelda-Stil und in „feinster“ Gameboy-Auflösung.

Reaching Finality - Oberwelt

Reaching Finality - Oberwelt

Reaching Finality - Unterwelt

Reaching Finality - Unterwelt

Auch klasse: Forget me not.

Extrem reduziert Grafik, aber tolles Gameplay. Wie fühlt es sich an? Wie eine Mischung aus Pac-Man, einem Shooter in 2D und Adventure. Ach, probiert es doch einfach aus…

Forget me not

Forget me not

Noch mehr Spielereien von Nerds

Bin gerade über zwei lustige Dinge aus der Rubrik „Das passiert, wenn Leute zuviel Zeit haben“ gestolpert. Oder auch: „Wenn die Spielidee klasse ist, ist es egal, wie die Grafik ausieht“.

Portal auf TI Taschenrechner

Erinnert sich noch jemand an Taschenrechner? War mal ein heisses Ding in den 70ern und 80ern. Ich habe hier auch noch so ein Gerät rumliegen: Einen Texas Instruments TI-84, programmierbar und mit Klötzchengrafik. Irgendjemand hat sich nun den Spass gemacht, das Spiel Portal auf dem Gerät umzetzen. Sieht gut aus. Seht selbst:

 

Rollenspiel mit Textgrafik – im Browser!

Und wenn wir schon mal in den 70er/80er Jahren sind: Star Wars und Rogue. Ersteres kennt jeder, das zweite vielleicht nicht. Roguelikes sind Rollenspiele in denen man durch Dungeon rennt, Monster besiegt und Schätze einsammelt. Der Witz ist, dass das alles ohne Grafik, nur mit Text symbolisiert wird. Ondřej Žára hat nun ein solches Spiel programmiert – mit Star Wars Thema und im Broser lauffähig. Genial!

Browser Star Wars Rogue

Browser Star Wars Rogue

=> Hier geht es zum Spiel

Beides gefunden auf Nerdcore. Danke!

Noch mehr Mobile-Mist

Ich hatte mich ja neulich schon mal darüber ausgelassen, dass mir die ganze Entwicklung mobiler Betriebssysteme nicht schmeckt. Unsere ach-so-tollen Hyper-Super-Duper-Hi-End-Smartphones schmiessen neuerding immer mehr Funktionen raus, die seit mindestens 10 Jahren (in Mobilfunkzeit: „schon immer“) Standard waren. Neueste Entdeckung:

Android kann offensichtlich nur noch normale HTTP(S) Links.

Ich hatte gerade mir JQuery Mobile versucht, mir ein kleines Telefonbuch zu basteln und musste feststellen, dass alle Links, die mit tel:// sms:// oder mailto: anfingen, nicht mehr unterstützt werden.

Wirklich grossartiges Krüppelzeug, Ihr Arschlöcher!

Kann Nokia mal bitte wieder vernünftige Handies bauen – ich sehne mich wirklich danach, diesen unausgegorenen Ami-Rotz (Apple, Google, Microsoft, RIM) wieder loszuwerden.

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

Nächste Seite »