PHP Blogger

So schnell können Wünsche in Erfüllung gehen Julius ;) Das mit dem Artikelwunsch ist eine prima Sache für Autoren. Ich gebe zu, in letzter Zeit bin ich wenig fantasievoll, was Artikelthemen angeht. Dann schreibt man halt über ein Thema, das einen selbst gerade beschäftigt und natürlich nutze ich meinen Blog auch dazu, Lösungswege für mich (und die Öffentlichkeit) festzuhalten.

Performance als Thema ist immer so eine Geschichte. Bei den meisten kleinen Projekten eher präventiv zu sehen, ist es bei Business-Projekten mit hohen Zugriffszahlen und/oder gigantischen Datenbankgrößen ein nicht unwesentlicher Aspekt bei der Webentwicklung.

Aber aus Spiel und Spass kann schnell ein großes Projekt werden, weil es das mehr oder minder breite Publikum begeistert und die Zugriffszahlen in die Höhe schießen lassen und die Entwicklung mit dem Tuning nicht mehr nachkommt. In diesem Fall (und allen anderen) rechnet sich dann eben eine sorgfältige leicht paranoide Planung der Entwicklung nach dem Motto, was wäre wenn…

…mein Projekt wirklich erfolgreich wird. Hehe. Die meisten Projekte werden es nämlich nicht. Um dem Grund allen Übels auf den Grund zu gehen, machen wir mal eine kleine Reise durch die Geschichte der Performance:

Ganz früher

Irgendwann mal waren Rechner und Server kleine poplige Maschinen, bei denen man stolz war, wenn sie 3 statische HTML Seiten gleichzeitig ausliefern konnten. Damals wurde der Performance Wust noch durch laaaaaaaaaaangsame Internetverbindungen gebremst. Bei einem 14000er Modem wurde die Datenübertragung noch mit Bit/Sekunde berechnet. Da war einfach nicht klar, warum eine Webseite nun 30 Sekunden für den Aufbau benötigt hat:

1. War der Rechner einfach zu lahm?
2. Die Verbindung zur Vermittlungsstelle so schlecht?
3. Der Provider überlastet?
4. Der Server überflutet mit Anfragen?
5. Die Grafiken viel zu pompös?

Warten war da an der Tagesordnung: Für einen 10 MB Download hat man da schon mal eine Stunde oder länger gewartet. Das geht heute natürlich nicht mehr. Über zum Glück sind nicht nur die Datenleitungen gewachsen, die die Bits und Bytes der Anfragen schneller auf einen Server einprasseln lassen, sondern auch die Server sind leistungsfähiger geworden.

Alles nur Spass

Aber bei der Entwicklung und Programmierung ist es leider nicht anders als bei Spielen. Ich kann mich noch daran erinnern, das ich mal gesagt habe “Bald hab ich einen Pentium 1, dann läuft Indiana Jones endlich flüssiger als auf meinem 486er”. Der PC Triumph über Datasette mit 10 Minuten Ladezeit für ein Game wurde leider dadurch gedrückt, das mit den PCs auch die Games in Größe und Leistungshunger gewachsen sind.

Der Stammbaum

Wie gesagt: das gleiche Problem haben wir jeden Tag beim Entwickeln: Sobald die Leistung der Maschinen wächst, wächst auch der Anspruch des Entwickler-Menschen: Da sind Assembler und Kobol einfach nicht mehr genug. Da müssen Objekte und Schnittstellen her. Objekte kommen auch nicht aus dem nichts, sondern werden über Väter- und Mutter-Klassen, Großvater- und Urgroßvater-Klassen von einem Interface abgeleitet.

Globale Variablen? Bäh. Die wurden von ein paar fleissigen OOP-Spezialisten von Singleton-Mustern abgelöst und jetzt ist auch das zu unsauber entwickelt. Singleton ist pfui, es müssen Action-Controller und View-Generatoren her. Der Kampf von Objektorientierung gegen die Performance hat begonnen.

Was mit der Erkenntnis anfangen?

Das klingt jetzt so, als wäre der PHP Blogger ein OOP-Gegner. Hehe. Ach quatsch, so ist es auch nicht. Ich möchte nur über den Kompromiss berichten, den man als Entwickler von Web-Applikationen jeden Tag machen muss.

Muss jedes einzelne Website-Element dynamisch generiert und ausgeliefert werden? Statisch im Dateisystem abgelegte Elemente sind einfach immer schneller ausgeliefert, als zur Laufzeit aus der Datenbank exportierter oder serialisierter Objekt-Content.

Pro und Contra

Mal kurz innehalten und überlegen, was man alles statisch ablegen kann:

• Grafiken, die im Tempplate und CSS abgelegt werden
• Downloads, die für jeden abrufbar sind
• Javascripts, die keine großen Geheimnisse beinhalten
• Inhaltsseiten, die nur sehr selten geändert werden

Natürlich kann man diese Liste noch ein wenig fortführen. Die Tendenz zu Inhalten, die dynamisch verwaltet werden können, ist hoffentlich auch klar geworden:

• Geschützte Inhalte, die auf einem komplexen Rechtesystem basieren
• Personalisierte Inhalte, die häufig in Benutzerportalen verwendet werden
• Login-Bereiche
• Dynamische Seiten, die vom Benutzer verändert werden können (Wikis, Blogs, usw)

Auch diese kurze Liste ist sicherlich noch erweiterbar. Es gilt also ganz klar festzuhalten:

1. Es gibt Inhalte, die auf Grund Ihrer Art dynamisch ausgeliefert werden müssen.
2. Was dynamisch mit Hilfe einer Programmiersprache dynamisch generiert wird, sollte auf gutem und flexiblen Code basieren.
3. Objektorientierung kann (richtig angewendet) die Wartung eines Codes beträchtlich vereinfachen.
4. Möglichst fein gegliederte Objektstrukturen haben einen extrem hohen Wiederverwendungswert und so kann man meistens zentral Fehler beseitigen und trotzdem eine dezentrale Wirkung erreichen.

Eine schöne, logische Codebasis ist also essenziell. Ganz klar. Hat aber eben auch den Nachteil, das alles was der Entwickler so schön dezentralisiert und durch die Gegend vererbt hat, von einem armen Prozessor wieder zusammengepuzzelt werden muss. Das braucht Zeit, Speicher und damit eben auch Performance.

Wie jetzt was

Genau, wie geht man mit dem Dilemma jetzt am Besten um? Wir brauchen die Objektorientierung, wir brauchen Patterns, aber wir brauchen auch Performance.

Eine Lösung ist sicherlich ein ausgeklügeltes Cache-System. Mit einem sehr guten Cache, kann man alles cachen. Es gibt nichts, was man nicht cachen kann. Das Geheimnis, das einen Cache wirklich wirkungsvoll macht, ist sicherlich die Methode, die zum Aktualisieren des Caches führt. Denn Cache muss immer aktuell sein. Und gerade, wenn man mit personalisierten Inhalten arbeitet, die die Besucher am Ende selbst festlegen können, wird es spannend: Wie zum Kuckuck teilt man dem Cache mit, das er an einer bestimmten Stelle aktualisiert werden muss? Wie identifiziert man zu aktualisierende Cacheinhalte?

Fragen über Fragen. Die kann ich natürlich am Rande diesen Artikels nicht beantworten. Einen Cache zu bauen ist ein Thema für sich. Sehr anspruchsvoll. Denn auch Cachen sollte man nicht übertreiben - schließlich kann die Neuberechnung eines Caches länger dauern und mehr Performance kosten, als ein Generator, der alles zur Laufzeit zusammenbaut.

Ein Cache ist also sicherlich nur eine Teillösung, kein Allheilmittel. Aber es unterstützt die Objektorientierung, in dem es im besten Fall einer Maschine wieder Performance zurückgibt.

Wer gerne objektorientiert programmiert, sollte daran denken, es nicht zu übertreiben. Elemente, die er statisch ausliefert schenken dem Entwickler und seinem Code nämlich auch Performance. Und so wird ein entspannter und solider Webserver-Betrieb garantiert.

Nochmal Zusammenfassend

1. So viel wie möglich mit statischen Elementen arbeiten
2. Ein ausgeklügeltes Cache-System einsetzen
3. Die gewonnene Performance für Objektorientierung und klar strukturierten Code verwenden

Ich muss weg.

Ähnliche Artikel:

1. Linktipps: Performance und Produktivität
2. Wo ist meine MySQL Performance?
3. MySql Performance steigern
4. Sei ein Objekt-Schwein!
5. Performance durch PHP Benchmarks