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

Aberta
  • Algo errado?
#48 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 2 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
backend, performance

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
8
Forks
0
Merge médio
2d 10h
PRs com merge (30d)
40

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de voidzero-dev/vite-plus-remote-cache-cloudflare

Todas as issues de voidzero-dev/vite-plus-remote-cache-cloudflare

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.