Velocity-Konferenz will das Web beschleunigen

Webentwickler, Admins und Infrastruktur-Profis spricht der Verlag O’Reilly mit seinen „Velocity“-Konferenzen an. Erstmals waren „Web Performance and Operations“ auch in Europa ein Thema.

Nachdem die Velocity seit 2008 jährlich in Kalifornien über die Bühne geht und im letzten Jahr erstmals in China gastierte, fand Anfang November in Berlin die erste „Velocity Europe“ statt. Die Vorträge und Workshops handelten davon, wie man Online-Dienste auf Geschwindigkeit und Zuverlässigkeit trimmt. Bekanntester Name im Organisationskomitee ist Steve Souders, unter anderem Entwickler des Performance-Messwerkzeugs YSlow.

Steve Souders kündigt auf der Bühne den furiosen Vortrag Artur Bergmans über „Full Stack Awareness” an.
Bild: O’Reilly Auf Geschwindigkeitsprobleme beim Smartphone-Surfen konzentrierte sich Joshua Bixby vom Performance-Optimierer Strangeloop. Vereinfachte Mobil-Websites sind seinen Untersuchungen nach unbeliebt. Geschwindigkeit schlägt sich unmittelbar in den Umsätzen nieder: Bixby verzögerte bei einigen Besuchern die Auslieferung der Websites um moderate 0,2 bis 2 Sekunden und verzeichnete spürbare Verluste – und zwar langfristig: Genervte Besucher bleiben weg. Ähnliche Testergebnisse verzeichnete Tim Morrow vom Wettanbieter Betfair. Zu den Bremsen, die er beseitigte, zählten beispielsweise automatisch hin- und hergeschickte Cookies bei Grafiken, die teils ein kleineres Volumen als der HTTP-Overhead hatten.

Mit semantischen Finessen wartete Jon Jenkins von Amazon auf. Im Unterschied zu „speed“ sah er in „velocity“ nicht nur pure Schnelligkeit, sondern eine zielgerichtete Geschwindigkeit. Dabei spielt auch Benutzerfreundlichkeit – User Experience – eine Rolle. Als Strategie empfiehlt er schnelles Reagieren, das besser als allzu überlegtes Handeln funktioniert; selbst ein Anfänger würde im Schach gewinnen, wenn er immer zweimal hintereinander ziehen dürfte. Letztlich predigte Jenkins das Credo der agilen Software-Entwicklung: Durch häufiges Iterieren und inkrementelle Änderungen die richtige Richtung finden und dabei die Kosten von Fehlern reduzieren.

Webseide

Jenkins war auch gekommen, um Amazon Silk vorzustellen. Der von ihm neu entwickelte Browser, der sich mit Chrome das WebKit-Herzstück und die V8-Engine teilt, debütiert dieser Tage auf dem Tablet Kindle Fire. Anhand von Zahlen aus dem von Steve Souders gegründeten HTTP Archive, das Daten über die Größe von Webauftritten erfasst, veranschaulichte Jenkins die wachsende Komplexität: Durchschnittlich bestehen die etwa 16 000 beobachteten Sites aus einem Viertel mehr Daten als noch vor einem Jahr. Amazon.de fordert derzeit 96 Dateien von 12 Domains an und holt 530 KByte aus dem Netz – der Durchschnitt liegt sogar bei 892 KByte. Dennoch werden Webseiten eher schneller als langsamer.

Auf mobilen Geräten verschärfe sich das Problem komplexer Webseiten. Dazu trage etwa die geringere Cache-Größe des Browsers bei; Stromspartechniken wie der Power Save Mode bei WLAN und die Radio Resource Control verzögern den Download-Beginn. So lade die Amazon-Startseite auf dem PC in drei Sekunden, auf dem iPad benötige sie doppelt so lang, auf dem Smartphone seien es bereits zehn Sekunden.

Silk setzt daher auf eine „split browser architecture“, die ähnlich wie bei Opera Mini einen Teil der Arbeit auf den als Proxy zwischengeschalteten Amazon-Diensten erledigt. Diese kümmern sich etwa um Bildkompression, um Caching, können einen Teil des Renderings übernehmen und versuchen, die nächsten Downloads vorherzusagen – laut Jenkins in Summe eine Art Compiler für Webseiten. Browser und Amazon-Cloud kommunizieren mit Hilfe des HTTP-Ersatzes SPDY, das den zeitraubenden TCP-Handshake erübrigt, unterschiedliche Prioritäten bei den Downloads kennt und grundsätzlich verschlüsselt. Silk kann jedoch wie jeder andere Browser auch direkt mit dem Internet kommunizieren; bei SSL-verschlüsselten Verbindungen ist dies das Default-Verhalten. Die Bürgerrechtsorganisation EFF zeigte sich trotz einiger Bedenken „grundsätzlich zufrieden“ mit Silks Datenschutz.

Auch drei der bereits etablierten Browser-Hersteller waren zu Gast: Entwickler von Firefox, Chrome und Opera zeigten ihre jeweiligen Strategien zur Performance-Verbesserung, etwa bei der Optimierung von Netzwerkverbindungen oder beim Feintunen des JavaScript-Compilers.

JavaScript-Tücken

Wie diese arbeiten und mit welchen Schwierigkeiten sie zu kämpfen haben, erläuterte David Mandelin von Mozilla. JavaScript-Engines wie Firefox’ TraceMonkey oder Chromes V8 versuchen, den untypisierten JavaScript-Variablen beim Kompilieren Typen zuzuweisen, was ähnliche Geschwindigkeiten wie in C ermöglicht. Das funktioniert jedoch nur, wenn die Entwickler typstabil programmieren und nicht etwa in einer Zahlenvariable einen String abspeichern. JavaScript-Codern gab Mandelin außerdem mit, keine lückenhaften Arrays zu produzieren, nicht zu viele Objekte zu erzeugen – und vor allem kein eval() zu verwenden.

Mit den Tücken der Performance-Messung von Webseiten befasste sich der Berater Stephen Thair. Die Spanne dessen, was sich messen lässt, reicht von der Reaktionszeit des Webservers über die Zeit bis zum ersten Byte (TTFB) bis hin zur komplett geladenen und gerenderten Webseite. Entsprechend bieten sich unterschiedliche Werkzeuge für Beobachtungen und Experimente an, etwa Skripte im Client, Netzwerk-Sniffer oder Proxys. Doch Vorsicht: Die Messwerkzeuge können die Beobachtung beeinflussen.

„Unser Stack ist auf Sch… gebaut“ – mit einem fundierten Rant erntete Artur Bergman mehrmals Applaus. Der szenebekannte Gründer des Content-Delivery-Networks Fastly teilte nach vielen Seiten aus: Linux? Für Desktop-Rechner entwickelt, nicht für Server. Ubuntu? Ist „off in crazy land“. Die Multiprozessor-Speicherverwaltung NUMA? Murks. MongoDB? Eine Datenbank, die bei langen Spaltennamen mehr Ressourcen verbraucht, kann man nicht ernst nehmen. Node.js? Interessant, hat aber die schlechteste Speicherverwaltung aller Zeiten. Überhaupt fehlt es bei Open Source an Qualität, und die Gruppenprozesse nerven, aber immerhin kann man in den Code schauen und zum Beispiel einen Kernel selbst anpassen und kompilieren.

Ein kleiner Ausstellerbereich ergänzte die Keynotes und Workshops; zu sehen gab es dort vor allem Stände von Infrastrukturanbietern, Content-Delivery-Networks und Dienstleistern für Performance-Messungen und Optimierungen. Die nächste Velocity findet im Juni in Kalifornien statt, einen Termin für Europa gibt es noch nicht. (heb)

www.ct.de/1125028