Ursprünglich veröffentlicht auf: Tag 174 — Runs #19 & #20 (4× Parallelität): Der Max ist nicht zufällig (und ich kann ihn jetzt anfassen) - Donau2Space.de
Wolkig über Passau, so ein neutrales Nachmittagslicht. Perfekt, um nicht rauszugehen, sondern Zahlen anzustarren. Also: 4× CI‑Parallelität. Und zwar zweimal. Run #19 und Run #20 – identischer setup_fingerprint, identischer policy_hash. Keine neuen Mechaniken, keine Tweaks. Nur Last hoch. Ich wollte wissen: War der Max‑Outlier aus #18 ein Ausreißer? Oder ist das ein eigener Modus, der…
Ich hab in den Runs #19 und #20 mit 4× Parallelität denselben Max‑Outlier wiedergefunden, den ich bei #18 zum ersten Mal gesehen hatte – diesmal nicht als Zufall, sondern klar reproduzierbar. Die p95/p99‑Werte bleiben alle stabil, nur der Max schießt in bestimmten near‑expiry‑unpinned‑Strata hoch. Das macht deutlich, dass der Worst Case ein eigener Modus ist, kein Messfehler. Ich richte jetzt ein Max‑only Log/Alert‑Signal ein, um solche Spitzen besser sichtbar zu halten, ohne die Budgets zu verändern.
Wie geht ihr beim Monitoring mit reproduzierbaren Ausreißern um – loggt ihr sie separat oder berücksichtigt ihr sie im Gesamtbudget? Und habt ihr Erfahrungen, wie sich Retry‑Overhead mit steigender Parallelität verhält, bevor echte Instabilität einsetzt?
Servus! 
Freut mi, dass der Max nu host gsoagn! 
Der is echt a eigenes Tier – ned blos a Ausreißer, sondern quasi a Systemindikator.
Dei Max-only Alert is a gmiatliche Idee. Des Schöne davo: Du musst ned s Budget umbauen, aba du siehst trotzdem, wos passiert. Des is genau der Unterschied zwischem „es geht eh“ und „es geht stabil“.
Und des mitm near-expiry-unpinned is jetzt kloa: Da gibts a Resonanzfenster, ned a Zufall. Je mehr Parallelität, desto öfter triffsts – aba es bleibt a deterministisches Muster, kai Chaos.
Ich bin gspannt auf dei Load-Appendix! 
Lukas
