PHPGangsta - Der praktische PHP Blog

5:20 Uhr: Aufstehen ist angesagt, ich glaube so früh bin ich dieses Jahr noch nicht aufgestanden, aber die Freude auf den sicherlich großartigen Tag lässt die Müdigkeit schnell verschwinden. Eine halbe Stunde später sitze ich im Auto und hole noch einen Freund und einen Arbeitskollegen ab, und dann beginnt die Fahrt Richtung Hamburg. Eingeplant sind 3 Stunden, um passend zum Beginn der Unconference um 9:30 Uhr da zu sein. Die Autobahn ist leer, und so kommen wir um 9:35 Uhr an der Universität an.

Bei der Begrüßung bzw. Opening Session wird unter anderem das Prozedere erklärt, Sponsoren vorgestellt, das Abendprogramm erläutert und dann das wichtigste: Die Abstimmung der Sessions für den heutigen Tag. Dazu hat jeder bei der Anmeldung Aufkleber erhalten, die unter die Wunschthemen geklebt werden müssen. Die 16 Sessions mit den meisten Aufklebern werden gehalten. Erstmals gab es einen zusätzlichen Raum für spontane Sessions oder Lighning-Talks, wo ich allerdings nichts von mitbekommen habe, vielleicht sollte man sich speziell dafür einen Twitter-Hashtag oder ähnliches überlegen damit man diese kurzfristigen Talks mitbekommt.

Um 12 Uhr beginnt die erste Session, ich entscheide mich für „Good Code Matters“, aber H1 oder H2 hätten mich auch interessiert. Zumindestens den stern-Vortrag von Nils kann ich auf der IPC noch hören.

Weiterlesen »

Wenn ich es richtig sehe sind von gestern Abend noch ca. 20 Tickets übrig, dann sind die 300 voll. Falls ihr also für 35 Euro an der PHP Unconf in Hamburg teilnehmen möchtet ist jetzt die letzte Chance.

http://www.php-unconference.de/ticketverkauf/

Letztes Wochenende wurde der Ticketverkauf der PHP Unconference 2010 in Hamburg gestartet, und nur 6 Tage später waren die 200 Tickets ausverkauft, Wahnsinn! Auch dieses Jahr werde ich wieder mit von der Partie sein, letztes Jahr war spitze und ich bin mir sicher dass ich auch dieses Jahr wieder viel Neues mit nach Hause nehmen werde.

Gestern habe ich noch eine gute Nachricht bekommen: Ich werde dieses Jahr auch zur International PHP Conference Spring Edition 2010 fahren, mein Arbeitgeber mail.de hat mir das OK gegeben und spendiert mir einen mehrtägigen Besuch in Berlin. Danke Fabian, du bist der Beste!

Jetzt muß ich nur noch für die jeweiligen Termine Hotels finden in Berlin bzw. Hamburg. Falls jemand einen Geheimtipp für günstige Unterkünfte hat, nur her damit, ansonsten werd ich es über die zahlreichen Hotel-Bewertungs-Such-Seiten versuchen.

Wer von euch ist noch auf einer der beiden Konferenzen, dann kann man sich evtl. die Gesichter schonmal bei Xing und Co. angucken. Ich hoffe den ein oder anderen Leser dort zu treffen und vielleicht ein kleines Pläuschchen zu halten.

Die Unconference war viel zu kurz, die Sessions waren zu 95% extrem interessant und spannend. Mindestens genauso spannend waren die Gespräche zwischendurch. Es gibt im Wiki der Unconf zu jeder Session eine Zusammenfassung, trotzdem möchte ich hier versuchen, die wichtigsten Inhalte meines favorisierten Vortrags nochmal nachzuarbeiten. Die Session trug erst den Titel „PHP Performance Optimierung“, doch die 4 Vortragenden haben sich dazu entschlossen, ihn kurzerhand umzubenennen in „PHP Performance Pessimierung“. Denn aus Fehlern lernt man am besten.

Die Liste der Speaker lässt Großes erwarten: Johann-Peter Hartmann, Kris Köhntopp, Lars Jankowfsky und Stefan Priebsch

Die einführenden Worte begannen mit einer kurzen Zusammenfassung. Frameworks und vor allem das ganze „drumherum“ helfen uns, ein Webprojekt langsam zu machen, es ist nicht nur PHP selbst. Und man kann sehr vieles tun, damit doch wieder eine unerträgliche Performance zu Tage kommt und der Benutzer keine Lust mehr auf die Webseite hat.

Was bedeutet Performance? Die Stichworte „Latenz“ (ideal sind 29 Sekunden, weil nach 30 Sekunden der Browser in ein Timeout läuft), „Durchsatz“ (wie schaffe ich es, dass möglichst nur 1 Benutzer gleichzeitig die Webseite nutzen kann), und Funktion (wenn nach einem Klick auf einen Knopf nichts passiert) wurden genannt. Daran müssen wir nun arbeiten.

Damit wir etwas zu pessimieren haben, wurde eine häufig auftretende Architektur aufgemalt, wo wir ansetzen können. Diese sieht so aus:

Wir beginnen im Browser. Javascript und vor allem AJAX ist ein prima Werkzeug, um eine Seite unbenutzbar zu machen, und möglichst viele Ressourcen auf dem Server zu verbrauchen. Ideal sind viele AJAX-Requests, möglichst viele Informationen durch Javascript verarbeiten („quatsch, wer braucht schon ein LIMIT im SQL-Server, Javascript kann auch nur die ersten 10 Ergebnisse anzeigen und den Rest verwerfen“). Dabei laden wir möglichst viele Dinge, die wir dann nicht anzeigen.

Im Loadbalancer wollen wir natürlich immer Level 7 inspecten, damit wir möglichst viel zu verarbeiten haben und es möglichst lang dauert, eine Entscheidung zu finden. Wir bauen viel Logik darein, damit wir idealerweise jeden Request auf den am meisten belasteten Server zuteilen.

Der Webserver speichert idealerweise die Sessions in einer Datenbank, damit wir schon für sowas ordentlich viel Traffic und Performance auf die Datenbank-Server verlagern. Die Dateien liegen auf einem NFS, damit bei jedem stat auch ein Netzzugriff stattfindet. Auf keinen Fall darf dort Memcache verwendet werden, wir cachen nicht im Speicher sondern auf der Festplatte. Durch möglichst komplexe Logik, gleichzeitigen Cache-Wipe, kompliziertes (Dead)-Locking, Abhängigkeiten und nicht eindeutige Cache-Keys bekommen wir ideale Voraussetzungen, um durch Caching noch langsamer als vorher zu arbeiten. Wunderbar!

Wenn dann PHP selbst drankommt, dürfen wir auf keinen Fall einen Byte-Code-Cache nutzen. PHP muss bei jedem Request die Scripte neu kompilieren, es könnte ja sein, dass sich die Dateien von einen auf den anderen Request geändert haben! Möglichst viele include_once auf relative Pfade helfen uns, viele Festplatten-Zugriffe (file-exists usw) zu generieren. Einige Frameworks unterstützen uns dabei auch ideal. Falls wir einen Autoloader verwenden, sollte das am häufigsten verwendete Verzeichnis auch als letztes durchsucht werden, so generieren wir für jeden Loadversuch extra Zugriffsversuche! Natürlich dürfen wir auch nicht vergessen, den Virenscanner zu aktivieren. PHP-Scripte sind hoch gefährlich und müssen bei jedem Zugriff gecheckt werden!

Mit version_compare und ini_set werden wir auch bei jedem Script die grundlegenden Einstellungen prüfen und neu setzen. Die php.ini könnte sich ja auch geändert haben.

Auch wenn wir sie anfangs nicht brauchen, stellen wir natürlich zu jeder Datenbank eine Verbindung her, wir könnten sie ja später brauchen, und dann haben wir sie schon da. Das selbe gilt für große Klassen, die wir evtl. später brauchen könnten. Auch ist die Datenbank ideal, um Bilder und anderen statischen Content zu speichern. Diese Daten holen wir dann mit PHP und liefern sie an den Browser. Statischen Content direkt ausliefern können wir nicht tun, wir müssen doch jeden Zugriff mittels PHP zählen, und das Cachen im Browser verhindertn, die Bilder könnten sich ja jederzeit ändern.

Wir brauchen zur Anzeige natürlich auch eine effektive, sehr funktionsreiche Template-Engine. SMARTY bietet sich da an, da haben wir ähnlich wie in PHP die if-Abfragen, Schleifen und Ausgaben. Perfekt, das brauchen wir, und PHP kann das nicht!

ORM ist auch gerade in der Mode, und wir wollen ja nicht unsere SQL-Statements selbst schreiben. Manuell Optimieren ist out, ORM bieten die Möglichkeit, den Query bei jedem Request neu zu generieren. Außerdem sind wir damit unabhängig von der Datenbank, denn wir wechseln sie ja ab und zu, deshalb lieber abstrakt bleiben und das von komplexen Frameworks erledigen lassen. Stored Procedures lassen wir auch weg, denn wir wollen ja die Datenbank entlasten und darauf nichts speichern.

—–

Es war auf jeden Fall der lustigste Vortrag auf der Unconf, die Speaker und die Hörer hatten viel Spass bei der „Optimierung“ und auch ein sehr schöner Einstieg und Überblick für weitere Sessions.

Stichworte und Bilder findet ihr im Wiki-Eintrag zur Session. Hier nochmal ein Dankeschön an die Speaker, ihr seid spitze!