Kategorien
Architektur vs. Performance
Auf der PHP Unconference in Hamburg hatte ich ein sehr nettes Gespräch mit Lars Jankowskfy über den Oxid Shop und die Kritiken, die „derzeit“ (ist schon ein paar Wochen her) eintreffen. Im Kern unseres Gespräches ging es darum, ob man eine gute Architektur aufbrechen darf, um Performance zu gewinnen. Und genau diese Frage möchte ich heute für mich beantworten.
Als Lars mich darauf angesprochen hat, war ich der festen Überzeugung, da schon eine Meinung zu haben, denn an der Uni wurde mir diese Meinung auch eingeprägt. Aber vielleicht lasse ich erstmal meine ersten Gedanken auf euch los und dann schaue ich mal wie man das anpassen kann.
Wenn ich ein großes Projekt starte, sagen wir mal ich möchte die Webseite von www.heise.de neu machen, dann würde ich mit einer sauberen Architektur anfangen und niemand dürfe gegen die Richtlinien verstoßen. Wenn wir an ein großes Bottleneck stoßen und absolut keine saubere Lösung finden, dann würden wir einen zusätzlichen Server hinstellen, um die Lastspitzen zu kompensieren. Ich habe nicht wirklich etwas gegen das Aufbrechen von Richtlinien, aber die Wartung des gesamten Systems wird immer schwieriger. Irgendwo kann man auch nachlesen, dass 80% der Kosten eines Projektes in der Wartung stecken. Und rechnet man mal hoch, dann ist ein Entwickler um einiges teurer, als ein Server, den man irgendwo hinstellt. Server werden auch in kürzeren Zeiträumen schneller, als das Entwickler effizienter werden. Das muss natürlich alles überschaubar bleiben. Das System mit Servern zuschütten, kann nicht die Lösung sein, aber das muss es auch nicht, wenn die Architektur gut durchdacht ist.
In diesem Fall würde ich mich also genau gegen die Vorgehensweise von Oxid stellen. Da ich aber viel von Lars halte, wollte ich mir da doch ein paar merh Gedaken drüber machen. Kann man die ich oben über „mein“ Projekt habe, auf Oxid mappen? Nein.
Nehmen wir mal an, wir haben ein Shopsystem, dieses System muss die Datenbank bei großen Datenmengen denormalisieren, damit es noch läuft. Wäre es mein System, dann würde ich es auf zweit Datenbanken verteilen. Wer kauft aber ein Shopsystem, bei dem man bereits weiß, dass es zwei Server „verschwendet“? Niemand. Besonders, wenn andere Anbieter es mit einem können. Mir ist es auch egal, ob die Wartung teuer ist, ich werde mich ja nur in den Templates aufhalten. Mir als „Endkunde“ geht es also nicht um die tolle Architektur und genau aus diesem Grund, werde ich dafür auch nicht zahlen. Will ich also im Rennen mit meinem Produkt bleiben, dann kann ich mein System architektonisch so aufblähen, dass mir die Kunden wegrennen. Diese Optimierung durch Aufbrechen der Struktur muss in diesen Fällen natürlich sehr gut dokumentiert sein und darf einem Entwickler nicht immer wieder zufällig über den Weg laufen.
Wir müssen also entscheiden, was für ein Projekt wir starten. Ist es ein lokales Projekt und bin ich somit der einzige Anwender, dann würde ich alles dafür tun, möglichst wenig Wartung und Erweiterbarkeit zu schaffen. Muss ich Produkt auf dem Markt positionieren, dann ist das Ziel möglichst viele Einheiten zu verkaufen. Hier sollte ich drauf achten, dass das System auf handelsüblichen Maschinen läuft.
Ach ja, was ich noch dazu sagen wollte. Ich habe keine Ahnung, ob der Oxid Shop an mehr als einer Stelle die Architektur aufgebrochen hat. Ich habe ihn nur als ein Beispiel genommen, da ich weiß, dass er vor kurzem im Gespräch war.
– Komplexere Architekturen sind … komplexer 😉 Die „leichte“ Erweiterbarkeit kann sich genauso ins Gegenteil umkehren
– Sie sind fehleranfälliger, weil mehr Komponenten beteiligt sind
. Sie sind per se auch mal überflüssig: Braucht ein einfacher Shop — auch in Hinblick auf mögliche Erweiterbarkeit — unbedingt 4 oder 5 schichtige Datenabstraktion?
Wie in einem Artikel gelesen, den ich nicht mehr zuordnen kann: Architekturen und Designs haben oftmals fast religiösen Charakter. Es wird garnicht mehr in Frage gestellt, ob sie zweckmässig sind.
Eine gute Architektur und Performance müssen sich ja nicht zwingend gegenseitig ausschließen. Natürlich geht eine zu komplexe Architektur auf die Performance. Wenn man z.B. jeden kleinen Scheiss in einem eigenen Objekt kapselt, dass auch wieder andere Objekte referenziert, dann stösst man irgend wann an die Grenzen. Aber solch eine Architektur würde ich auch nicht als gute Architektur bezeichnen.
Es spricht IMHO nichts dagegen, eine solide und wartbare Architektur zu haben und dennoch die Daten in einer Datenbank stark denormalisiert und teilweise redundant zu halten. Man muss dann nur dafür sorgen, dass diese Redundanz nicht zu Datenabweichungen kommt.
Der Artikel passt recht gut dazu, finde ich: http://www.codinghorror.com/blog/archives/001198.html
Natürlich ist das nicht so simpel wie dargestellt. Es kommt auch darauf an, wie das System dann hochskaliert. Wenn man für dieselbe Menge an Neunutzung (neue Kunden, Logs, Produkte) immer mehr Server braucht (der Bedarf also stark exponentiell ansteigt), dann hat es keinen Sinn, Hardware draufzuwerfen.
Man muss dann davon ausgehen, dass die Architektur irgendwo einen Fehler hat. So etwas gehört bereinigt, das hat aber mit Optimierung nichts zu tun, sondern eher mit Fehlersuche (ja, eine schlechte Architektur ist in meinen Augen ein Fehler).
Ich persönlich halte mich an eine Message, die ich aus „Object Thinking“ mitgenommen habe: Wenn die Zerlegung der Verantwortlichkeiten richtig vorgenommen wurde, kommt von ganz allein irgendwoher auch eine akzeptable Performance.
@Nils korrigiere doch bitte mal den Tippfehler. Der macht Augenkrebs! ;-P
@Ralf: Ist passiert.
Ich will übrigens gar nicht sagen, dass ich auf Performance keinen Wert lege! Performance ist super wichtig. Wenn ich aber die Wahl habe, dann würde ich mich für die saubere Architektur entscheiden. Und natürlich kann und meistens ist eine saubere Architektur auch performant.
@kingcrunch: Du hast natürlich auch Recht. Aber nur weil ich von Architektur rede, heisst es noch lange nicht, dass ich Überabstraktion für sinnvoll halte. Struktur und Konsistenz sollte aber Bestandteil sein, egal wie klein das Projekt ist.
Ich kann die von dir angefuehrten Gruende einer Aufbrechung gut nachvollziehen. Fuer solche „Systemhaus Komponenten“ wie einen Shop, den ich weiterverkaufen will, lassen sich architektonische Hygienemassnahmen schlecht gegenueber dem Kunden verargumentieren. Ganz im Gegensatz zu einem gaenzlich internen Projekt.
Es ist fuer mich aber nicht nur eine Frage der guten Dokumentation. Sondern auch eine der sauberen Kapselung und vor allem der Beweisfuehrung.
Die saubere Kapselung beschreibst du ja schon. Eine Architektur Abweichung sollte dem Entwickler nicht staendig ueber den Weg laufen. Stattdessen sollte sie IMHO eine saubere Schnittstelle bieten und dahinter machen „was sie will“ (gut dokumentiert und so).
Die Beweisfuehrung halte ich aber noch fuer wesentlich wichtiger. Damit meine ich das genaue Pruefen der Architektur (IST Stand). Die Frage ist doch: Warum laesst sich ein Performance Schub nicht architektonisch erreichen?
„Weil es nur mit zusaetzlicher Hardware geht.“ ist fuer mich kein Argument, denn es geht mit einem Hack ja scheinbar auch ohne.
Es ist wichtig herauszufinden, an genau welcher Stelle die architektonischen Richtlinien diesem Performance Gewinn im Wege stehen mit dem Ziel eine Loesung sauber zu integrieren und die Architektur entsprechend anzupassen, zu erweitern, zu aendern.
Ich bin mir ziemlich sicher, dass nahezu jede Verbesserung des Systems mit in einer Architektur vereinbar ist, wenn man bereit ist die Architektur als etwas lebendiges zu betrachten, was sich mit der Zeit auch weiterentwickeln und veraendern darf.
Es ist halt immer eine Sache des Abwägens. Nur manchmal habe ich allerdings den Zweifel, dass dieser oder jene „Verstoß“ wirklich durchdacht ist. Weil selbst beim Verstoß, versucht man diesen eigentlich so zu kaschieren, das er andere Komponenten so wenig wie möglich beeinflusst.
Jeder Mensch bringt glücklicherweise immer ein Stück Individualität mit! Sonst wäre alles unendlich langweilig. Dennoch denke ich: Programmieren ist wie Kunst! Lerne die Regel und dann lerne sie zu brechen!