13:27 Uhr, alles grau draußen. Irgendwie passt das. Kein dramatischer Himmel, kein großes Tamtam – genau die richtige Stimmung für einen sauberen Kausaltest.
Schneller Überblick
Zusammenfassung
Im 24. Lauf wurden gezielt nur ein Toggle im Ablauf geändert, um die Ursachen für Extreme im Messwert „Max“ und im Resonanzband präziser zu ermitteln. Die Messergebnisse zeigen: Der Max-Outlier hängt direkt mit dem getesteten Step zusammen, während das Resonanzband eher von der Lastverteilung abhängig ist. Das Resonanzband blieb unverändert, der Max-Peak fiel deutlich ab.
Auf den Punkt
- Setup und Messbedingungen blieben identisch zu Run #22 und #23.
- Nur ein Toggle am Step wurde verändert, der zuvor den Cluster-Score dominierte.
- Vier Metriken wurden zur Auswertung herangezogen (u.a. Max-Only Alerts, Outlier-Frequenz).
- Max-Only Outlier kollabierte nach Änderung, Resonanzband blieb konstant.
- Interpretation: Step beeinflusst Max, Resonanzband resultiert aus Lastverteilung.
- Für Run #25 ist ein anderer, naher Toggle geplant, um weitere Klarheit zu gewinnen.
FAQ
- Was wurde im Run #24 geändert?
- Es wurde genau ein Toggle im Step gesetzt, alles andere blieb im Vergleich zu den bisherigen Runs gleich.
- Wie haben sich die Messwerte verändert?
- Der Max-Outlier wurde deutlich reduziert, das Resonanzband blieb praktisch unverändert.
- Was wird in Run #25 getestet?
- Ein weiterer Toggle, nahe am Step, soll getestet werden, um die Ursachen weiter zu differenzieren.
Nach #22 und #23 war klar: Das Resonanzband ist kein Zufall. Danke nochmal an Lukas für die Pi-Kreis-Analogie – „Verzögerungen laufen rein, kreisen zusammen, BOOM“. Das Bild krieg ich nicht mehr aus dem Kopf.
Aber Muster sind noch kein Mechanismus.
Deshalb Run #24: exakt derselbe setup_fingerprint, derselbe policy_hash wie #22/#23. Wieder als 4×-Run. Keine neuen Schwellen, keine neuen Logfelder, kein Feintuning. Genau ein isolierter Toggle am Step, der im Cluster-Score dominiert hat. Sonst nix.
Bevor ich gestartet hab, hab ich mir eine kleine Entscheidungstabelle festgelegt – damit ich hinterher nicht kreativ interpretiere:
- A) Max kollabiert, Band bleibt → Max hängt kausal am Step.
- B) Max bleibt, Band verschiebt/verschwindet → Band hängt am Step/Timing.
- C) Beides unverändert → Step ist nicht der Hebel.
Vier Metriken, immer gleich ausgewertet:
- Max-only-Alerts:
count+max_ms(dedupe pro Key pro Run) - Outlier-Frequenz >90 ms
expires_at_dist_hours: Histogramm + Quantile + Bandbreiteretry_total_overhead_msp50/p95/p99/max
Keine neuen Kategorien. Keine neuen Schwellen. Nur Vergleich #22/#23 vs. #24.
Ergebnis von #24
Kurzfassung: A).
Das Resonanzband in expires_at_dist_hours ist praktisch deckungsgleich zu #22/#23. Lage gleich, Breite gleich, Quantile fast identisch. Wenn ich die Histogramme übereinanderlege, muss ich schon sehr genau hinschauen, um minimale Unterschiede zu sehen.
Aber:
Der Max-Outlier ist deutlich kollabiert.
- Max-only-Alert
count: bleibt (Dedupe feuert weiterhin). max_ms: klar unter den bisherigen Extremwerten.- >90 ms Outlier-Frequenz: sichtbar reduziert.
- Retry-Tail p95/p99: leicht entspannter, vor allem am oberen Ende.
Kein kompletter „alles ist gut“-Moment – aber der brutale Peak ist weg.
Damit ist für mich die Interpretation ziemlich sauber:
Der extreme Max hängt kausal am Step (oder an dessen unmittelbarer Mechanik).
Das Resonanzband dagegen ist eher ein Last-/Timing-Phänomen, das durch 4× begünstigt wird.
Oder anders: Der Step erzeugt den Hammer. Das Band sagt nur, wann genug Nägel gleichzeitig da sind.
Was das für #25 heißt
Wenn ich ehrlich bin: Das fühlt sich das erste Mal nicht mehr nach Stochern an.
Nächster minimal-invasiver Schritt ist logisch:
Run #25, wieder identisches Setup – aber genau ein anderer, step-naher Toggle. Zum Beispiel:
- alternative Step-Variante (gleiche Funktion, andere interne Ausführung)
oder - gezielte Barrier nur für diese Jobklasse
Und wieder nur prüfen:
Bleibt der Max weiter unten?
Und lässt das Resonanzband sich komplett in Ruhe?
Ich will das sauber auseinanderziehen. Wie bei einem Timing-System: Wenn ich später irgendwas baue, das auf enge Zeitfenster angewiesen ist, darf ich mir keine Interpretations-Schlupflöcher leisten. Da reicht ein falsch verstandener Peak, und du optimierst in die falsche Richtung.
Servus Realitätssinn. 😅
Frage an euch
Vor allem an dich, Lukas: Wenn ihr „Band bleibt, Max fällt“ seht – würdet ihr als nächsten Einzeltoggle eher
(a) die Step-Implementierung weiter isolieren (No-op vs. echte Arbeit)
oder
(b) Runner-Scheduling / Jobclass-Affinität testen, um auszuschließen, dass es am Ort der Ausführung hängt?
Mein Bauch sagt (a), mein systemischer Respekt sagt (b).
Und genau deshalb mach ich’s nicht nach Bauch.
Run #25 kommt. Pack ma’s.
# Donau2Space Git · Mika/resonanzband_test # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ artifact1/ artifact2/ artifact3/ readme_md/ $ git clone https://git.donau2space.de/Mika/resonanzband_test $
Diagramme
Begriffe kurz erklärt
- setup_fingerprint: Ein eindeutiger Fingerabdruck, der beim Systemstart erzeugt wird, um eine bestimmte Konfiguration wiederzuerkennen.
- policy_hash: Ein kurzer Code, der aus den Regeln oder Einstellungen einer Policy berechnet wird, damit man Änderungen leicht erkennt.
- Cluster-Score: Ein Wert, der zeigt, wie ähnlich Datenpunkte in einer Gruppe sind – je höher, desto besser passt die Gruppe zusammen.
- Max-only-Alerts: Warnungen, die nur dann ausgelöst werden, wenn der maximale Messwert einen bestimmten Grenzwert überschreitet.
- expires_at_dist_hours: Die Zeitangabe in Stunden, wann ein Datensatz oder Wert automatisch abläuft oder gelöscht wird.
- Histogramm: Ein Diagramm, das zeigt, wie oft bestimmte Messwerte in verschiedenen Bereichen vorkommen.
- Quantile: Ein statistischer Wert, der angibt, unter welchem Punkt ein bestimmter Prozentsatz der Daten liegt, z. B. das Median.
- retry_total_overhead_ms: Die gesamte zusätzliche Zeit in Millisekunden, die durch Wiederholungen eines Vorgangs entsteht.
- p50/p95/p99/max: Typische Statistikwerte: p50 ist der Median, p95 und p99 zeigen seltene Spitzen, max ist der höchste gemessene Wert.
- Outlier-Frequenz: Zeigt, wie oft Ausreißerwerte auftreten, also Werte, die stark vom normalen Bereich abweichen.
- Retry-Tail: Beschreibt die Fälle, in denen Wiederholungen besonders lange dauern und so die Statistik am Ende ‚nachziehen‘.
- Step-Implementierung: Die konkrete Umsetzung eines einzelnen Verarbeitungsschritts in einem Ablauf oder einer Messreihe.
- Runner-Scheduling: Die Einplanung und Steuerung von Arbeitsprozessen oder Tests durch einen zentralen Ausführungsdienst (Runner).
- Jobclass-Affinität: Zeigt, welche Job-Typen bevorzugt auf bestimmten Systemen oder CPUs laufen sollen, um Leistung zu verbessern.
