Quark

13. Dezember 2023

In letzter Zeit sind auch Technik-Themen wieder vermehrt im Fokus. Eines liegt mir besonders am Herzen: Das Laufzeitverhalten von Java-Anwendungen. Es gibt immer wieder Behauptungen, manche Java-Prozesse benötigten mehrere Sekunden zum Starten.

Fakt ist, dass es mit so ziemlich jeder Programmiersprache hinzubekommen ist, dass ein Prozess so lange zum Starten braucht. Es ist dann aber stets ein Anzeichen von ineffizienter Architektur des Programmes.

In diesem Beitrag soll ein Vergleich näher betrachtet werden, der auf der Internetseite von Quarkus angestellt wird, die u.a. das hier gezeigte Schaubild enthält.

Traditional Cloud-Native Stack und Quarkus

Im Schaubild werden zwei Anwendungsfälle "REST" sowie "REST + CRUD" betrachtet. Es wird unterstellt, dass ein Traditional Cloud-Native Stack zwischen 4,3 (REST) und 9,5 Sekunden (REST + CRUD) zum Start benötigt.

Demgegenüber benötigt Quarkus angeblich 2 Sekunden (REST + CRUD) sowie 0,95 Sekunden (REST). Mit der von Quarkus unterstützten native ahead of time Kompilierung auf Grundlage der GraalVM käme man sogar auf 0,016 Sekunden (REST) und 0,042 Sekunden (REST + CRUD).

REST

Nun darf zuallererst gefragt werden: Was um Himmels willen machen ein Traditional Cloud-Native Stack und auch Quarkus beim Start, was ohne AOT-Kompilierung zwischen 1 und 4,3 Sekunden dauert? Eine gewöhnliche REST-Funktionalität ist schließlich nichts weiter als HTTP-Requests, die von einem in eine Applikation eingebetteten Webserver entgegengenommen und beantwortet werden.

Der Start einer beliebigen Java-Anwendung mit nur dieser Funktionalität erfordert auch ohne AOT-Kompilierung nur wenige Hundertstelsekunden.

CRUD

Auch für CRUD, also Operationen für Create, Read, Update, Delete in einer Datenbank ist neben dem zum Fabrikat der Datenbank passenden Treiber im Grunde nichts weiter erforderlich als eine Programmbibliothek für objekt-relationales Mapping, die auf die Java Database Connectivity (JDBC) aufsetzt. Insbesondere für gewöhnliche CRUD-Operationen ist die Implementierung von etwas wie der Java Persistence API (JPA) nicht nötig und es darf auch gefragt werden, ob die JPA in der vorliegenden Form überhaupt nötig ist.

Wenn wir einmal Fragen der Latenz und der Verwendung eines Connection Pools ausklammern, die jede Datenbankverbindung aufwirft, fällt eine Unterstützung von Datenbank-Operationen für die Startzeit eines Java-Prozesses nicht ins Gewicht.

Es darf also abermals gefragt werden, was Quarkus oder ein Traditional Cloud-Native Stack noch alles machen, um auf eine Startzeit von 2 - 9,5 Sekunden zu kommen.

Gegenbeispiel: Laufzeit

Ein REST-Dienst auf der Basis einer sehr minimalistischen Lösung wie Neon ist nach 0,04 Sekunden betriebsbereit. Ein Dienst mit REST+CRUD auf Basis von Neon und BaseLink benötigt ebenfalls 0,04 Sekunden bis zur ersten Antwort auf Requests. Wohlgemerkt auf OpenJDK ohne AOT-Kompilierung.

Was bei Quarkus 1-2 Sekunden benötigt, schafft eine schlankere Java-Lösung ohne AOT-Kompilierung in nahezu der Zeit, die Quarkus nur erreicht, wenn native ahead of time Kompilierung eingesetzt wird. Neon und BaseLink sind ohne AOT-Kompilierung fünfundfzwanzigmal so schnell wie Quarkus, vom Traditional Cloud Stack gar nicht zu sprechen.

Gegenbeispiel: Größe

Dasselbe Bild ergibt sich beim Speicherbedarf. Was laut Schaubild mit Quarkus 12 MB (REST) bzw. 28 MB (REST + CRUD) an Speicher erfordert, bleibt mit Neon und BaseLink bei 0,5 - 1 MB und damit um mehr als eine ganze Größenordnung kleiner.

Einordnung

Quarkus und ein Traditional Cloud-Native Stack werden als Industriestandards betrachtet. Beide sind derart groß und schwerfällig, dass ein Einsatz ohne ahead of time Kompilierung nicht mit einfachen Java-Lösungen mithalten kann.

Ein von Grund auf schlanker und effizienter Programmierstil erreicht bereits mit herkömmlichen Java-Bordmitteln und ganz ohne ahead of time Kompilierung eine Geschwindigkeit und Größe, die um Größenordnungen schneller und kleiner ist als Quarkus oder ein Traditional Cloud-Native Stack.

Nun ließe sich einwenden, dass Neon und BaseLink ja nur meine eigenen Lösungen sind, die weit entfernt sein mögen von "bullet proof Industriestandards". Das kann jeder selbst bewerten und die Industrie muss ja meine eigene Lösung nicht verwenden. Jeglicher Industriestandard muss sich aber daran messen, was in puncto Laufzeitverhalten und Umfang technisch möglich ist.

Was gegenüber dem technisch Machbaren ohne sicht- oder spürbaren funktionalen Zugewinn das Zehn- oder Zwanzigfache an Laufzeit und Größe erfordert ist zu groß und zu langsam für einen Standard.