feat: per-RPC latency tracking integrated into the generated call path
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 12/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- go
- Ambito
- distributed-systems, documentation
Direzione di ricerca
Start with Node.Latency() and the gorums.Latency comparator, which hold the existing node-wide EWMA, and the generated quorum-call and unicast stubs where per-node response timing would be recorded. Then read the NodeResponse, ResponseSeq and Responses types to see where a per-RPC accessor could live. Done means per-RPC estimates update with no call-site changes, unmeasured RPCs return a negative sentinel, existing behaviour is unchanged, and the user guide's Measurement Limits section documents the new accessor. The issue leaves the design open, so settle the API with a maintainer before coding.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Background
Node.Latency() maintains a single exponential moving average per node, shared across all RPC types. This is sufficient for coarse node ranking but, becomes misleading when different RPCs have substantially different server-side processing times — the estimate conflates network latency with compute time and provides no per-operation breakdown.
A user-space workaround (measuring around node.MyRPC() calls and feeding a custom SortBy closure) is impractical because the normal call site is cfg.MyRPC(), not a per-node call. There is no clean hook for users to instrument at the right level without bypassing the configuration abstraction.
Proposed change
Add integrated per-RPC latency tracking at the code-generation layer so that each generated RPC method records its own moving average alongside the existing node-wide average. Concretely:
- Extend Node (or a new NodeStats struct) with a per-RPC latency map, keyed by RPC method name or a generated constant.
- The generated quorum-call and unicast stubs measure elapsed time per node response and update the per-RPC map, using the same EWMA approach as the current node-wide measurement.
- Expose the latency via the
NodeResponsetype, which could be accessed as part of theResponseSeqorResponsestypes. - Another (less attractive) alternative is to expose a Node.LatencyFor(rpc string) time.Duration accessor (or a typed variant via generated code) so that SortBy closures can read per-RPC estimates.
- SortBy(gorums.Latency) continues to use the node-wide estimate; per-RPC ordering requires a user-supplied closure.
Acceptance criteria
- Per-RPC estimates are updated automatically with no changes required at call sites.
- Unmeasured RPCs return a sentinel (negative duration) consistent with the existing node-wide convention, so SortBy closures can handle the cold-start case uniformly.
- The existing Node.Latency() behavior and gorums.Latency comparator are unchanged.
- The user guide "Measurement Limits" section is updated to note that per-RPC tracking is available and link to the relevant accessor.
- Lingua principale
- Go
- Stelle
- 149
- Fork
- 15
- Merge medio
- 1g 1h
- PR unite (30g)
- 51
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di relab/gorums
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
I maintainer di solito rispondono entro 1 giorno
-
cleanup performance
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
sweep: command documentationApertadoc
Difficoltà 3/5 Mezza giornata Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di relab/gorums
Issue simili
-
area/docs framework/hugo help wanted language/markdown
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:other issue-rating: 🦞 diamond lobster no-stale P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
openclaw/crabbox#3060 · 1 commento · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
kubeflow/semantic-operator#52 ·
I maintainer di solito rispondono entro 10 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
PramodBasavarajMenasi/siftwise#52 ·
I maintainer di solito rispondono entro 1 giorno