Disk polling: measure owner completion service under concurrent polling
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- rust
- Ambito
- distributed-systems, performance
Direzione di ricerca
Inizia con la configurazione condivisa del benchmark e i criteri di valutazione in #4174, quindi leggi core/shard/src/router.rs, core/shard/src/poll/completion.rs e core/configs/src/server_config/sharding.rs. Riutilizza la cattura dello stage padre ed esegui un breve ramp-up di letture concorrenti, se giustificato. Il lavoro è completato quando sono state registrate le misure richieste relative a carico, ammissione, coda, memoria, avanzamento delle scritture e latenza, con qualsiasi confronto tra policy allineato alle guardrails.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Part of #4174, which records the shared benchmark setup and evaluation criteria.
Measure whether admission or owner service limits disk polling under concurrent load. The owner pump services one completion after ordinary work and also has a completion select arm. Capacity is reserved before I/O and held until dequeue or discard.
The limit counts running reads plus queued completions, including reads continuing after requester timeout. It bounds operations, not retained bytes or time spent waiting behind owner work.
An earlier diagnostic used base 0d862e36dcc42fd1fffca2f4504886718bf7757f plus an instrumented port of the archived lane, rather than the current implementation. At capacity 1024:
| Observation | Without writes | With writes |
|---|---|---|
| Maximum ordinary inbox occupancy sampled at pump starts | 1 | 2 |
| Maximum candidate reservation occupancy | 1 | 1 |
| Maximum candidate completion queue occupancy | 1 | 1 |
| Rejected candidate reservations | 0 | 0 |
This separate diagnostic comprised eight captures of 10,000 explicit offset polls, using the shared sequential consumer workload described in #4174. Its report and captures remain archived locally. Pump samples can miss brief peaks; these observations establish neither saturation nor a benefit from greater capacity. Instrumented timings are not a clean performance comparison.
- Reuse the parent's stage capture. If owner service appears material or a representative concurrency requirement warrants it, run a short ramp with several simultaneous reads and ordinary work.
- Record offered and completed load, active reads, reserved capacity, queue occupancy, admission rejections, retained bytes, write progress and tick delay.
- Separate enqueue to owner acceptance from acceptance to caller resumption. Correlate waits with actual owner work and service intervals, sharing timestamps with #4178.
- If a specific boundary explains material delay, compare one bounded policy change at matched load. Use completion latency, achieved write throughput and tick latency as guardrails.
Preserve bounded admission, reservation release and history validation on the owner. Larger drains can delay consensus, other replies or shutdown; greater capacity can admit more detached I/O and retain more data. Use the parent's arrival model guidance so a slowing sequential client does not conceal the pressure being studied.
- Lingua principale
- Rust
- Stelle
- 5.2k
- Fork
- 502
- Merge medio
- 3g 11h
- PR unite (30g)
- 143
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
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 apache/iggy
-
go good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
HTTP client treats a consumer group as a plain consumerForse già presa @mohitduhan19 l’ha presa 18 giorni fa. Apertabug rust server
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
apache/iggy#4408 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Add the fail-fast connection option to the Rust and Python quick-startsForse già presa @QIW9 l’ha presa 6 giorni fa. Apertadocs good first issue
Difficoltà 1/5 1-3 ore Idoneità per principianti 92/100
apache/iggy#4261 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug python sdk
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
apache/iggy#3748 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Python examples: add a sink data producerForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertagood first issue python
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
example
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
rust-lang-nursery/rust-cookbook#954 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 70/100
OpenZeppelin/openzeppelin-relayer#967 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
DecisionOutcome::label() / n_dosed(): engine-side mapping so downstream needs no wildcard armAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
src/runs.rs:1987: a missing --source-run-id now answers 400 "Source run ... does not exist", not 404Apertanightly-audit
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
antithesishq/snouty#602 ·
I maintainer di solito rispondono entro 1 giorno