Mir ist gerade ein strittiger Punkt in einem SLA untergekommen, den ich in Zukunft bei der Vertragsgestaltung berücksichtigen werde: wer misst eigentlich die Einhaltung des Service Levels?

In einem SLA von uns steht klar definiert, dass ein Dienstleister eine Verfügbarkeit der Dienste (definiert als Antwort innerhalb von 500 ms) im Monatsdurchschnitt von 99,5% zu garantieren hat. Wenn nicht, wird eine (Geld-)Strafe fällig. Soweit gut und bekannt.

Leider ist nicht klar definiert, wer genau diese Verfügbarkeit misst. Wir messen selbst (nagios) und mit ServerGuard24. Der Dienstleister misst (soweit ich weiss) selber.

Nun liegen die Zahlen der drei Messpunkte leicht auseinander. Diese Abweichung könnte aber zu einer recht empfindlichen Strafe führen. Und es geht um die Frage: wessen Messung gilt?

Zusammenfassend habe ich heute gelernt: lieber € 10 im Monat in einen unabhängigen Dienstleister investieren, der die SLA misst. Und diesen Dienstleister dann im SLA verankern. Spart Diskussionen.

P.S. Eigentlich sind Service Levels von 99,5% m.E. heutzutage bei kritischen Anwendungen nicht mehr zeitgemäß. Das sind mehr als drei Stunden Downtime pro Monat. Da muss ich mal nachbessern.

Die Ergebnisse der Aufrufe waren so beeindruckend (und erschreckend), dass Jupp direkt eine Woche Zeit bekommen hat, um unseren Code zu durchforsten. Das Ergebnis

• Die Execution Time wurde teilweise um bis zu 75% reduziert.
• Unser Code wirkt jetzt teilweise etwas komisch.

Normalerweise würde man ja sagen: wenn solche Ersparnisse drin sind, wurde vorher etwas falsch gemacht. Zumindest würde ich das immer behaupten. Unsere Ladezeiten waren aber immer ok (zwischen 600-800 ms) und deswegen war Performance lange keine Baustelle. Der Cache federt bei uns Unfug ab, und ordentliche Hardware macht den Rest.

Wo kam der Performance-Gewinn her? Zwei Stellen waren:

Magic Functions und Member Variablen. Wir machen ausgiebigen Gebrauch von magic functions. Vor allem, um partitionierte Daten nachzuladen. Oft ist es aber wesentlich günstiger mit den Daten, die man eh hat, die member Variablen zu füllen anstatt auf den __get() zu warten. Auch wenn __get() im Normalfall sehr billig ist (je nachdem, was man da alles reinsteckt).

Validate Methoden. Jeder Service in unserer Architektur validiert alle Parameter, mit denen er aufgerufen wird. So kommt kein Quatsch bis zur DB vor. Dabei gibt es einfache Validierungen (int, string) aber auch kompliziertere, bis hin zu DB-Lookups usw. Wir finden Sicherheit wichtig, und dazu gehören saubere Input-Daten. Diese validate-Funktionen werden hunderte Male pro Seite aufgerufen. Zum einen haben wir da die “Klassen-lastigkeit” reduziert. Wir haben Zend_Validate eingesetzt, da liegen zwischen dem Aufruf und dem Ergebnis verschiedene Klassen, diese implements dies, die andere macht die factory für das usw. Zusätzlich machen an so zentralen Stellen Code-Änderungen im PHP-Bereich Sinn. Normalerweise wird da ja viel kaputt optimiert, aber bei den zentralen Stellen bekommt man was raus. Ein unintuitives Lieblingsbeispiel von mir:

if (isset($aValues[$sNeedle]))
{
   return true;
}
elseif (in_array($sNeedle, $aValues))
{
   return true;
}
else
{
   return false;
}

Normalerweise könnte man sagen, das obere mit dem isset() kann man sich sparen. Richtig. Nur: isset ist viel schneller als in_array (Benachmarks, mehr). In diesem Fall hat der isset ca. 95% der Fälle erledigt, NULL kommt selten vor. Sprich der aufwendigere Code ist sogar schneller. Pro Ausführung spart man jetzt nicht wahnsinnig viel, aber in einer sehr zentral genutzten Funktion macht es schon einen Unterschied.

Ich kann XHProf wärmstens empfehlen. Man entdeckt tolle Sachen (wer zum Teufel hat die Regex da eingebaut?) und spart Ausführungszeit. Uns hat die Optimierung sicherlich ein Hardware-Upgrade eingespart.

Ein kleiner Hinweis noch: wenn man XHProf lokal auf dem Testsystem ausführen muss man unbedingt gucken, dass die Bedingungen, insbesondere was Caches angeht, den realen entsprechen. Sonst wird an der falschen Stelle optimiert. Passiert den besten Bloggern…

Vorgestern hat er ein kostenloses eBook veröffentlicht, zusammen mit einigen nahmhaften Co-Autoren (Gary Vaynerchuk, Guy Kawasaki, Tim O’Reilly, Tony Hsieh, Tom Peters usw.) . Das eigentlich simple Thema: Here’s what we’re working on and thinking about.

Ich würde jedem empfehlen, mal durch das eBook durchzuflippen. Mich haben einige Beiträge sowohl persönlich wie auch in beruflicher Hinsicht interessiert und berührt. Die große Schriftgröße und die dadurch bedingten kurzen Texte finde ich als Format super. Einmal kurz Inspiration am Abend.

Das eBook gibt es als kostenlosen Download, bei Scribd oder in seinem Blog.

Beim nächsten Mal geht es wieder weiter mit technischen Themen. Ich denke ich sollte mal etwas über Suche schreiben, da bekomme ich einige Anfragen zu und es ist ein Problem, was schwierig ist gut zu lösen. Wenn es andere Themen gibt, gerne melden! Entweder in den Kommentaren oder an jan@hitmeister.de

Bei Hitmeister organisieren wir im nächsten Jahr zwei Events: einmal den Internet Marketing Köln (IMK) und einmal den Hitmeister e-Commerce Day.

• Der IMK richtet sich an alle, die im Online-Marketing (samt der Unterdisziplinen) tätig sind und sich mit anderen austauschen möchten. Es gibt keine Vorträge, sondern Kölsch, Fingerfood und nette Gespräche. Früher war das mal der Online-Marketing Stammtisch, von einem Stammtisch kann man aber bei > 400 Teilnehmern nicht sprechen. Die Teilnahme ist kostenlos, Sponsoren bezahlen die Getränke. Der Termin steht jetzt fest: 17. Juni 2010 ab 19h im RheinEnergie Stadion. Wichtig: Ab dem 15.03.2010 kann man sich anmelden. Und da die Veranstaltung letztes mal innerhalb von 24 Stunden ausgebucht war, sollte man sich den 15.03.2010 im Kalendar notieren.
• Der Hitmeister e-Commerce Day richtet sich an Online-Händler, Shopbetreiber sowie e-Commerce Dienstleister. Es wird relevante Fachvorträge geben sowie einen Ausstellerbereich, mit Unternehmen und Dienstleistern der Branche. Sowohl das Vortragsprogramm wie auch die Liste der Aussteller wird fortlaufend ergänzt. Auch hier ist die Teilnahme kostenlos. Der Hitmeister e-Commerce Day findet am 13. März 2010 statt, eine kostenlose Anmeldung ist ab sofort möglich. Wir hoffen hier ein Forum für den Online-Handel schaffen zu können, wo die Branche zusammen kommt und über aktuelle Themen und Entwicklungen diskutiert.

Es würde mich freuen, Leser von meinem Blog auf den Veranstaltungen persönlich zu treffen!

Der Sprecher meinte auch, Quelle.de hätte in den ersten 10 Stunden der Rabattaktion 31.000 Bestellungen verarbeitet. Ich habe nochmal dazu im Vergleich die Amazon-Zahlen für den “Peak Order Day” 2008 rausgesucht:

Peak items ordered on a single day

2008: 6.3M
2007: 5.4M
2006: 4.0M
2005: 3.6M
2004: 3.6M
(Quelle: TechCrunch)

Quelle hat also bei 31.000 Bestellungen pro Tag ihren Peak Order Day, Amazon bei 6.3 Millionen. Leider gibt Amazon keine Zahlen für Deutschland raus. International ist bei Amazon laut dem Segmentbericht ca. 50% (=3,15 Mio. Order). Deutschland ist davon der stärkste Markt, also hat Amazon.de am besten Tag 2008 so grob 1-1,5 Mio. Bestellungen gemacht? Das zeigt sehr deutlich, wie weit Amazon Quelle voraus ist, beziehungsweise war.

So, und jetzt weiterarbeiten!

P.S. Dies soll keine Kritik an der Quelle-Technik sein! Ein System ist immer nur für eine erwartete Obergrenze ausgelegt, die war bei Quelle einfach niedriger angesetzt. Man kann ja nicht für den maximal denkbaren Traffic-Ansturm Kapazität bereithalten. Interessant ist die erwartete Last aber schon.

Update vom 03.11.2009:
Intershop führt die Ausfälle auf eine stellenweisen Überlastung der Netze nach Fürth zurück. Die eigene Software sei zu keiner Zeit an ihre Grenzen gestossen. Am zweiten Tag wurden wohl 86.000 Bestellungen abgewickelt. Laut einem Traceroute hostet www.quelle.de bei Lambdanet. Mich würde interessieren, was die dazu sagen.

Den Mauszeiger auf pointer zu setzen sollte selbstverständlich sein. Trotzdem ist es ein über Jahre am PC gelerntes Verhalten, dass Knöpfe leicht dunkler werden, wenn der Mauszeiger über ihnen “schwebt”. Und vom gelernten Verhalten der Nutzer abweichen ist generell nicht gut. Warum im Web abweichen?

Ich habe mal im Internet geguckt, wer hovers definiert hat (beim “in den Warenkorb” Knopf auf der Artikelseite):
Amazon: nein
Otto: nein
Neckermann: nein
Hitmeister: ab dem nächsten Update

Wir überholen bald alle! Ernsthaft, dieser Effekt kostet einen Designer vielleicht 20 Minuten und hilft dem Nutzer weiter. Zwar leicht und unterschwellig, aber der Gesamteindruck zählt. Also ab ans Photoshop!

Hier ist eine Anleitung, wie man hovers hübsch in CSS löst, ohne flackern. Und wenn man schon dabei ist: am besten in den Formularen nochmal kontrollieren, dass der Beschreibungstext der Checkboxen auch klickbar ist.

Wie versprochen hier meine Folien zum Thema “Ein technischer Blick hinter die Kulissen eines Internet-Marktplatzes”.

Sobald ich meine Gedanken wieder etwas sortieren kann (02:00 Bettchen, 08:25 Abflug) werde ich noch ein paar zusammenfassende Gedanken dazu posten.

Wir haben für die ganze Nacht bis jetzt Kreditkarten bei uns ausgeschaltet. Wie hoch der Schaden ist, ist schwer zu sagen. Die meisten Kunden haben hoffentlich Lastschrift, Paypal oder ClickandBuy gewählt.

Was wir daraus lernen:

• Eigentlich sollten wir zwei Kreditkartenprocessor anbinden, damit so etwas nicht passiert. Das ist ein SPOF und wäre z.B. in der Weihnachtszeit ziemlich unangenehm.
• Die Möglichkeit, einzelne Zahlungsmethoden auszuschalten, hat gut funktioniert. Das muss aber die technische Bereitschaft machen. Eventuell sollte das über ein Admin-Interface möglich sein? Schliesslich bekommen die Leute im Kundendienst so etwas als erste mit.
• 24h Notfall-Kundendienst würde man bei einem börsennotierten Unternehmen erwarten. Gibt es aber nicht. Eventuell wechseln? Oder sich die Handynummer des CTO geben lassen…

Als kleine Anregung für andere e-Commerce Unternehmen.

Zum Video
Zum Paper, den Folien usw.

Einige gute Stellen im Video (komplett gucken lohnt aber auch):

• 01:00 Einführung in das Thema, Erfahrungen bei Amazon
• 3:00 Footcare reduziert mit einem Gutscheinfeld seine Conversion Rate um 90%
• 04:00 Microsoft reduziert sein Website-Feedback um 80%
• 07:15 Je weniger Daten man hat, um so mehr muss man schätzen. Da Menschen schlecht schätzen, sind mehr Daten immer besser
• 08:00 Was ist eigentlich mein Ziel, wie messe ich den Erfolg? Overall Evaluation Criteria
• 09:00-19:00 Arbeiten mit Statistiken
• 20:00 Wie baue ich in meinem Unternehmen eine “Data-driven culture” auf?
• 21:00 Zusammenfassung (ich würde aber trotzdem zumindest die ersten 10 Minuten und ab 20:00 gucken)

Viel Spaß damit!

P.S. Warum kill the HiPPO? HiPPO steht für Highest Paid Person’s Opinion. Die gewinnt immer, wenn es keine verlässlichen Daten gibt.

Wir haben uns dran gemacht nach und nach alle Empfehlungen aus diesen Büchern umzusetzen, und erreichen zumindest auf Hitmeister generell zumindest gute Ergebnisse. Unsere Ladezeiten auf dem Server sind auch mit 600-700ms ganz ok, da wäre es vergleichsweise teuer noch viel herauszuholen.

Als eine der letzten Baustellen war das Thema CSS Sprites dran (Beispiel siehe rechts). Eigentlich recht einfach. Man fasst möglichst viele kleine Grafiken in einer Grafik zusammen und spielt mit dem Browser, dass er trotzdem nur an den Stellen anzeigt, wo sie hinsollen. Die Vorteile: viel weniger HTTP-Abfragen. Anstatt jedes Bild einzeln zu holen, braucht der Browser nur einmal mit dem Server sprechen. Gerade bei kleinen Icons ist der HTTP Overhead hoch. Zudem ist die Summe der Bilder oft größer, als wenn man die eines packt, wegen dem Dateikopf usw. Aber das fällt nicht so ins Gewicht. Interessant ist wirklich die Anzahl der Abfragen. Das macht die Seite schneller, insbesondere bei neuen Besuchern, die keinen “warmen” Cache haben. Wir haben übrigens bei der Einführung von CSS Sprites einen merklichen Rückgang in der Anzahl der Abfragen auf unseren Bilderservern feststellen können. Die Auswirkung auf die Ladezeit hängt stark von der Internetverbindung der Kunden ab. Aber mit dem Beispiel rechts ist die Anzahl der Anfragen pro Artikelseite auf Hitmeister um ca. 15% gesunken.

Noch ein Beispiel:

Bei der Implementierung der Sprites haben wir einige Erfahrungen gemacht:

• Die Ausrede “naja das Bild wird einmal geladen dann ist es im Cache” gilt nicht. Insbesondere für Neukunden soll die Seite schnell sein.
• Es gibt Grafiken bei denen Sprites schwierig sind (Verläufe usw.). Erstmal weglassen, 80/20 Regel. Bewertungicons usw. sind quick wins.
• Man sollte nicht versuchen alle Grafiken auf der Seite in eine Datei zu quetschen. Lieber ein paar getrennte Dateien machen, z.B. eine Pro Seitentyp und eine für Header/Footer. Das erhöht die Übersichtlichkeit und Wartbartkeit.
• Unbedingt die Sprites ausgebig in verschiedenen Browser/Auflösungskombinationen testen. Insbesondere mit dem IE6 gibt es hier einige Probleme. Wir hatten regelmäßg zerhackte Seiten während der Tests. Oft hilft möglichst einfaches HTML (Manchmal auch Tabellen statt DIVs, für die alten Browser) weiter. Zudem ist es gar nicht schlecht einen einfachen ein/aus Knopf für die Sprites zu haben, wenn doch was schief geht.
• Man sollte die Icons horizontal kacheln. Spart Speicherplatz im Bild (entgegen unserem Beispiel oben). Mit so großen Flächen haben wir schlechte Erfahrungen gemacht. Lieber Streifen.
• Wenn man zuviele Bunte Sprites in eine Datei steckt, wird die Farbpalette (und damit die Datei) größer. Dann lieber nach Farben trennen und z.B. keine Photos mit reinnehmen.

Insgesamt sind geschickt eingesetzte CSS Sprites ein ziemlich dankbarer Weg, um nochmal einige hundert Millisekunden Ladezeit bei einer Seite wegzubekommen. Der einzige Nachteil ist, dass die Erstellung und Wartung der Seite etwas mehr Zeit in Anspruch nimmt, da die Sprite-Datei erstellt und gepflegt werden muss. Aber bei high-traffic Seiten lohnt sich das bestimmt.