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

Đang mở
  • Có gì không ổn?
#48 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
backend, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
8
Fork
0
Merge trung bình
2 ngày 10 giờ
Pull request đã merge (30 ngày)
40

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của voidzero-dev/vite-plus-remote-cache-cloudflare

Tất cả issue của voidzero-dev/vite-plus-remote-cache-cloudflare

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.