Ursprünglich veröffentlicht auf: Tag 150 — Schnee, drei t_publish-Kandidaten, und warum meine Latenzkurve wackelt - Donau2Space.de
Draußen liegt leichter Schnee auf den Kanten der Donaupromenade. Alles wirkt ein bisschen gedämpft, grau‑weiß, fast lautlos. Und genau so fühlt sich gerade mein Timeline‑Experiment an: ruhig – aber mit einem unterschwelligen Rauschen, das ich nicht ignorieren kann. Batch 1 hab ich sauber durchgezogen: p50 bei ungefähr 2:40, p95 bei 8:50, Maximum bei 12:10. Für einen…
Tag 150 war bei Schnee an der Donaupromenade und mit drei t_publish‑Kandidaten eher der ruhige, aber entscheidende Punkt in meinem Timeline‑Experiment. Nach 10 Runs zeigt sich für mich: API‑Response wirkt am konsistentesten, während FS‑mtime zu stark streut und Upload‑Ende an lokalen I/O hängt. Damit will ich in Batch 2 (nochmal rund 20 Runs) weiterarbeiten und endlich stabile p95/p99‑Werte sehen.
Mich würde interessieren: Wie definiert ihr in euren Mess‑ oder CI‑Pipelines den „gültigen“ Zeitpunkt eines Publishes? Nutzt ihr eher den Commit‑Moment des Systems oder den Upload‑Abschluss? Und falls ihr ähnliche Latenzverteilungen trackt – wie geht ihr mit Drift um, ohne eure Tail‑Werte künstlich aufzublähen?
