Consider admission control for Guest Agent RPCs
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
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- rust
- Ambito
- backend-api-design, performance
Direzione di ricerca
Non sono indicati file, test o punti di ingresso. Inizia individuando il confine centralizzato del client Guest Agent e verificando come vengono attualmente gestite le chiamate RPC di VMM, le deadlines e le metriche. Definisci la policy di concorrenza e sovraccarico in base alla capacità di deployment e all’uso misurato delle risorse; il lavoro è completato quando esiste un design concordato che copre i limiti globali e per VM, il comportamento in caso di sovraccarico e le metriche.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
VMM proxies several API methods to the Guest Agent over vsock. Request deadlines bound how long each individual call can remain active, but they do not cap the number of calls that can execute concurrently. A burst of requests, or many unresponsive guests, could therefore create a large number of concurrent connection attempts and request tasks until their deadlines expire.
Possible approach
Consider adding admission control at the centralized Guest Agent client boundary, with:
- a global VMM concurrency limit;
- an optional per-VM concurrency limit so one guest cannot consume the full budget;
- explicit overload behavior (fail fast versus bounded queueing);
- metrics for active calls, rejected calls, and timeout rates;
- limits derived from expected deployment size and measured resource use rather than hard-coded without capacity data.
This is intentionally tracked separately from request timeout hardening so the timeout fix remains small and the operational policy can be reviewed independently.
- Lingua principale
- Rust
- Stelle
- 555
- Fork
- 97
- Merge medio
- 1g 3h
- PR unite (30g)
- 199
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun 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 Dstack-TEE/dstack
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
Dstack-TEE/dstack#1384 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
Dstack-TEE/dstack#1301 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
Dstack-TEE/dstack#1300 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Dstack-TEE/dstack#1299 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Dstack-TEE/dstack#1298 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Dstack-TEE/dstack
Issue simili
-
ai_p2
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
ClickHouse/ClickHouse#123351 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
github/copilot-sdk#2804 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
lance-format/lance#9655 ·
I maintainer di solito rispondono entro 2 giorni
-
bug language::rust router
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
Hexagon lifting issuesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
Vector35/binaryninja-api#8621 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni