Optimieren von Code ist toll und kann gewaltige Vorteile in der Performance bringen. Aber man sollte es nicht übertreiben.

Es gibt dutzende, wenn nicht sogar hunderte oder tausende, Wege eine Anwendung performanter zu gestalten. Einer der meistgenutzten Wege ist die Optimierung des Codes. Hierbei gibt es natürlich einige sehr interessante und gute Ansätze, aber auch viele, die die Wartungsfähigkeit des Codes einschränken oder schlichtweg nur minimale Gewinne bringen.

Vorweg wollen wir uns jedoch mit der Frage beschäftigen, ob Optimierungen wirklich nötig sind. Wenn eine Anwendung in einer für den Nutzer zumutbaren Zeit reagiert sollte man sich keine Gedanken machen hier noch etwas zu verbessern. Ebenso sollte man sich keinen unnötigen Aufwand zumuten, wenn sich das Problem durch Aufstocken der Hardware lösen lässt. Meist bringt das mehr und kommt günstiger. Man sollte jedoch dringend etwas unternehmen, wenn sich die Hardware sowieso schon auf einem Maximallevel befindet und diese an ihre Grenzen stößt.

Der übliche Weg ist dann mithilfe eines Profilers die Stellen im Code zu finden, die die Anwendung ausbremsen. Sobald man sie gefunden hat macht man sich Gedanken, was man verbessern kann. Beispiele hierfür sind weniger Datenbankabfragen ausführen, Ergebnisse zu cachen, Statements optimieren, etc.

Was man jedoch tunlichst vermeiden sollte sind Mikro-Optimierungen. In PHP gibt es hierfür einige tolle Beispiele, z.B. Strings in einfache Hochkommata schreiben, Prekrement statt Postkrement verwenden, kürzere Variablennamen zu verwenden, usw. Ich persönlich habe mir zwar einige Sachen davon angewöhnt, da es nie schaden kann hier und da eine tausendstel Millisekunde zu sparen, jedoch bringen diese Optimierungen meistens keine Verbesserung im Gegensatz zum vorherigen Stand. Viel wichtiger ist es seinen Code nochmal zu überdenken und alternative Methoden zu finden, die die Ausführung beschleunigen.

Irgendwie habe ich gerade das Gefühl, dass ich was komplett anderes geschrieben habe als ich ursprünglich wollte, aber die wichtigste Message habe ich genannt und darauf kommt es an. Übrigens gibt es auch bei PHP hates me einen Artikel dazu.

—
Foto: Old street at the speed of light von fabbio

Hiermit will ich einen Einblick in die Sessions des ersten Tages der IPC 2009 und der Ergebnisse davon geben.

Da ich, wie ich bereits geschrieben habe, pünktlich angekommen bin habe ich die Eröffnungssession auch noch mitbekommen, die einen kleinen Einblick in das vielfältige Programm der International PHP Conference und der webtech gab. Kurz darauf ging es dann auch schon mit der Session “Design Patterns” von Cal Evans bei mir los und das war genau richtig als Einstimmung auf die nächsten drei Tage.

Design Patterns von Cal Evans

Gestartet hat die Session direkt mit einer Buchempfehlung: “Design Patterns” von der Gang Of Four. Anschließend ging er dann großteils auf das MVC-Pattern ein und hat dessen richtige Verwendung erklärt, z.B. sollte ein Model niemals direkt auf eine Datenbank abbilden, da die Datenquellen eines Models wesentlich vielfältiger sein können. Sie können neben Datenbanken auch auf Webservices, etc. zugreifen und ihre Daten von dort beziehen.

Controller sollten ebenfalls keine großen Logiken beinhalten, sondern nur dafür Sorge tragen, dass die Daten vom Model zum View und umgekehrt gelangen. Jedoch sollten im Controller die Exceptions gefangen werden. Das Stichwort, welches ich vor kurzem dazu gelernt habe, nennt sich “Fat Model, Tiny Controller”.

Der View sollte logischerweise keine Logiken enthalten, sondern nur für die Darstellung sorgen. Dafür kann er, wenn nötig, auch direkt auf das Model zugreifen, darf jedoch keine Daten schreiben, sondern nur lesen.

Abgesehen davon ist er noch auf das Decorator Pattern eingegangen, welches anstatt multipler Vererbungen verwendet werden sollte, da man damit wesentlich flexibler ist.

NetBeans IDE von Petr Pisl

Die zweite Session stand ganz im Zeichen der aktuellen Betaversion von NetBeans, einer schlanken, aber sehr mächtigen IDE für die Entwicklung in verschiedenen Programmiersprachen. Da es bei der IPC logischerweise um PHP geht wurden auch nur die neuen Features dieses Pakets abgehandelt.

So soll die neue Version nach Plan am 10.12.2009 erscheinen und viele neue Fähigkeiten besitzen. Die erste genannte war eine Codevervollständigung ohne PHPDoc. Dafür scannt NetBeans den Code und versucht anhand verschiedener Indikatoren herauszufinden, was die Methoden und Funktionen für Rückgabewerte liefern. Auch soll PHPDoc nun eine Code-Completion erhalten, ebenso wie einzelne Elemente eines Arrays oder auch SQL, welches in Strings vorkommt. Man kann nun auch bestimmte Ordner aus dem Index für die Vervollständigung herausnehmen.

Abgesehen von diesen Features, die ich enorm spannend finde soll auch das Erstellen von Unit-Tests sehr einfach werden und die Ausführung dieser ebenso. Das Handling dieses Features erinnert mich stark an Zend Studio for Eclipse, wo das auch möglich ist.

Continuous Integration von Stefan Priebsch und Sebastian Bergmann

Diese Session war für mich extrem interessant, da ich mit diesem Thema noch nicht wirklich in Berührung gekommen bin. Die ersten Aussagen der beiden hat auch direkt beinhaltet, dass man unbedingt automatische Tests durchlaufen lassen soll und mindestens einmal täglich den aktuellen Stand zu integrieren, also zu committen.

Anschließend wurde der Wert von Continuous Integration angesprochen, der sehr hoch ist. Durch dieses Verfahren verringert man Risiken und reduziert gleiche Prozesse, da nicht überall die gleiche Software installiert werden muss. Abgesehen davon erzeugt man deploybare Software, sorgt für größeres Vertrauen in den eigenen Code und die Sichtbarkeit eines Projektes wird erhöht, da jeder immer den aktuellsten Stand einsehen kann.

Um mit diesem Verfahren starten zu können muss man zuerst einmal die Prozesse herausfinden, die automatisiert werden können. Hieraus soll dann ein “Non-Event” gemacht werden, was im Klartext bedeutet, dass es sehr einfach sein soll diesen Prozess auszuführen, z.B. durch einen Klick auf einen Button oder ein kleines Skript.

Zuletzt wurden dann noch diverse Tools vorgestellt, die man nutzen kann und die ich hier einfach nur auflisten will, da ich mich damit noch nicht weiter beschäftigt habe: CruiseControl, phpUnderControl, Hudson, Atlassian Bamboo und Arbit.

Event Driven Architectures von Benjamin Eberlei

PHP an sich unterstützt nur bedingt Events, da es eine request-basierte Sprache ist. Jedoch gibt es zwei Patterns, die man nutzen kann, um so eine Architektur zu bilden: Das Observer-Pattern und das Event-Dispatcher-Pattern.

Doch auch dies reicht noch nicht aus, um auf Events reagieren zu können. Dazu sind weitere Tools notwendig, wie z.B. XMPP, dropr oder Gearman. Erst durch diese wird es möglich auch asynchron mit PHP arbeiten zu können. Von diesen drei Tools hat Benjamin noch Gearman etwas weiter vorgestellt, welches durch seine einfache Nutzung bei mir punkten konnte.

Wer langsam ist verliert von Dr. Johannes Mainusch

Diese Session war von der webtech und sehr interessant. Es wurde davon berichtet, welche Ziele sich XING gesetzt hat und wie sie es geschafft haben diese zu erreichen.

Die Performance von Websites ist sehr wichtig und jede Seite sollte innerhalb von zwei Sekunden komplett geladen werden, da ein Mensch in dieser Zeit eine Reaktion erwartet. Wenn nichts voran geht kommt Frustration auf und die Plattform wird verlassen. Diese Nutzer kommen auch meist nicht wieder. Dabei macht die Zeit, die der Server für die Datenverarbeitung benötigt, meist nur einen kleinen Teil aus, der größte Teil findet jedoch auf dem Weg vom Server zum Nutzer statt.

Um hier für mehr Geschwindigkeit zu sorgen ist es erstmal wichtig die Engpässe zu finden. Wie groß sind die ausgelieferten Dateien, werden diese vom Browser gecached, gibt es langsame Requests usw. Hat man hier alles identifiziert kann mit der Optimierung begonnen werden. Man kann dann anfangen Dateien zusammenzufassen, das Caching für den Browser zu beeinflussen usw.

Fazit

Alle diese Sessions waren sehr interessant und ich bereue es nicht andere Sessions besucht zu haben. Es waren viele spannende Themen von kompetenten Speakern, die zumindest mir einige neue Erkenntnisse gebracht haben.

—
Foto: IPC 2009 von mor10am

Seit gestern gibt es ein neues Feature hier im Blog. Einen Planet.

Gestern habe ich mich mal damit befasst ein lange von mir geplantes Feature umzusetzen, nämlich die Aggregation und Anzeige von interessanten Artikeln, die ich in meinem Feedreader lese.

Dabei ist nun diese Seite entstanden, die genau das macht. Die Technik dahinter ist noch sehr simpel gehalten und auch noch nicht ganz so performant wie ich das gerne hätte, aber dafür finde ich auch noch eine Lösung in den nächsten Tagen. Dann folgt auch eine weitere Erklärung, wie das geschieht und welche Technologien eingesetzt werden.

Und dann noch eine Sache. Sollten auf dieser Seite Artikel angezeigt werden, die dort nicht gewünscht sind kann man mich bequem über mein Kontaktformular erreichen. Ich werde diesen Artikel dann selbstverständlich aus der Aggregation entfernen.

—
Foto: Notting Hill garden little planet

Aber es gibt auch eine Alternative zu den kleinen Bildchen. Nämlich noch kleinere Bildchen: Favatars. Hierfür gibt es für WordPress ein kleines Plugin, welches sich ganz frech die Favicons der Sites, die einen Track-, bzw. Pingback senden oder deren Autor einen Link hinterlässt, schnappt und dort anzeigt, wo man es gerne hätte.

Ersteres hat sich bereits zum großen Teil durchgesetzt, aber wer aus der Masse stechen will sollte sich für Letzteres entscheiden oder wie hier nichts dergleichen anzeigen. Ein Problem gibt es mit den Favatars jedoch: Wenn sie so eingebunden sind wie beim Dr. Web Weblog erzeugt jeder Seitenaufruf eines Eintrags einen Aufruf des Favicons. Das wäre nicht weiter schlimm, soll ja auch so sein. Doch wer kein Favicon sein Eigen nennt wird mit der Auswertung seiner Serverlogs nicht mehr froh, da es jedes mal zu einem Fehler 404 kommt.