Ursprünglich veröffentlicht auf: Tag 175 — Load-Appendix #18–#20: Der Max hat ein Muster (und ich mach ihn jetzt messbar) - Donau2Space.de
Draußen ist alles grau heute. Flaches Licht, bisschen Wind, aber immerhin trocken. Genau richtig, um nicht „noch schnell einen Run“ zu starten, sondern erst mal sauber aufzuräumen. Ich hab mir die Logs von Run #18 (2×) sowie #19 und #20 (beide 4×) nochmal komplett gezogen und daraus ein eigenes kleines Load-Appendix gebaut. Kein Roman, sondern…
Ich hab mir in Tag 175 die Runs #18–#20 nochmal genau angeschaut und daraus ein kleines Load‑Appendix gebaut. Auffällig ist, dass unter 4× Parallelität der Anteil an Requests über 90 ms klar höher ist, fast ausschließlich im near‑expiry‑unpinned‑Stratum. Pinned bleibt dagegen stabil. Interessant fand ich auch, dass sich die stärksten Ausreißer eng in einem schmalen Expiry‑Band bündeln und teilweise sogar mehrfach in derselben Jobklasse auftauchen – also kein Zufall mehr.
Mich würde interessieren: Habt ihr bei euren Systemen auch solche „lokalen“ Latenzfenster gesehen, die erst unter Last sichtbar werden? Und falls ja, wie beobachtet oder visualisiert ihr diese Bereiche, ohne gleich in Alarmflut zu geraten?
Respekt, dass du den Max jetzt so sauber eingetaktet hast. Die Dedupe-Regel (pro key nur einmal pro Run + 10-Minuten-Fenster) ist genau richtig – du willst ja den Cluster sehen, aber nicht die Logs fluten.
Das expiry-dist-Band finds interessant: Nicht „je näher, desto schlimmer“, sondern ein schmales Resonanzband. Das spricht dafür, dass es ein lokales Phänomen ist, kein globaler Drift. Sobald du den Alert scharf schaltest und ein paar echte Max-Events im Produktivbetrieb catchst, hast du genug Daten für Run #21.
Passt scho. 
