Repository navigation
perf(upload): default --concurrency to 256 - #54
Merged
Merged
Conversation
The one-shot upload pool has defaulted to 8 sessions since the first upload code. The throughput work since then (latency-aware cap, pool and buffer sweeps) ran through the daemon's --pool-size 256 and an explicit --concurrency in bench-direct, so a plain `hoverfly upload` never got it. Each chunk is routed through the closest session, so 8 sessions send most chunks through far-away peers. The ENS portal release job runs with no flags: 8.9 MB in 210 s, pool=8 throughout, 53% of pushes answered shallow, and 22 chunks accepted shallow-only after 59 retries. Small uploads are unaffected: push_chunks_concurrent still opens max(4 per chunk, 16) sessions, capped by this value. The browser passes its own UPLOAD_POOL (48) and never read this constant.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
hoverfly uploadhas defaulted to an 8-session pool since the first upload implementation. Every throughput improvement since then was measured with 128–256 sessions: the daemon's--pool-size 256, andbench-directpassing--concurrency 128. A plainhoverfly uploadwith no flags never benefited from that work.This changes
DEFAULT_UPLOAD_CONCURRENCYfrom 8 to 256, the same value as the daemon's--pool-size.Why 8 is too small
Each chunk is pushed through the closest session in the pool. With only 8 sessions, most chunks go through peers that are far from their address.
The ENS portal release job runs
hoverfly upload portal.tarwith no flags (run):pool=8 (at inflight cap=8)).For comparison, a random 20 MiB file is 5563 chunks, about the same as the portal. The benchmarks push that in roughly 9–48 s.
Effect on small uploads and the browser
push_chunks_concurrentstill sizes the pool asmax(4 × chunks, 16), capped by--concurrency. A 3-chunk file opens 16 sessions, not 256.UPLOAD_POOL(48) to every upload call and never read this constant. Browser uploads don't change.upload_collectionwith the request'sconcurrency, so they also move from 8 to 256.