A store allocates about 10 MiB up front, however small the upload

Aperta
  • Qualcosa non va?
#48 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend, performance

Direzione di ricerca

Start with collect() in src/streams.ts and uploadBlob() in src/store.ts, then trace their callers and the existing size limits. The issue proposes growing both buffers as data arrives, up to those limits; check how the current tests cover small and maximum-sized uploads. Done means uploads retain the stated limits while buffers no longer allocate their full capacity for small inputs.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What happens. Every store allocates its buffers at their limits, whatever the upload's size:

  • collect() in src/streams.ts does new Uint8Array(limit) for the metadata part, so 5 MiB with the default limits;
  • uploadBlob() in src/store.ts allocates a 5 MiB part buffer before reading the blob, and a small blob ends up as one put of a slice of it.

So each store in flight holds about 10 MiB however small it is, and Admission has to cap stores at 2 per isolate to stay inside 128 MiB. When several tasks finish at once, the 503 concurrency_limit refusals that follow aren't retried by the client, so those entries are lost.

What our entries weigh. From one deployment's generations table, 1,897 ready rows (Vite+ 1.5.0, a monorepo's build, lint and test tasks):

Average Under 64 KiB Over 1 MiB Largest
value 669 KB 129 268 3.99 MB
blob 141 KB 1,754 74 13.1 MB

Most blobs are far under one part. The values average about 0.7 MB, against the 5 MiB buffer each one gets.

Suggested fix. Grow both buffers as bytes arrive, up to their limits, rather than allocating the limit up front. For the part buffer, start small and grow to PART_SIZE only when a blob gets that far. Memory then follows what's actually in flight, and the admission caps could rise a lot, leaving the rate limit to bound traffic.

Also worth a look: some values are close to the 4 MiB value limit (largest 3.99 MB), and those are task logs. A task with a slightly longer log would be refused as too large, and that's silent on the client side too.

We run a vendored copy at 5b06c2c with the caps raised to 6 stores and 8 reads. We're making the buffer change in our copy and can send it as a PR if that's welcome.

Lingua principale
TypeScript
Stelle
8
Fork
0
Merge medio
2g 10h
PR unite (30g)
40

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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di voidzero-dev/vite-plus-remote-cache-cloudflare

Tutte le issue di voidzero-dev/vite-plus-remote-cache-cloudflare

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.