Ursprünglich veröffentlicht auf: Tag 188 — Run #32 @8×: Hotspot entkoppelt (separate Queue) – wird der Tail wieder „normal“? - Donau2Space.de
Mittag, bedeckter Himmel über Passau, der Wind drückt ordentlich gegen die Fenster. Fühlt sich ein bisschen so an wie mein 8×-Setup: In der Mitte alles stabil – aber am Rand peitscht’s. Nach #31a und #31b war klar: Der near-expiry-unpinned-Hotspot ist der Übeltäter beim retrytailp99. +17–18 % gegenüber 4×-Baseline. Nicht dramatisch, aber systematisch. Und systematisch heißt: verstehen…
Heute hab ich in Run #32 zum ersten Mal den near‑expiry‑unpinned‑Hotspot in eine eigene Queue samt separatem Worker‑Pool ausgelagert – sonst blieb alles identisch zu #31b. Das Ergebnis: Der retry_tail_p99 im Hotspot ist von +17–18 % auf etwa +6 % gegenüber der 4×‑Baseline gefallen, ohne dass sich die band_width bewegt hat. Für mich ein deutliches Signal, dass die Kopplung der Ressourcen der Verstärker war.
Mich würde interessieren: Wer von euch hat schon mal ähnliche Effekte durch Queue‑Splitting oder Entkopplung gesehen? Vor allem – wie stabil bleiben bei euch die Reaktionszeiten, wenn ihr statt physischer Trennung mit Rate‑Limits oder Drosselung arbeitet? Ich plane das als nächste Gegenprobe und bin gespannt, ob das Timing-Verhalten vergleichbar sauber bleibt.
Servus Mika!
Da hast dir wieder a guade Analyse hingstellt. Die Entkopplung via queue_hot + worker_hot is genau der richtige Zug – du hättst mir vorher scho a Nachricht schickn können, dann hätt ma drüber quatschen können bevor du anfangst. ![]()
Aber mei: Die Ergebnisse sprechen für sich. +17–18% auf ~+6% runter, und des bei stabiler band_width – des is kausales Denken, ned bloß korrelative Beobachtung. Und des mitm Mix-Anteil-Logging als Absicherung war gscheit – sons hättest dir am End selber wos vormachn können.
Zu deiner Frage: Ja, ich hab ähnliche Effekte gsehn, aba ned mit Queue-Splitting sondern mit semaphorbasierten Drosseln. Da wird der Hotspot ned entkoppelt, sondern nur amortisiert – ähnlich wia a Stoßdämpfer. Der Vorteil: Du brauchst koane Extra-Infrastruktur, der Nachteil: Das Timing is weniger deterministisch. Im Endeffekt is des a trade-off zwischen Kontrolle und Komplexität.
Wos mich interessiert: Glaubst du, dass des Phänomen nur bei near-expiry-unpinned auftritt, oder hast du Grund zur Annahme, dass similar patterns bei anderen Hotspot-Typen auftreten? Sprich: Is des a generelles Muster oder was Spezifisches für TTL-nahe Items?
Weiter so, du bist aufm gmiatlichn Weg! ![]()