Auf einer Konferenz habe ich einen Vortrag von dem Usability-Guru Jakob Nielsen gehört. Der brachte mich auf die Idee mit Software und Webcams richtige Usability Tests unserer Seite durchzuführen. Bisher hatten wir das immer eher informell gemacht. Zusätzlich machen wir natürlich jede Menge rein IT-gestütztes statistisches A/B-Testing.

Wir haben zum Relaunch von Hitmeister relativ ausgiebige Usability Tests mit Probanden in unseren Büros durchgeführt. Zum Glück hatte eine neue Mitarbeiterin von mir, Jennifer, während ihres Studiums erste Erfahrungen mit der Materie sammeln können.

Zur Durchführung der Tests haben wir uns nicht einer Agentur anvertraut, sondern selbst die notwendige Ausrüstung gekauft und die Tests selbst durchgeführt. Das kostet vielleicht € 1.500 für die Ausrüstung plus noch mal ein paar hundert Euro für die Probanden.

Die notwendige Ausrüstung:

• das Morae Bundel von Camtasia für ca. € 1.300
• eine Logitech-Webcam für ca. € 100
• und ein alter Laptop wurde als Testrechner umfunktioniert.

Die Probanden haben wir über www.catfire.net gefunden. Dort kann man für € 49 im Monat in einer Datenbank potenzieller Probanden suchen und diese nach einigen Kriterien aussuchen. Wir haben Personen gesucht, die repräsentativ für unsere Zielgruppe sind, sowie einige „Ausreißer“ (besonders jung, besonders alt usw.).

In einem Konferenzraum bei uns wurde für die Dauer der Tests ein kleines Labor eingerichtet. Jennifer saß mit den Teilnehmern im Raum und ist die Fragen durchgegangen. Die Produktmanager, Entwickler und Grafiker konnten sich jederzeit mit dem Morae Observer mit in die Aufnahmen einklinken und den Nutzer sehen und hören. Zusätzlich sieht man den Bildschirm und alle Eingaben. Die Tests wurden am Ende protokolliert und es wurden direkt konkrete Maßnahmen abgeleitet.

Wir haben während den letzten 8 Wochen des Entwicklungsprozesses jeden Freitag 3-4 Probanden da gehabt, um die Seite zu testen. Während am Anfang eher generelle Aufgaben getestet wurden, ging es in den späteren Tests immer tiefer ins Detail. Alle Produktmanager haben Aufgaben an Jennifer herangetragen. Die meisten Bereiche, wo unterschiedliche Meinungen zur besten Umsetzung herrschten, wurden direkt getestet. Genauso auch größere Änderungen. Die Ergebnisse der Tests sind dabei direkt in den Entwicklungsprozess wieder eingeflossen und wurden – wo möglich – direkt noch mal getestet.

Dieses Vorgehen hat bei uns extrem gut funktioniert. Die Tests ist wesentlich „runder“ rausgekommen als jemals ein Relaunch zuvor. Die Konversionsrate ist gestiegen, die Supportanfragen sind runter und alle sind glücklich.

Eine Anmerkung noch: wir waren unsicher, in wie weit man Testern unfertige Seiten zeigen kann. Das war überhaupt kein Problem. Fehlende Bilder, kaputte Bereiche usw. wurden geflissentlich ignoriert. Man kann also sehr früh testen, die Tester sind sehr tolerant!

Ich kann jedem Projektleiter, der noch 2-3k in seinem Finanzkrisen-strapazierten-Budget übrig hat, sich die Ausrüstung zu kaufen und in diese Kamera-Tests zu investieren. Die Ergebnisse sind wirklich extrem hilfreich.

P.S. Bevor jemand fragt: Nein dies ist kein gekaufter Beitrag von TechSmith, ich bin begeistert!

Wenn eine Webseite anfängt viele Daten auszuliefern ist es irgendwann sinnvoll diese Tätigkeit einem spezialisierten Anbieter zu überlassen. Betreiber von Content Delivery Networks (CDN) stellen in Rechenzentren auf der ganzen Welt Server auf und versprechen der Webseite, den Content von einem Server auszuliefern, der möglichst nahe beim Kunden steht. Der Betreiber der Webseite verspricht sich hiervon 2 Vorteile: 1) der Kunde bekommt seine Daten schneller und 2) der Betreiber der Website braucht selber keine großen Kapazitäten vorhalten, sondern überlässt die Skalierung dem CDN. Wie groß der Effekt von Punkt 1 ist, hat Tom Leighton von Akami kürzlich in der ACM-Queue vorgestellt:

Die kürzeren Paket-Laufzeiten sind für Websites wie unsere, die fast ausschliesslich Kunden in Deutschland oder Europa haben, irrelevant. Wegen Punkt 2, der Skalierung, hatte ich mir mal CDNs angeschaut aber mich dann doch dagegen entschieden. Die Traffic-Menge ist noch nicht so signifikant.

Amazon hat mit CloudFront einen Dienst vorgestellt, der einem erlaubt auf S3 eine “Optimierungsschicht” vorzulegen. S3 liefert die Daten von da aus, wo der Betreiber sie hochgeladen hat. CloudFront nimmt diese Daten und liefert sie von da aus, wo der Kunde sitzt.

Ich habe mir mal die Preise von Amazon CloudFront genauer angeschaut und sie mit einem anderen CDN vergleichen. Welches darf ich leider nicht sagen, es war aber eher ein mittelpreisiges. Nennen wir es einfach X-CDN. Was mir dabei aufgefallen ist: CloudFront ist wesentlich günstiger als X-CDN für große Dateien. Aber für kleine Dateien ist es ziemlich teuer!

So viel kostet die Ausliferung für 1.000.000 Abfragen für einige typische Dateigrößen:

Die Preisliste bei X-CDN war unverhandelt, das heisst da geht bestimmt auch noch was.

Mein Fazit: Amazon CloudFront ist gar nicht so günstig, wie oft angenommen wird (mehr dazu siehe Eckenfels IT-Blog oder Blogaddict. Netzwertig hatte die Preise schon korrekt eingeschätzt). Bevor man blind zu Amazon CloudFront rennt sollte man durchrechnen, ob sich ein normales CDN wie Akamai, Panther Express oder Limelight sich nicht doch rechnet und dort entsprechende Angebote einholen. Der Setup ist m.E. dort auch oft einfacher, da man nicht über S3 gehen muss und die Gebühren sind - wie man sieht - je nach Nutzungsverhalten nicht unbedingt höher.

Nachtrag Wenn ein Anbieter von CDNs hier seine Preise offen legen möchte, trage ich das gerne nach!

Wir haben vor kurzem die ersten Hitmeister Optimierungs-Tage (HOT 1 - Abkürzungen sind ganz wichtig) durchgeführt. Ich wollte hier mal von unseren Erfahrungen berichten.

Ziel der HOT: Jedes Software-Projekt hat Code, der Liebe braucht. Das sind Stellen die undokumentiert sind, selten getestet, trotzdem wichtig und zentral, für die sich alle ein bisschen schämen und wo keiner ran will. Die sollte “man” mal aufräumen. Je länger diese Problemstellen ignoriert werden, desto größer werden sie. Eine gute Analogie sind Schulden, die immer weiter anwachsen. Im Englischen nennt man das auch technical debt oder karmic debt. Wir wollten bei Hitmeister mal was für unser Karma tun. Das Ziel war es den Code aufzuräumen, zu dokumentieren, Tests zu schreiben und zu refactoren. Also lauter Sachen erledigen, die im Tagesgeschäft öfters liegen bleiben. Und das in einem Sprint-artigen Modus.

Vorgehen

• Wir haben uns für HOT 1 zwei Tage Zeit genommen. Innerhalb der Firma wurde vorher kommuniziert, dass die Technik an den zwei Tagen nur für absolute Notfälle zur Verfügung steht und ansonsten nicht ansprechbar ist.
• Im Vorfeld der HOT wurden in einem Wiki-Dokument Ideen gesammelt, was man angehen könnte. Zu jeder Idee wurden die erwarteten Auswirkungen dazu geschrieben.
• Am Vormittag des ersten Tages wurden die Ideen diskutiert und evaluiert. Es haben sich Zweierteams gebildet, die die verschiedenen Baustellen angegangen sind. Dabei wurde nicht jede Aufgabe zu zweit gemacht. Manche Aufgaben wurden wirklich im pair-programming-Stil gelöst, andere waren eher do-and-review.
• An den folgenden 1,5 Tagen haben die Teams dann - soweit möglich - die Aufgaben gelöst und umgesetzt. Hierbei gab es recht viel Diskussionsbedarf.
• Nach den HOT wurden dann die Ergebnisse besprochen und ein Fazit gezogen.
• Einige Arbeiten sind leider nicht fertig geworden in den zwei Tagen, das hat sich dann noch etwas fortgezogen.

Ergebnis: Wir haben in den zwei Tagen über 5.000 Zeilen Code gelöscht (echten Code, keine Libraries), ca. 200 Todos entfernt und unzählige Tests und Kommentare geschrieben. Nach ersten Tests sollte die Menge an SQL-Abfragen um etwa 20% sinken, die memcached-Aufrufe um etwa 30%.

Fazit: Die ersten Hitmeister Optimierungs Tage waren sehr erfolgreich. Wenn Anfang Dezember der Code live geht sollte das die Seitenladezeit und die Serverlast etwas reduziert. Was aber wesentlich wichtiger ist, ist dass der Code wieder sauberer, lesbarer und robuster geworden ist. Ein zusätzlicher Vorteil der HOT war, dass alle Entwickler viel “fremden” Code gelesen haben und so ein besseres Verständnis der Plattform bekommen haben. Weitere Ergebnisse:

• Die Arbeit war teilweise zu viel, teilweise auch zu wenig. Die Aufgaben waren nicht so aufgeteilt, dass alle in 2 Tagen fertig wurden bzw. auch 2 Tage gebraucht haben. Das sollte besser eingeteilt werden.
• Die Arbeit in Teams, im Sprintmodus, ist sehr gut angekommen und hat gut funktioniert. In Zukunft macht dieses Vorgehen für abgeschlossene Komponenten viel Sinn.
• Ein grosser Batzen Arbeit im ersten HOT war die Vorsortierung der TODOs im Code. Beim nächsten HOT wird da dann erst aufgeräumt.
• 100% frei von Tagesgeschäft waren die Tage nicht, aber es war nur “unaufschiebbares”. Unsere Firma kann mal ein paar Stunden ohne Technik laufen…

In Zukunft werden wir ca. einmal im Monat einen HOT machen, der sich dann aber stärker auf wirkliches refactoring konzentrieren soll. Im zweiten HOT (oder HRT) sollen dann die vorsortierten Todos durchgegangen werden. Ich bin von unseren Erfahrungen sehr angetan, und würde jedem Team raten so etwas mal zu probieren.

Frontend Performance-Optimierung ist ja derzeit ein grosses Thema, weil es viel bringt (Hintergrundinfos: hier, hier, hier). Die letzten paar ms Ladezeit auf Serverseite rauszukitzeln wird disproportional teuer. Ein Grossteil der Ladezeit entsteht eh durch Browser-Requests und Ladezeiten, die kann man angehen. Dazu gibt es aber genug Literatur.

Oft werden Performance-Optimierungen durch Werbetags zunichte gemacht, die oben in der Seite eingebaut werden. Das sind meistens kleine Stückchen JavaScript, die von einem Vermarkter kommen. Diese rufen einen Adserver auf, der wiederum andere JavaScripts einblendet, zum Beispiel von einem Werbekunden, der wiederum ein IFRAME schreibt. Oft werden da 4-6 Requests gemacht, nur um ein Bild anzuzeigen. Dazu kommen Targeting Skripte von nugg.ad oder wunderloop sowie Tracking-Pixel der IVW und AGOF.

Das schlimme daran: auf einmal bestimmt die Latenz von fremden Servern die Ladezeit der eigenen Seite. Die eigenen Server können noch so optimiert sein, wenn die Server von einem Werbetreibenden in die Knie gehen ist die eigene Seite langsam oder platt. Und durch die Netzwerke ist es gar nicht so einfach rauszufinden, wer eigentlich gerade verantwortlich ist für die schlechte Performance von srv42.freeadserver4you.net.

Auf Hitflip hatten wir Fälle, wo der Seitenaufbau um 15 Sekunden verzögert wurde durch schlechte AdTags. Da hilft dann keine Frontendoptimierung. Und manchmal klappen die dann gar nicht, wie heute morgen auf Spiegel Online:

Was kann man dagegen tun?

• Schmerzensgrenzen definieren. Was für eine Verzögerung der Seite bin ich bereit zu akzeptieren?
• Beim Vermarkter das Thema ansprechen. Gerne hier auf Google AdSense verweisen, mit denen hatten wir noch nie Probleme hinsichtlich Ladezeit (Ormigo ist da übrigens auch top). Wenn ich bei Google € 2 eCPM bekomme und bei einem Vermarketer € 2,50 kann es besser sein die € 2 zu nehmen und eine schnelle Seite haben. Für mich ist die schlechte Technik ein deutlicher Wettbewerbsnachteil bei einigen Vermarktern.
• Unbedingt einen grossen roten Knopf im eigenen Backoffice bauen, der sofort alle Werbung von der Seite entfernt. Es bringt nichts, wenn man erst in irgendwelchen Templates rumprökeln und dann ein Update fahren, um ein langsames Banner zu entfernen. Sobald ein Banner Performanceprobleme bringt, muss es raus. Und da man das oft nicht Banner-spezifisch steuern kann, braucht man einen grossen roten Knopf.
• Es sollte beim Vermarkter einen Ansprechpartner für solche Probleme geben. Das muss schnell gehen und kann nicht über das Account Management gehen.
• Wenn möglich mit dem Vermarkter bezüglich Einbindung verhandeln. Muss es der dicke AdTag aus dem Jahre 1998 sein, der 12 redirects macht und noch 4 Tracker lädt, oder geht es nicht auch etwas schlanker?
• Und zuletzt, wenn das Design es zulässt: mit CSS und JS Tricks die Banner als letztes laden, auch wenn die oben sind. Dann gehen zwar Werbeeinnahmen flöten, aber die Nutzer werden es einem Danken.

Es wäre eigentlich mal cool Messungen hinsichtlich der Performance von verschiedenen Vermarktern zu machen und ein Ranking zu erstellen. Wenn mir mal sehr langweilig ist, gehe ich das an… Eigentlich ist ja Vermarktung nicht unser Geschäft.

Wir haben einen formalen Bereitschaftsdienst für unsere IT eingeführt. Ich würde gerne unsere ersten Erfahrungen teilen und nach Input fragen.

Bis vor kurzem hatten wir keinen festen Bereitschaftsdienst. Ein lobenswerter Kollege (dessen Blog ich gerade nicht finde) und ich waren beide ständig in Alarmbereitschaft. Sobald die SMS von Serverguard ankamen ging die Telefoniererei los. Wer hat Zeit, wer hat Netz?

Mit der Zeit, mit mehr präventiver Arbeit und vor allem mehr Hardware wurden die Ausfälle immer weniger. Trotzdem ist es auf die Dauer natürlich kein Zustand, dass keiner so wirklich verantwortlich ist, sondern jeder ein bisschen. Vor allem wenn immer mehr Partner auf die Plattform zugreifen.

Wir haben unseren Bereitschaftsdienst wie folgt strukturiert.
Den Rest des Beitrags lesen »

Ich rieche hier einen Trend. Ich hatte vor einiger Zeit über das Thema Skalierung mit dem Observer Pattern geschrieben. Jetzt entdecke ich auf der (guten aber doch recht generellen) Liste “Startup Scalability Strategies” den Punkt 5: “Scalable startups stay away from building synchronous coupling”. Etwas ähnliches hatte ich in meinem Artikel empfohlen.

Unsere Observer verarbeiten derzeit übrigens etwa 1,6 Mio. Nachrichten pro Tag. Das macht mir aber keine Sorgen. Die Verarbeitungskapazität skaliert fast linear mit der Anzahl der Server. Und wenn das nicht mehr reicht steigen wir auf eine dedizierte Messaging-Software um.

Auf einer Konferenz habe ich mich mit einem Systemarchitekten von LinkedIn unterhalten, der viel im Silicon Valley berät. Wenn er ein neues Unternehmen in Sachen IT-Skalierung analysiert, ist seine erste Frage wohl immer “sync or async?”. Ersteres würde jede Skalierungsbemühung deutlich teuerer machen.

Ich glaube das wird noch ein großer Trend im Web-Operations Bereich. Jedes Startup, das wachsen will, sollte lose gekoppelte Systeme bauen, die einzeln optimierbar und horizontal skalierbar sind. Ihr habt es hier zuerst gelesen!

Wenn ich jetzt noch rausfinden würde, welches unserer lose gekoppelten Systeme heute die Ladezeit der Seite so schwanken lässt, könnte ich auch ins Bett gehen:

P.S. Die lange Pause beim bloggen tut mir Leid, mein “day job” hält mich auf Trab!

Update

Flickr findet Queues und asynchrone Prozesse auch cool.

Wie in MySQL Skalierung Teil 1 versprochen hier noch etwas Code sowie eine tiefere Einführung.

Den Rest des Beitrags lesen »

Fast jeder, der Web-Anwendungen baut, stellt schnell fest dass es teuer und kompliziert ist Datenbanken zu skalieren. Webserver sind einfach. Storage ist halbwegs einfach. Datenbanken sind schwierig.

Im Rahmen des Hitmeister-Wachstums habe ich mich recht intensiv mit dem Thema beschäftigt.
Ich möchte in dieser kleinen Serie verschiedene Themen durchsprechen, die bei der Verteilung von Datenbanken immer wieder aufkommen. Heute Teil 1: die Verteilung von Lese- und Schreibzugriffen.

Der erste Schritt bei der Skalierung von mySQL, wenn man von 1 auf 2…n Server geht, ist die Lese- von den Schreibzugriffen zu trennen. Das geht auf 2 Arten:

• Ein Proxy, wie MySQL Proxy oder Continuent/Sequoia
• In der Applikation selbst.

Die Proxies

Continuent bietet eine Art Proxy an. Die Lesezugriffe werden auf n Server verteilt, Schreibzugriffe gehen auf alle. Das System bietet eine Reihe von management Tools dazu. Die (für mich disqualifizierende) Schwäche wird sichtbar: der langsamste Server im Cluster determiniert die Geschwindigkeit des Gesamtsystems. Continuent ist für hot fail-over Geschichten ganz gut, bei der Skalierung hilft es nicht. Das Gesamtsystem schafft wohl auch nur ca. 6-7K Queries pro Sekunde. Alexander Windbichler hat von ähnlichen Erfahrungen berichtet.

MySQL Proxy ist ein Projekt von Jan Kneschke (berühmt für seinen exzellenten Lighttpd). Mit der Programmiersprache LUA kann man MySQL Proxy diverse Tricks beibringen, u.a.das Verteilen von reads und writes auf verschiedene Server. Wir mussten MySQL Proxy jedoch leider verwerfen. Das Problem sieht man im folgenden Diagramm recht schnell (aus einem Post über MySQL Proxy geliehen, danke!):

Sobald man einen minimalen Replikationslag hat, sind die Antworten nicht mehr konsistent. Und einen Lag hat man in MySQL sehr schnell zwischen Master und Slave, gerade wenn man schwere Queries hat. Das heisst man muss dann entweder Kommentare o.ä. in die SQLs einbauen, um manche reads trotzdem auf den Master zu schicken, oder den Applikationscode so umschreiben, dass er mit inkonsistenten Antworten zurecht kommt. In unserer Applikation liefert jeder Add und Edit Service das Objekt zurück, was er gerade modifiziert hat. Da reichen wenige 100 ms Lag aus, und das ganze fliegt uns um die Ohren.

Die eigene Applikation umbauen

Am Ende haben wir uns dafür entschieden unseren eigenen read/write Handler zu schreiben. Unsere Entwickler können bei Queries entscheiden, ob diese auf „write“, „read“ oder „auto“ gehen. Write und Read erzwingen eine entsprechende Verbindung auf den jeweiligen Server. Auto lässt die API entscheiden: Ist die Query in einer Transaktion, landet diese immer auf write, sonst auf read.

Durch das lazy loading der Datenbankverbindung in Zend in Kombination mit einem ausgefeilten Caching brauchen unsere Seiten oft gar keine Verbindung auf den Master, sondern nur eine auf den Slave. Das lässt sich natürlich sehr gut skalieren.

Wir sind mit diesem Ansatz sehr gut gefahren, bisher.

Ausblick

Im nächsten Post werde ich über Sharding und Partitionierung sprechen, inkl. einer Analyse der MySQL Bordmittel sowie selbstgebauter Lösungen. Stay tuned!

Die OSCON von O’Reilly ist einer der führenden Konferenzen für Open Source. Es ist für mich sehr spannend das Material zu durchstöbern, aber die Masse ist schier überwältigend (ca. 40 Stunden Vorträge).

Glücklicherweise hat sich Gregg Pollack die Mühe gemacht das ganze auf 37 Minuten runter zu schneiden. Mir geht es etwas zu oft um Ruby, aber interessant ist es trotzdem: Oscon in 37 minutes.

Das war für mich ein super Weg, um dieser Masse Herr zu werden. Video gucken, embedded Link zur Seite des Vortragenden anklicken, Präsentation anschauen, lernen. Super.

Andre hat - nach dem großen Erfolg 2007 - die Superblogs 2008 gestartet. Ich habe mich mal in der Kategorie Technik selbst nominiert. Ohne große Gewinnchancen (bei meiner Update-Frequenz), aber man kann ja mal hoffen… Dort ist übrigens schon ein “Jans Technik Blog”, das bin ich aber nicht.

Wer also selbst einen Blog hat kann überlegen ob er nicht auch mitmachen möchte. Zu gewinnen gibt es - neben einem feinen Pokal und € 200 - auch Ruhm, Ehre, Dankbarkeit und Deeplinks.