3. Juni 2020 | 3 min lesezeit

TECHNISCHE GRÜNDE FÜR SCHLECHTE ENTWICKLUNGSPERFORMANCE

Das #Softwarepicknick ist deine digitale Mittagspause mit den Experten der open knowledge GmbH. Bei diesem meet und eat bringen wir dir hilfreiche Codesnacks und aktuelle Thesen der modernen Softwareentwicklung direkt auf den Tisch und schaffen eine Wiese für deine konkreten Fragen aus dem Projektalltag. Die etwa 30-minütigen Aufzeichnungen der Talks und die wichtigsten Fragen haben wir dir in diesem Blogpost zusammengefasst.

Alles an Metaprogrammierung, was eine klassische Enterprise Java Applikation zur Startup Zeit macht, können wir bereits vorher erledigt haben. Doch wie geht das? Und was können wir von Quarkus in dieser Richtung lernen?

Wenn die Metadaten verarbeitet werden, bevor die Klasse existiert, wie performant ist das? Hört sich an, als könnte das sehr gut laufen?

Ja. Besonders unter Anbetracht der Tatsache, das die meisten Modernen IDEs häufig im Hintergrund Dateien rekompilieren. Das sorgt dafür, dass die Last auf kleine, unabhängig laufende Compiler Zyklen verteilt wird. Wir müssen also nicht einmal „lange“ warten, sondern können die sowie im Hintergrund laufenden Zyklen nutzen. Plus natürlich der Fakt, dass der Compiler alles das was wir sonst händisch machen würden, bereits erledigt hat.

Es hört sich so an, als ob statisch gegenüber im Grunde nur Vorteile bringt. Warum hat es dann so lange gedauert, jetzt mit Quarkus, dass das kommt?

Im Grunde liegt dies vermutlich daran, dass Standards auf Laufzeit Verarbeitung ausgelegt sind. Diese Standards existieren zumeist schon länger, als die statische Metaprogrammierung in Java. Diese Standards müssten jetzt umgeschrieben und neu aufbereitet werden, was allerdings sehr viel Zeit braucht, nicht nur um diese neu zu definieren, sondern auch um bestehende Applikationen an diese neuen Standards anzupassen. Quarkus hingegen ignoriert diese Standards „bewusst“. Es biegt sehr viele Standards so hin, dass es auch zur Compile Time funktioniert. Und das kostet natürlich Zeit.

Warum hat es sich bisher bei JavaEE und anderen Technologien nicht durchgesetzt?

Es existiert ein sehr großes Ökosystem an JEE Frameworks und APIs, die wir uns auch tag täglich zu Nutzen machen. Alle diese sind auf die Standards ausgelegt, dass zur Laufzeit Berechnungen durchgeführt werden können. Halt dynamische Metaprogrammierung. Diesen Standard zu ändern würde bedeuten alle Frameworks, alle APIs und dann auch alle Applikationen anzupassen. Und das ist Arbeit an laufenden Systemen. Vielleicht erklärt hier der Leitspruch „never touch a running system“ die Lage.

Wie wirkt sich der Workload des dauerhaften Recompile auf die Leistung während der Entwicklung aus? Sprich, Last auf dem Rechner?

Nicht so unglaublich, wie man vermutlich denken würde. Achtung: Selbstverständlich hängt das davon ab, wie wir den Annotation Processor designen! Wenn wir einen unglaublich großen und komplexen Annotation processor bauen, der lange rechnet, dann dauert das auch dementsprechend länger. Standardmäßig allerdings ist das nicht so viel mehr. Die IDE recompiliert Dateien, die sich geändert haben, immer wieder während wir arbeiten neu. Manchmal allerdings auch erst alles auf einen Schlag. Wir haben dann zwar beim Kompilieren eine etwas größere Last auf den Rechner, allerdings hätten wir diese auch, wenn die Applikation hoch fahren würde. Wann das ganze ins Gewicht fällt, ist wenn wir sehr sehr viele Annotation Processor haben. Allerdings lässt sich dieses mit geschicktem Design auch umgehen.

Ergibt es jetzt, wo wir immer mehr auf kleine Microservices gehen, wirklich Sinn, wenn diese einzeln schlicht kleiner und schneller werden?

Ja und Nein. Es gibt einige Wenige Anwendungsfälle, die einen Microservice in wenigen nano Sekunden bräuchten. Es stimmt allerdings, dass dies normalerweise nicht wirklich relevant wird. Systeme wie Kubernetes nutzen health checks, um zu schauen ob eine Applikation läuft. Ist dieser auf 10 Sekunden eingestellt, dann macht es keinen Unterschied ob der Microservice in 0.01 MS oder 5 Sekunden hochgefahren ist. Wo es sich auswirkt und was wirklich ins Gewicht fällt, ist allerdings die Entwicklungszeit.

Mir ist noch nicht ganz klar, wie die Entwicklungsperformance verbessert wird. Meinst Du es sollte mehr Metaprogrammierung gemacht wird?

Ja, aber entsprechend des Vortrages statische im Gegensatz zu Dynamischer. Dann würden unsere Applikationen schneller hoch fahren, es ist „hot deployment“ möglich (also die laufende Applikation kann geänderte und neu Kompilierte Dateien einfach annehmen) und für uns wird es wesentlich übersichtlicher, was dort im Hintergrund passiert. Keine schwarze Voodoo Magie mehr, sondern einfacher, klassischer Code in den wir hinein gucken können.

Die Slides zum Talk sind auf Slideshare verfügbar:

Die weiteren Talks aus der #Softwarepicknick Reihe findest du auf unserem Blog.


Keine Kommentare

Kontakt

OPEN KNOWLEDGE GmbH

Standort Oldenburg:
Poststraße 1, 26122 Oldenburg

Standort Essen:
II. Hagen 7, 45127 Essen