13:30 in Passau, alles wolkig, die Donau wirkt wie ein graues Band. Kein Drama draußen – passt eigentlich gut. Heute ging’s nicht um Stimmung, sondern um Messwerte.
Nach Run #17 war klar: pinned ist sauber, Δt<0 ist stratum-spezifisch (near-expiry-unpinned) und kein Zufall. Und Lukas hatte recht: Wenn ich 80/90 ms als Schwellen setze, dann muss ich auch den Stress-Test liefern. Also pack ma’s.
Setup: nur ein Drehrad
Run #18 ist bewusst langweilig im Setup:
- gleicher Code
- gleicher
policy_hash - gleicher
setup_fingerprint - nur CI-Parallelität auf 2× erhöht
Keine neuen Schwellen. Keine Retry-Tweaks. Kein „ach, das fix ich noch schnell“. Genau ein Last-Drehrad.
Ziel war klar:
- p95 ≤ 80 ms
- p99 ≤ 90 ms
unknown_rate = 0- Heilungsrate ≥ 99 %
Und diesmal nicht nur auf p95/p99 schauen, sondern auch auf Max und Retry-Verhalten.
Ergebnis: stabil — aber mit echtem Ausreißer
Run #18 ist durch. Direkt neben #17 gelegt.
Kurzfassung:
unknown_ratebleibt 0 ✅- pinned-Stratum weiterhin ohne Δt<0 ✅
- Δt<0 tritt erneut nur im near-expiry-unpinned-Stratum auf
- Retry heilt in diesem Lauf wieder 100 %
Das Gate hält also auch unter 2× Parallelität.
Was sich verändert hat: Die Latenz-Verteilung ist leicht nach oben gerutscht. Kein Drama – p95 und p99 bleiben unter meinen 80/90 ms. Aber:
Zum ersten Mal sehe ich einen klaren Max-Outlier, deutlich oberhalb des p99.
Kein unknown. Kein Schwellenbruch. Aber ein einzelner Wert, der sichtbar aus der Reihe tanzt.
Und genau das ist interessant.
Bisher habe ich stark auf p95/p99 optimiert – völlig legitim für ein Gate. Aber unter Last merkt man: Der Max ist eine eigene Risikolinse. Er sagt nicht „System instabil“, aber er sagt: Hier gibt’s einen Rand, den du kennen solltest.
Das fühlt sich weniger wie Bug-Jagd an, mehr wie Timing-Arbeit auf Systemebene. Wenn viele Jobs gleichzeitig laufen, verschieben sich nicht nur Mittelwerte – die Ausreißer erzählen die eigentliche Geschichte.
Retry-Overhead unter 2×
retry_total_overhead_ms bleibt im bekannten Rahmen:
- p50 im gewohnten Bereich
- p95/p99 weiterhin unter Budget
- ein einzelner höherer Max (konsistent mit dem oben gesehenen Ausreißer)
Wichtig: retry_taken_rate ist nicht explodiert. Keine Kettenreaktion unter Last. Das war meine eigentliche Sorge.
Heißt für mich: Gate V1 ist unter moderater Last statistisch stabil. Die Mechanik kippt nicht plötzlich.
Load-Appendix (Start)
Ich habe mir direkt ein kleines Appendix-Skeleton für die Decision-Card gebaut:
Vergleich #17 vs #18:
- p95 / p99 / max
retry_taken_rateheal_rate- Stratum-Aufschlüsselung
Zusätzlich logge ich jetzt beim Max-Outlier explizit:
- Stratum
- Job-Parallelität
Nicht um sofort Alarm zu schlagen, sondern um bei #19/#20 nicht nur zu sagen „Max war hoch“, sondern wo genau.
Nächster Schritt: 4×
Jetzt wird’s spannend. Runs #19 und #20 mit 4× Parallelität – sonst identisch.
Erst danach entscheide ich sauber:
- Bleibt
MODE=warnDefault? - Ergänze ich nur ein zusätzliches Log-Flag für Max > X?
- Oder zeigt sich unter 4× ein echter Strukturbruch?
Noch fasse ich nichts an. Keine neuen Schwellen. Keine Mechanik-Änderung. Erst messen.
Und ganz ehrlich: Diese Art von Last-Tests fühlt sich gerade wichtiger an als jede kosmetische Optimierung. Wenn viele Dinge gleichzeitig passieren und das System trotzdem präzise bleibt – das ist die Art von Robustheit, die man später in deutlich größeren Kontexten braucht.
Kleiner Schritt. Aber diesmal einer mit Gewicht.
Run #19 steht als Nächstes an.
Diagramme
Begriffe kurz erklärt
- Retry-Overhead: Der zusätzliche Zeit- oder Leistungsaufwand, der entsteht, wenn ein Vorgang erneut versucht wird, weil er beim ersten Mal fehlgeschlagen ist.
- Load-Appendix: Eine Zusatzinformation, die beim Laden eines Systems oder Moduls hinzugefügt wird, um spezielle Einstellungen oder Messdaten zu ergänzen.
- p95: Ein Messwert, bei dem 95 % aller Beobachtungen darunterliegen – zeigt also die typische Obergrenze der meisten Werte.
- p99: Ein Messwert, bei dem 99 % aller Daten kleiner sind – gut für das Erkennen von seltenen, langsamen Ausreißern.
- p50: Der Medianwert, also genau die Mitte aller Messungen, bei dem 50 % darunter und 50 % darüber liegen.
- unknown_rate: Der Anteil oder die Rate von Messungen, deren Ergebnis oder Quelle nicht eindeutig bestimmt werden konnte.
- retry_total_overhead_ms: Die gesamte zusätzliche Zeit in Millisekunden, die alle Wiederholungsversuche zusammen verbraucht haben.
- retry_taken_rate: Der Prozentsatz der Versuche, bei denen tatsächlich ein erneuter Versuch stattgefunden hat.
- heal_rate: Die Rate, mit der ein System fehlerhafte Zustände selbständig korrigiert oder stabilisiert.
- Stratum-Aufschlüsselung: Eine Darstellung, wie die Daten in verschiedene Schichten nach Genauigkeit oder Signalquelle (z. B. GPS, NTP) aufgeteilt sind.
- Max-Outlier: Der größte Messwert, der deutlich außerhalb des üblichen Bereichs liegt – also der stärkste Ausreißer.
- setup_fingerprint: Ein eindeutiger digitaler Abdruck einer Systemkonfiguration, mit dem man z. B. zwei Setups vergleichen kann.
- policy_hash: Ein Hash-Wert, der den Inhalt einer bestimmten Regel- oder Richtlinienkonfiguration eindeutig beschreibt.
- Decision-Card: Eine kompakte Übersicht, die zeigt, welche Wahl ein System oder Benutzer in einer bestimmten Entscheidungssituation getroffen hat.
