Kategorien
Performance
Kurz und knackig der Titel, aber genau darum geht es, um Performance. Viele von uns arbeiten an Projekten und Webseiten, die möglichst schnell Inhalte ausliefern sollen. Am besten im Millisekundenbereich. Je schneller desto besser. Und ich muss ganz ehrlich sagen, dass ich nichts gegen Performance habe. Gibt schlechtere Eigenschaften die ein Stück Software haben kann. Wer mal mit mir gearbeitet hat, weiß aber auch, dass ich das nicht auf Teufel komm raus hinbekommen muss. Manchmal ist es meiner Meinung nach einfach günstiger mehr Hardware hinzustellen und dafür eine saubere Applikation gebaut zu haben.
Aber egal. Worüber ich heute eigentlich diskutieren möchte ist folgende Frage: „Kann ich Performance nachträglich in ein Projekt einbauen?„. Entstanden ist die Frage bei einem Projekt welches wir betreut haben. Dort waren die Entwickler der Meinung, dass man Performance im letzten Schritt rauskitzeln sollte. Zuerst wurde die ganze Applikation funktional bis zum Ende programmiert und dann wurde angefangen zu profilen und langsame Stellen zu suchen. Ich finde den Ansatz gut, denn so optimiert man genau dort, wo es sein muss. Vielleicht ist ein Refaktoring ein wenig schwerer als es gleich richtig zu machen, dafür muss ich viel weniger Stellen optimieren. Hätte man jede Methode und jeden SQL im Voraus optimiert, wäre man sicherlich um einiges langsamer an das Ziel gekommen.
Zweiter großer Vorteil dieses Vorgehens ist der Funktionsumfang des Produktes. Wir sind relativ früh mit einem „langsamen“ Projekt soweit, dass funktional alles stiiiiiiiiiiimmt ( <- das muss man ganz langsam lesen, damit man merkt wie langsam die Software noch ist). Wenn ich jetzt livegehen müsste so könnte ich das. Zwar mit sehr viel Hardwarekosten, aber es würde gehen. Andersherum wäre der Weg nicht möglich.
Natürlich gibt es auch Leute, auch welche von denen ich sehr viel halte, die anders denken. Es ist viel zu teuer Performance im Nachhinein einzubauen, denn oft muss Architektur dazu angepasst werden und dass ist teuer. Lieber das was man entwickelt gleich gut machen und dafür nur ein Mal.
Leider ist bei dem Projekt, dass wir betreut haben der Livegang relativ schief gegangen, da die Performance nicht gestimmt hat. Ja ich weiß, eigentlich zahlt das auf das Konto der Pre-Optimierer ein. Dabei glaube ich aber, dass wir die Applikation einfach nicht gut genug verstanden hatten und somit durchgeführte Last- und Performance-Tests einfach nicht aussagekräftig genug waren. Natürlich muss man das fachliche System nicht so gut kennen, wenn man alles im Voraus optimiert, da ist die Methode zwei klar im Vorteil.
Trotz des Problems beim ersten Release würde ich trotzdem wieder so arbeiten. Das Projekt funktional nach Hause bringen und dann optimieren. Bei den Lasttest muss man aber dann ein wenig konzentrierter arbeiten, da hier nun mehr von abhängt als bei anderen Ansätzen.
Was denkt ihr? Erzähle ich Müll und das klappt eurer Meinung eh nicht oder würdet ihr den gleichen Ansatz fahren?
Ich finde, dass man sich vorher, also in der Planungsphase damit beschäftigen sollte, an welchen Stellen es zu Leistungsengpässen kommen könnte, damit hier bereits Maßnahmen ergriffen werden können – wie die Auswahl des richtigen Cachingsystems.
Wahrscheinlich ist es jedoch fast überall so, dass hinterher profiled wird um gezielt nur die „Schwachstellen“ zu optimieren. Wer’s mag 😉
Dazu gibt es ein Zitat von Donald Knuth: „premature optimization is the root of all evil“.
Ich denke, dass man wirklich im Nachgang langsame Stellen optimieren sollte. Ansonsten verstrickt man sich in Mikrooptimierungen deren nutzen fragwürdig ist und zumeist den Code nur unleserlich werden lassen.
Ich kenne dieses Vorgehen auch aus einem Projekt und hier war das Vorgehen erfolgreich … 🙂
Noch ein Zitat: „Don’t optimise and don’t do it now“. Ich bin da bei dir (wie du dir eh denken kannst….) – die Vorgehensweise ist ok so (natürlich nur, wenn sauber konzipiert). Interessant finde ich das indirekt verwandte Thema: wie mache ich im Rahmen eines komplexen relaunches relevante lasttests, um nicht im livebetrieb erst reagieren zu können? Anderes Thema, wäre aber auf deine Ideen gespannt.
Ich würde in jedem fall zwischen „code-optimierung“ und „optimierung der architektur hinsichtlich performance“ unterscheiden. Von vornehinein ein Sharding/Clustering der zu persistierenden Daten oder Caching-Patterns in das Denken einzubeziehen, schadet meiner Meinung nicht.
Mir tut es immer in der Seele weh, wenn ich sehe, dass ein Programm mit einem riesigen Aufwand, bei jedem Aufruf immer genau das gleiche macht und immer zu dem gleichen Ergebnis bekommt. Und auch an die Umwelt denken! Eingesparte Last heisst auch Energie-Sparen!
TL;DR;
– Oft die selben Probleme bei verschiedenen Projekten (mit PHP)
– Iteratives arbeiten rockt, sich bei den Performance-Optimierungen aber nicht in kleinkram vertiefen.
Besonders bei der Programmierung mit PHP und *SQL sind es immer wieder die selben Performance fresser.
Iterativ arbeiten (mit jeder Iteration bisschen mehr auf Performance statt nur den funktionalen Anforderungen schauen) hat bei mir immer super funktioner.
Wobei ich eigentlich immer zwischen HW, SW oder Clientseitige SW-Schwächen unterscheiden konnte.
Wobei die SW-Probleme vor allem mit PHP immer die selben sind: fehlendes Caching, fehlende DB-Indizes, tiefe Rekursionen (erinnert Ihr euch noch an die „dynamic Programming“ lektionen in der „Einführung ins Programmieren“ Vorlesung im 1. Semmester?) und bevor ichs vergesse: fehlendes Caching 🙂
HW-Seitig lässt sich schon vieles durch ne gute Konfiguration behben, Prozesse abstellen die Ressourcenintensiv sind, falsche Abfragen früh beenden, mehr RAM / schnellere HD einbauen, Load balancing (eigentlicher SW-Code wird hier praktisch nie angefasst).
Clientseitig kann man selten was machen, hier kann man aber SW-Seitig die Requests minimieren (Zusammenfügen, gzippen und – schonwieder – Cachen).
All diese Schritte kann man Prima ab ca 1/3 des Projektes ins Auge fassen und bei jeder Iteration mehr gewichten. Solange man nicht auf die Suche geht, irgendwelche Nanosekunden pro Request ein zu sparen (Thema: echo „“; oder echo “;), schaded ein bisschen Weitsicht imho nicht.
Bevor man die Peformance optimieren kann, muss man wissen wo es überhaupt Engpässe gibt. Dazu braucht man entweder extrem viel Erfahrung – oder aber testbare Software. Da das mit der Erfahrung ziemlich tricky ist und man sich auch gerne mal verschätzt, würde ich Performance im Nachhinein angehen. Allerdings hilft die Erfahrung natürlich, dass man bei der Architektur der Software gewisse Pitfalls umgeht.
>>[…]dass funktional alles stiiiiiiiiiiimmt[…]
unter Umständen ist es am Anfang noch gar nicht so langsam, weil es da noch nicht so viele Anfragen gibt. Und wenn der Bekanntheitsgrad steigt, steigt auch der „Fortschrittsgrad der Codeoptimierungen“.
lg.
Wenn ich die Software iterativ entwickel und dadurch, sagen wir mal, alle 4 Wochen einen funktionierenden Prototypen habe, gehört für mich die Optimierung, Refactoring etc. in einen solchen Sprint. Am Ende habe ich 2 Dinge gewonnen: funktionierende, getestete Software und auch keinen faulen Gaul, der unkontrolliert gewachsen ist. Zu solch einer Iteration gehört meiner Meinung auch ein Lasttest (ab einer gewissen Größe der Software), um frühzeitig Lahme stellen zu erkennen und auszumerzen, gerade weil es dann noch günstig(er) ist als im Livebetrieb nachträglich noch an den Stellschrauben zu drehen.