In diesem Teil meiner Serie über WPO betrachte ich den traditionellsten Teil: Die auf dem Server laufende (selbst geschriebene) Software. Deswegen enthält die Optimierung also auch alle Software Design Entscheidungen und den entstandenen Quelltext. Hier gelieferte Beispiele sind an Java angelehnt, da ich mich größtenteils in diesem Umfeld aufhalte.
Skalierbare Architekturen
In meiner Zeit vor codecentric habe ich an einigen Projekten gearbeitet, welche (hoffentlich ohne mein Verschulden) in Probleme geraten sind und immer spät waren. Als ein Resultat wurden Systemtests und Skalierbarkeitstests gestrichen. Das war auch gar nicht so tragisch, da am Ende des Projektes geplante Tests sowieso keinen Probleme identifizieren können, die noch realistisch behebbar sind. Bei codecentric arbeiten wir an der stetigen Verbesserung unseres agilen Entwicklungsprozesses, um diesen Problemen entgegenzuwirken. Also denken wir über ein skalierbares Design schon ab dem ersten Tag nach. Die Frage „Was müssen wir ändern, um 2 Server hinzuzufügen?“ sollte idealerweise mit „nichts“ beantwortet werden. Wie kommt man also dahin? Einige der Faktoren für skalierbares Design habe ich in meinem Infrastruktur orientierten WPO schon angesprochen.
Agile Methoden helfen sicher, aber auch ohne kann man mit Skalierbarkeit schon von Anfang an experimentieren. Dazu gehören rudimentäre Lastests durch die man die Verhaltensmuster der Anwendung unter Last studieren kann. Zwar würde ich sehr gerne diese Tests ständig ausgeführt und als Teil der Definition of Done sehen, jedoch denke ich, dass es sinnvoll ist, diese überhaupt früh durchzuführen.
Allerdings wird durch Tests die Skalierung nicht magisch umgesetzt. Sie muss designt werden. Gernot Starke sprach auf unserem letzten Meet The Experts über das Problem von Softwarearchitekten etwas über gute Designs zu lernen. Sein Argument war, dass trotz den Veröffentlichungen der Designentscheidungen und Lösungen großer Firmen wie Facebook , Twitter , Ebay , Amazon und Google, diese nicht auf die Anwendungen anwendbar seien, welche wir tagtäglich entwickeln.
Ich denke er hat recht. Und irrt sich zugleich. Ja, wir haben vielleicht keine hunderttausend Datenbankabfragen pro Sekunde. Allerdings kann ein Design, welches diese Extrema unterstützt besser funktionieren und skalieren als etwas, was ich mir selbst ausgedacht hätte. Und das gilt auch für kleinere Anwendungen, weswegen ich davon überzeugt bin, dass es Sinn macht, sich diese Beispiele anzusehen.
Fremdsoftware regelmäßig aktualisieren
Es ist nicht nur unser Design und unsere Programmierung, die die Performance des Gesamtsystems ausmacht. Oft sind eine Reihe von weiteren Softwareprodukten involviert. Ich nehme an, dass wir mindestens ein Dutzend externer Software als Teil unserer Anwendung oder Lösung verwenden. Das ist keineswegs schlecht, denn wir müssen diesen Code nicht schreiben und sparen so eine Menge Zeit. Auch müssen wir keinesfalls Experten in Regelsystemen, Netzwerkverbindungsverwaltung, Caches, Kodierung, Kompression oder vielem mehr sein. Wir können uns allein auf die Erstellung unserer Anwendung konzentrieren. Wenn wir also einer Reihe von guten Komponenten vertrauen, warum aktualisieren wir diese dann nicht regelmäßig? In den vergangenen Jahren hat fast jedes Produkt in jedem Release „Performance“ als Punkt auf der Änderungsliste gehabt. Wir nutzen dies aber viel zu selten, wofür es meiner Meinung nach 2 Gründe gibt:
- Angst vor Problemen mit Abwärtskompatibilität
- Chaotische Drittanbietersoftwareverwaltung mit einem unflexiblen Prozess
Zwei sehr triftige Gründe. Allerdings wird der erste Grund im Laufe der Zeit immer gravierender. Nach einer gewissen Zeit haben sich die kleinen Anpassungen zu einem großen Haufen angesammelt, den niemand mehr anfassen möchte. Ich empfehle deshalb oft auf Aktualisierungen zurückzugreifen, da man nur so Performanceverbesserungen von den externen Experten erhält. Interessanterweise existiert sogar ein Zusammenhang zwischen der Angst vor dem Wechsel und dem (Performance) Gewinn. Applikations-Server, Datenbanken, UI Frameworks und Regelsysteme erhalten oft weitaus bessere Performanceschübe bei einem Upgrade als die Aktualisierung einer Minor-Version von Apache commons-lang. Aber die Angst ist größer, was wahrscheinlich daran liegt, dass sie größer und komplexer sind. Genau aus diesem Grund bieten sie aber für ihre Autoren ein gutes Optimierungspotential. Und wenn wir Angst vor dem Update einer Bibliothek haben. Warum setzen wir sie dann überhaupt ein?
Das zweite Problem ist schwieriger zu lösen, und leider denken viele es würde ausreichen Maven auf das Problem zu werfen und es würde verschwinden. Allerdings ist es oftmals so, dass kein gründliches Abhängikeitsdesign durchgeführt oder das Problem einfach ignoriert wird. Zwar kann ein Buildmanagementsystem und die Deklaration von Abhängigkeiten und zum Beispiel OSGi als Laufzeitsystem das Thema technisch unterstützen, aber die Lösung muss in der Planung eines sauberen Vorgehens gefunden werden.
Die Wahl des schnellsten Kommunikationsprotokolls
Kommunikationsprotokolle sind sehr wichtig in verteilten Systemen. Jedoch treffen wir häufig nicht die richtige Entscheidung. Durch den SOA Hype bedingt, bauen wir alle Software, die SOAP Webservices verwenden. Die denkbar schlechteste Wahl – zumindest aus Performancesicht. Oft sind dann auch noch die Services falsch geschnitten, wodurch übermäßig große Datenmengen übertragen werden müssen oder unnötig viele Remoteaufrufe stattfinden. Nehmen wir an, wir haben ein gutes Design, dann kann das verwendete Protokoll trotzdem eine große Bedeutung haben. Es gibt einige öffentliche Benchmarks, wie das JBoss Remoting Benchmark , oder das Java Benchmark von Daniel Gredler sowie viele andere. Idealerweise führt man natürlich das Benchmark selber auf eigenem Code durch.
Im Falle von AJAX ist die Wahl einfacher, da es im wesentlichen nur 3 Protokolle gibt die alle über HTTP abgewickelt werden.
- XML – Doch auf Grund der enormen Datenmengen von fast niemandem verwendet.
- JSON – Das beliebteste Protokoll. Oftmals handelt es sich nur um Schlüssel-Wert Paare. Kann schnell in native JavaScript-Objekte übersetzt werden.
- JavaScript – Anstelle von lediglich Objekten wird ausführbarer JavaScript Code übertragen. Dies ermöglicht viele Tricks, ist aber oft ein Anzeichen eines zu generischen Interfaces.
Eine interessante Alternative dazu werden WebSockets werden, welche in zukünftigen Browserversionen Unterstützung finden werden und schon jetzt durch Produkte wie Kaazing ermöglicht ist.
Einblicke in die Anwendungsperformance
Für WPO ist die Anwendung auf der Serverseite eine große schwarze Box, doch leider ist sie oft der Hauptverursacher für langsame Antwortzeiten. Dies kann nicht durch WPO Tricks optimiert werden, sondern benötigt Nachforschungen über ihre Ursache in der Anwendung. Dafür eignen sich Application Performance Monitoring Lösungen. Anders als traditionelle Systemüberwachung schauen sie in die Anwendung hinein, weshalb APM Lösungen oft auf eine Programmiersprache begrenzt sind. Für Java ist AppDynamics die derzeit beste Lösung auf dem Markt, weswegen es auch in unserem Lösungsportfolio seinen Platz findet. Mit einer Monitoringlösung erhält man schnell die nötige Information um sich Quellen von Performanceproblemen genau anzusehen. Arbeitet man an der Behebung solcher Probleme sind Profiler auf den Entwicklermaschinen das geeignete Mittel, um sämtliche noch so kleinen Details über die untersuchte Transaktion zu erfahren und alternative Lösungsansätze gegeneinander zu bewerten. Für Java empfehle ich YourKit oder JProfiler .
Leider schauen sich viele WPO Experten die Serverseite zu wenig an, obwohl sie oft einen wichtigen Anteil an der Gesamtperformance hat. Bei codecentric hingegen haben wir jahrelange Erfahrung in der Lösung solcher Probleme; von Design und Architektur bis Tief in die Codeebene. In der letzten Ausgabe dieser Serie werde ich dann über die am meisten gehypten Aspekte von WPO sprechen: Optimierungen im Browser.
Meine WPO Serie:
- Web Performance Optimierung ist das neue SEO
- Web Performance Optimierung: Die Infrasturktur
- Web Performance Optimierung: Serverseitige Software
- Web Performance Optimierung: Clients
War dieser Beitrag hilfreich?
Weitere Beiträge
von Fabian Lange
26.3.2015 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Fabian Lange
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.