Tune parallel chunk concurrency live

For chunked uploads (and direct-to-S3 / Azure), chunkConcurrency controls how many parts stream at once. Higher values fill the pipe; lower values are kinder to shared infrastructure. Adjust the slider between uploads and watch the effect on throughput.

Live demo. Running against the site's built-in chunked endpoint. Small chunk size (512 KB) so the worker pool is visible on modest files.

Chunk concurrency: 4

Applies on the next upload. Range 1-8; tune for your bucket's 5xx rate in production.

Configuration

new MultipleUpload('#uploader', {
 uploadUrl: '/api/upload',
 chunked: true,
 chunkSize: 5 * 1024 * 1024,
 chunkConcurrency: 4 // default 1; tune to taste
});

How parallel chunks work

The file is sliced into N chunks (totalChunks = ceil(size / chunkSize)).
A worker pool (size = chunkConcurrency) pulls chunks off the queue and uploads them independently.
Per-chunk progress feeds into a shared chunkBytes map; displayed progress is the sum across all chunks.
Each chunk has its own retry budget with exponential backoff; a failed chunk retries without stalling the others.
On completion, the server assembles chunks (for chunked) or the client commits the block/part list (for s3 / azure).

Works for every multipart strategy

The same chunkConcurrency option applies to chunked, s3, and azure strategies. tus is protocol-sequential (one PATCH at a time) and ignores the setting.

Observable tradeoffs

1 - strictly sequential. Slowest, kindest to throttled servers.
4 - sensible default for most home-broadband connections.
8+ - best on fibre links, but watch for rate-limit 429s, bucket throughput caps, and the server's ability to coalesce multiple PUTs.