PHPGangsta - Der praktische PHP Blog

Nach dem Mittagessen ging es im ersten Talk ums Monitoring, und warum wir so schlecht darin sind. Theo ist der Meinung dass wir häufig die falschen Dinge monitoren, denn Ziel Nummer 1 ist das Business, wir müssen vor allem messen können ob und wie die Nutzer die Applikation nutzen, dazu gehört mehr als nur Conversions. Häufig wird beispielsweise die Bandbreite gemessen, die aber erstmal nicht viel aussagt, und auch sitzen wir zu häufig vor Graphen die alle 5 Minuten aktualisiert werden, wir sitzen davor und gucken zu oder drücken F5. Wir brauchen Echtzeit Graphen mit 2 Sekunden Aktualisierungsintervall, und es sollten beispielsweise senkrechte Marker vorhanden sein die Deployments/Releases anzeigen.

Der nächste Talk von David Mandelin war sehr technisch, er ging direkt auf Javascript-Engine-Level und erklärte was so im Browser abläuft wenn Javascript ausgeführt werden soll. Eine einfache Anweisung „x=y+z“ macht bei einer typenlosen Sprache Probleme, deshalb gibt es mehrere Wege wie man diese in Maschinencode umsetzen kann. Die Browser sind da mittlerweile gleichgezogen, JIT und typisierte JIT Compiler können schnellen Code erzeugen, können aber nicht immer zum Einsatz kommen. Insgesamt interessante Einblicke unter die Haube, am Ende kamen noch einige Hinweise worauf man achten kann damit möglichst der schnellste Compiler zum Einsatz kommt, z.B. Typwechsel von Variablen vermeiden und vollständige Arrays nutzen.

Wie man Web Performance messen kann hat Stephen Thair nicht gesagt, denn es gibt keine eindeutige Vorgehensweise, egal wie man es macht, man macht es „falsch“. Zeit ist subjektiv, manchmal fliegt sie, manchmal schleicht sie nur so dahin. Um zu entscheiden ob eine Seite schnell (genug) ist helfen z.B. Videoanalysen, Umfragen, Interviews und ähnliches.

Objektiv kann man die Geschwindigkeit auch auf verschiedenste Weise messen: via JS Timing, Browser Extension,Proxy Timing, Webserver Module oder Network Sniffer. Wichtige Metriken sind Time to First Byte, Render Start Time, DOM Content Loaded, OnLoad. Weitere Stichworte: WebPageTest, Episodes, Yahoo Boomerang, HttpWatch, ShowSlow, Analytics Site Speed, Navigation API.

Cosimo Streppone von Opera hat ausführlich von seinem ersten DDOS Angriff berichtet an dessen Abwehr er beteiligt war. Es begann mit anfänglichem Stochern im Nebel: Buffer und Timer in nginx wurden eingestellt bzw. überprüft. Die Angreifer riefen nur eine bestimmte URL auf. Als diese Requests alle schnell mit einem Fehlercode beantwortet wurden ging es den Servern kurzzeitig besser, die Angreifer wechselten zu sich ändernden URLs und Headern.

Dann irgendwann ist man darauf gestossen dass es an einem TCP-Windows-0-Byte Problem liegt (durch Hilfe im IRC: Toolname nkiller2). Das Tool der Angreifer schickt einen Request und sagt dem Server dann mit einer Window-Größe von 0 dass der Server das Senden pausieren soll. Damit konnten die Angreifer sehr viele Connections öffnen ohne viel Traffic zu verursachen. Zuerst wurden diese Pakete mittels iptables geloggt, danach gedroppt. Nach über einer Woche hatte man die Situation im Griff, und lernte viel aus dem Vorfall: Ein Varnish mit einer TTL von 1s hält Hammerings vom Backend fern, man sollte seine Schritte und Konfigurationsänderungen dokumentieren, man sollte sich koordinieren mit allen Beteiligten, und seine Tools (tcpip, tcpdump,strace, nc,iptraf, tcpflow) kennen. Und man sollte TCP/IP kennen!

Die letzte Session ging um Automatisierung von Weboptimierungen. Eine Webseite zu optimieren kann man auf 2 Wegen machen: manuell oder automatisiert. Manuelle Änderungen, wie Bilder/JS/CSS komprimieren und zusammenfügen, kosten Zeit, und müssen bei neuen Features erneut durchgeführt werden. Automatische Tools die man entweder auf dem Webserver installiert (mod_pagespeed) oder zwischen Kunden und Webserver installiert (Pagespeed Service, Aptimize). Tests mit 100 Webseiten zeigen signifikante Verbesserungen, man sollte es mal ausprobieren und dann entscheiden ob man manuell oder automatisch optimieren möchte.