PHPGangsta - Der praktische PHP Blog

Speeeed! Genauso wie der letzte Tag geendet hat beginnt der zweite.

Steve und John eröffnen den zweiten Tag mit einer kurzen Opening Keynote, gefolgt von Jeff Veen der von den Problemen berichtet als Typekit einige Tage vor Weihnachten vom Erfolg überrollt wurde, und wie innerhalb eines Wochenendes das Problem kurzerhand gelöst werden musste und auch wurde. Das Grundproblem waren die vielen Kits die nicht zeitnah in das CDN gebracht werden konnten, und sich so eine massive Queue aufgebaut hatte. Ich mag solche praxisnahen Einsichten sehr. Eine These bzw. Grundsatz der Kultur der Firma: IRC über E-Mail. Im IRC kann man kurze Fragen und Antworten schreiben wie „no“. In E-Mails haben wir irgendwie den Zwang, formal zu schreiben und viele Sätze zu bilden. Das bläht schnelle interne Kommunikation unnötig auf.

Die folgenden zwei Lighning Demos stellten kurz Dynatrace Ajax Edition und FITB vor. Dynatrace ist eines der führenden Tools um sehr tief in Browser hereinschauen zu können (auch IE6/7!) und so Reflowes, Repaints usw sehen zu können und komfortabel Performance-Bottlenecks zu finden, die man ohne solche Einsichten nicht oder nur sehr schlecht eingrenzen kann. FITB ist ein PHP-basiertes Tool um Netzwerke zu monitoren und Graphen zu erstellen. Mit einer Zeile in der Konfiguration werden neue Switches hinzugefügt, alle aktiven Ports werden automatisch erkannt und Graphen erstellt.

Weiter ging es mit Arnaud Becard von ip-label, er zeigt auf wie wichtig Real User Monitoring (RUM) ist, und warum das wichtiger ist als künstliche Messwerte von einfachen Tools. Gerade unterschiedliche Bandbreiten (schnelles DSL, ISDN, Mobile), aber auch Browsergenerationen einzeln zu betrachten ist sehr sinnvoll. Auch Kleinigkeiten wie beispielsweise der Umstieg von HTTP 1.0 auf HTTP 1.1 mit KeepAlives kann bis zu 30% Performance Unterschied bringen!

John, einer der Mitorganisatoren und Moderatoren zeigt auf wie unmöglich es ist, Systeme ohne Fehler zu erstellen. Gerade bei Systemen wo man wirklich darauf achtet wie Amazon, Blackberry oder auch die Challenger Katastrophe zeigen dass man mit Ausfällen leben muss, es geht einzig darum sie möglichst schnell in den Griff zu bekommen und die Konsequenzen gering zu halten. Dazu gehören neben vielen anderen Dingen auch vor allem die Überlegungen vorher was alles passieren könnte (was mit viel Erfahrung natürlich besser gelingt), aber auch ein durchdachtes Troubleshooting und Kommunikation. Was passiert wenn das Netz ins Rechenzentrum ausfällt, möchte man dann Shellkommandos durchs Telefon durchsagen oder möchte man vor Ort einen Notfallplan liegen haben? Das Lernen aus Vorfällen ist auch ein sehr wichtiger Punkt. Messen ob Gegenmaßnahmen in der Zukunft gegriffen haben. Vor großen Änderungen und Deploys schreibt jeder Mitarbeiter eine Liste mit Dingen die passieren könnten…Wenn man noch nie einen Ausfall hatte wird der nächste Ausfall schlimm werden, wenn man öfter Ausfälle hat wird der nächste schnell und gut gelöst. Übung und Vorbereitung macht den Meister!

Dann betrat Artur Bergmann die Bühne, ein Veteran der Velocity-Konferenzen. So ganz genau kann man seinen Vortrag nicht zusammenfassen, im Prinzip ging es glaube ich darum zu zeigen dass man sich mit der Materie auseinander setzen sollte mit der man arbeitet, und generell sind Computer, Kernel und Tools kacke bis auf sehr wenige Ausnahmen. Wenn man in irgendwelchen Graphen Load-Spitzen erkennt tippt man zuerst auf die Applikationen, aber auch der Linux-Kernel ist laut Artur kaputt und schlecht dokumentiert, man sollte sie nie auf Magic verlassen. Seinen alten Jeep mag er deutlich lieber als einen Porsche Cayenne, da man ihn leicht verstehen, reparieren und erweitern kann. Ich hätte auch mal mitzählen sollen wie oft er „What the fuck“ gesagt hat 😉

Bei Spil Games, einem der führenden Spieleanbieter hat man mit 140 Millionen Unique Users pro Monat zu tun, und um User zu binden und zu gewinnen benötigt man vor allem eines: Geschwindigkeit! Wenn ein Spiel erst nach 15 Sekunden startet ist ein User wieder weg, wenn es nach 7 Sekunden da ist und das schneller ist als bei der Konkurrenz, dann bleiben sie und spielen wie verrückt. Dabei gilt es auch an langsame Verbindungen zu denken, Usern in Brasilien sollte man beispielsweise vorzugsweise bandbreitenschonende Spiele anbieten. Benutzer sind der Schlüssel, die Erfahrung der Benutzer, und dazu gehört eine gute Performance. Performance ist kein Projekt das ein Ende hat, sondern eine andauernde Mission. Focus: 5 Mitarbeiter wegschicken und nur an Performance arbeiten lassen ab und zu, aber auch permanent dran arbeiten. Wenn man einen Request um 4Sekunden verkürzen kann und das 1 Tag dauert: Machen! Messen messen messen und nie wieder langsamer werden, nur schneller, es gibt keine Ausnahmen und Entschuldigungen. Einblicke gewinnen, Multi Varianten Tests und A/B Tests, Aufschlüsselung von Messdaten nach Land, Spieltyp usw., auch in Staging Environment messen vor Deploy… Lernen: Bücher, Velocity Videos, Google Analytics Site Speed, CDNs, head.js, css/js/images kombinieren Low hanging fruits finden… Von 5s DOM Load auf 360ms DOM Load, und von 11s Full Page Load auf 4s Full Page Load.. An durchschnittlichem Samstag spart das den Usern 4 Jahre Wartezeit!

Beim nächsten größeren Block haben sowohl Opera als auch Chrome und Firefox über aktuelle Entwicklungen im Bereich Performance erzählt.

Opera arbeitet an SSL False Start, verbesserten Netwerkstack, Strict Transport Security, Opera Turbo, Opera Dragonfly als Remote Debugger vor allem für mobile Geräte, Opera Mini, angenehmeres und ruckelfreies Scrollen gerade auf schwachbrüstigen Geräten usw.

Tony Gentilcore von Google berichtet über Chrome Features, von Chrome Frame für den IE mit Aufforderung im IE zur Installation, <link rel=“prerender“>, webkitvisibilitychange event, Developer Tools verbessert (Timeline, Memory Profiler), requestAnimationFrame und einiges mehr.

Chris Heilmann von Mozilla gab bewußt keinerlei Zahlen im Detail für Firefox, denn die sind in sehr wenigen Wochen schon wieder outdated. Generell berichtete er von der Wichtigkeit von Browsern, dass es dem User generell freisteht welchen Browser er benutzt. Kurz riss er einige neue Features an wie die Web Console, Style Inspector, Scratchpad, Navigating visually, Sourcemapping im Javascriptbereich (Coffeescript), TILT um HTML-Verschachtelungen darzustellen.

Ramon erzählte über Hyves, dem sehr beliebten holländischen Sozialen Netzwerk. Bei 16,7 Millionen Niederländern hat Hyves 9,7 Millionen Accounts und 2 Millionen Unique Visitors pro Tag. Die Last wird mit 3500 Servern in 3 Rechenzentren bewältigt, 6Gbit Bandbreite, 12 Entwickler, 33 Entwickler. Einer dieser Entwickler hat an einem Wochenende HipHop for PHP ausprobiert und dabei eine 3-7 fache Performance feststellen können. Mit dieser Aussicht macht man sich daran es für einen Teil der Seiten einzusetzen, dabei entstand ein Binary von 750MB Größe, das auf 700 Frontend-Server deployed werden mußte. Die Kompilierung dauert anfangs 40-60 Minuten, nach massiven Verbesserungen und neuer Hardware konnte das auf <10 Minuten gedrückt werden. Probleme wie eval, Destruktoren etc. wurden beseitigt. Mit Hilfe von Jenkins und sollte das Deployment passieren, ein serielles Ausrollen kam nicht in Frage (bei 1Gbit Netzwerk würde das bei 700 Servern sehr lang dauern), nur ein Diff der Binarys deployen kommt nicht in Frage da das Diff teilweise 400MB groß ist. Erste Lösung: Bittorrent: Gemacht in Live Umgebung: Totalausfall des Netzwerkes, da alle Leitungen und Switches überlastet wurden über viele Minuten, selbst Admin-Zugang nicht mehr möglich. Danach Murder von Twitter angeschaut, einen eigenen Tracker geschrieben, einen modifizierten rtorrent-Client ohne DHT und UPNP etc., Definition von mehreren Schwärmen um die Rechenzentren zu trennen, Begrenzung im Client auf 90Mbit usw..

Johannes Mainusch von Xing plauderte auch etwas aus dem Nähkästchen, von Problemen beim Messen der Performance, nur jeder 200. Besucher schickt Messdaten an den Server. onbeforeunload() Cookie setzen, auf nächster Seite Zeit messen bei onLoad. Wenn Benutzer in das Login Formular klickt werden schonmal einige Bilder vorgeladen die auf der nächsten Seite gebraucht werden. Tweets pro Tag werden gemessen und vieles vieles mehr. Unter anderem auch Anzahl der Registrierungsmails, Anzahl Anleitung nach erstem Login, Anzahl Passwort vergessen, Benutzungen des Handshake-Features per Google Earth und kml.

Bradley Heilbrun von YouTube bzw. Google konzentrierte sich speziell auf das Thema HTTP Connection Handling. Was tut man wenn man mit 6 Servern beginnt und überrollt wird und sehr schnell skalieren muss? Hunderttausende von gleichzeitigen Verbindungen müssen gehalten werden, und wenn Apache für jede Connection einen Prozess startet? Man benötigt einen guten Loadbalancer bzw. spezialisierte Software, die das kann, und idle-Connections halten kann. nur Requests gehen dann durch auf die Backend-Webserver, die früher mit mod_php und mpm_prefork liefen. Besser: FastCGI und mpm_worker, bessere Skalierungsmöglichkeiten. Weiter hilfreich: URL Routing. Später dann Probleme als man > 5 IPs im DNS veröffentlichen wollte, >512 Byte, Umschwenk von UDP auf TCP. Dann wurde es nötig mit Direct-Server-Return zu arbeiten und 2 Load-Balancer-Schichten einzuführen. Bei Global Server Load Balancing (GSLB) sind Länder-Subdomains (us.youtube.com, eu.youtube.com …) doof, Indizierungsprobleme, Bookmarks usw… Anycast doof. Besser Geo-DNS.

So, das war es im groben Überblick, es war unglaublich wie viele interessante Eindrücke ich gesammelt habe, hoch interessant wenn solche großen Firmen und Weltmarkführer ihre Erfahrungen vermitteln, da könnte ich wochenlang zuhören. Eine wirklich tolle Konferenz ist nun zuende, und ich würde jedem empfehlen an der nächsten Velocity Europe teilzunehmen wenn möglich, es lohnt sich auf jeden Fall!

Übrigens bemerkenswert war das Vorhandensein eine Übersetzers in Gebärdensprache, cool!