Betrieb
Ein Belastungstest, bei dem nichts kaputtgeht, war keiner
Wir haben einen Tag lang versucht, unsere eigene Plattform kaputt zu machen. Drei Dinge sind kaputtgegangen. Das ist der nützliche Teil des Berichts, nicht die Zahlen davor.
Die meisten veröffentlichten Lasttests beantworten die falsche Frage. Sie zeigen, wie viele Abfragen ein System pro Sekunde schafft, solange alles gutgeht. Interessant ist aber, was passiert, wenn es nicht mehr gutgeht — und ob man das vorher erkennt.
Was ein Belastungstest zeigen muss
- Wo die Grenze liegt: bei wie vielen gleichzeitigen Nutzern die erste Abfrage nicht mehr durchläuft
- Was an der Grenze passiert: eine klare Abweisung oder ein System, das hängt
- Wie lange die Erholung dauert: wie schnell nach Lastende wieder normal geantwortet wird
- Ob jemand eingreifen musste — und wenn ja, wie oft
Die dritte und vierte Frage sind die, die im Betrieb zählen. Ein System, das unter Last langsamer wird und sich danach von selbst fängt, ist beherrschbar. Eines, das hängen bleibt und einen Neustart braucht, ist es nicht — egal, wie gut die Zahlen davor aussahen.
Vier Szenarien, eskalierend
Wir sind gegen eine bewusst bescheidene Anlage gefahren: eine einzelne virtuelle Maschine mit sechs Kernen und 24 GB, ohne Swap, mit der vollständigen Plattform darauf und 60 Millionen Zeilen als Datengrundlage. Alle Szenarien liefen über die normale, abgesicherte Schnittstelle — mit Anmeldung, Rechteprüfung und Audit, nicht an der Sicherheit vorbei.
| Szenario | Last | Was dabei herauskam |
|---|---|---|
| Nutzertreppe | 8 → 16 → 32 → 64 gleichzeitige Analysten | Bis 32 alles fehlerfrei; ab 64 wird abgewiesen |
| Dauerfeuer | 32 Nutzer, kurze Abfragen, 60 Sekunden | 3.176 Abfragen, Median 0,59 s |
| Speicher-Monster | Eine absichtlich unsinnige Abfrage | Nach Sekunden abgebrochen, alles andere lief weiter |
| Todesstoß | 128 Nutzer und 8 Monster gleichzeitig | 42 vollwertige Analysen fertig, der Rest abgewiesen |
Die wichtigste Zahl ist nicht die schnellste
Über alle Läufe: kein einziger Absturz der Abfrage-Engine. Dreißig Sekunden nach der härtesten Laststufe wurde eine normale Abfrage in 76 Millisekunden beantwortet — ohne Eingriff, ohne Aufräumen.
Möglich macht das eine Eigenschaft, die in Lasttests selten gewürdigt wird: die Abweisung. Wer über die zugesagte Parallelität hinaus feuert, bekommt sofort eine klare Meldung statt eines hängenden Systems. Das ist keine Erfindung, sondern eine Konfiguration der Abfrage-Engine — Trino kennt harte Grenzen für gleichzeitig laufende Abfragen und für die Länge der Warteschlange; ist beides erreicht, wird abgewiesen.
In der Auswertung sieht das schlecht aus: 9.433 abgewiesene Anfragen im härtesten Szenario. Die Zahl wirkt vor allem deshalb hoch, weil das Testwerkzeug abgewiesene Anfragen sofort wiederholte. Entscheidend ist, was daneben steht — 42 vollwertige Analysen über 60 Millionen Zeilen liefen in derselben Zeit sauber durch.
Drei Treffer, ehrlich
Ein Zerstörungstest, bei dem nichts bricht, hat nicht ernsthaft getestet. Wir hatten drei Treffer:
- Der Anmeldedienst fiel unter einem Anmeldesturm aus: 32 gleichzeitige Anmeldungen drückten ihn über sein damaliges Speicherlimit, der Wächter startete ihn neu. 23 Sekunden bis zur vollen Betriebsbereitschaft, ohne Handgriff. Abhilfe war eine Zahl in der Konfiguration.
- Die Engine riss beim Import von 60 Millionen Zeilen — solange ihr Container zu knapp bemessen war. Mit dem für diese Datenmenge angemessenen Limit lief derselbe Import in 73 Sekunden durch, über 800.000 Zeilen je Sekunde.
- Zwei Funde am Rande, beide kein Plattformfehler: der Brute-Force-Schutz griff bei 32 parallelen Anmeldungen desselben Kontos — im Test lästig, im Betrieb genau richtig. Und unser eigenes Messwerkzeug sprengte einen Hilfscontainer, weil es versehentlich darin lief.
Dimensionierung ist kein Architekturfehler
Der zweite Treffer ist der lehrreichste, weil er eine Unterscheidung erzwingt, die in Ausschreibungen regelmäßig verschwimmt. Ein System, das bei zu knappem Speicher abbricht, hat kein Architekturproblem — es hat ein Größenproblem. Die Prüffrage lautet: Verschwindet der Fehler, wenn man eine Zahl in der Konfiguration ändert? Dann ist es Dimensionierung. Bleibt er, ist es Architektur.
Der Unterschied ist praktisch: Dimensionierung löst man vor dem Produktivgang mit einer Messung. Architektur löst man gar nicht, jedenfalls nicht in dem Projekt, in dem man es merkt.
Was wir für die Größenwahl gelernt haben
Die naheliegende Reaktion auf Last ist, einen zweiten Rechenknoten dazuzustellen. Auf derselben Maschine bringt das nichts — er teilt sich dieselben sechs Kerne, und in unserem Vergleich lag diese Konfiguration in fast jedem Szenario hinter der einfachen. Was dagegen viel brachte: derselben Engine mehr Arbeitsspeicher geben. Von 8 auf 16 GB stiegen die fertigen Analysen unter Höchstlast um 70 Prozent, der Durchsatz kurzer Abfragen um 43 Prozent.
Die Regel daraus ist unspektakulär und gilt vermutlich für jede Engine dieser Bauart: Auf einer Maschine eine Engine, mit so viel Speicher, wie das Blech sicher hergibt. Erst darüber hinaus weitere Maschinen, die eigene Kerne mitbringen. Wer mehr Knoten auf dasselbe Blech stellt, verwaltet mehr und rechnet nicht schneller.
Was der Test nicht zeigt
Er zeigt eine Maschine bei einer Datenmenge. Über Terabyte-Bestände sagt er nichts, über den Verbund mehrerer Maschinen ebenso wenig, und über andere Abfragemuster als die getesteten auch nicht. Wer aus solchen Zahlen eine allgemeine Leistungsaussage macht, tut genau das, was Lasttests so oft wertlos macht.
Was er zeigt, ist etwas anderes und für eine Betriebsentscheidung nützlicher: dass die Grenze bekannt ist, dass sie sauber abgewiesen wird und dass nach ihr niemand aufräumen muss.
Quellen
Alle Zahlen in diesem Beitrag sind belegt. Wo keine belastbare Quelle vorliegt, steht keine Zahl.
- Trino – Resource groups (Parallelität und Warteschlangen)
- lavalake – Belastungsprobe der Referenzinstallation, 6. September 2026 (eigene Messung)