Skip to content

feat(orchestrator): Scale Volume ReadDir Concurrency with Directory Size - #3817

Open
Merlin0220 wants to merge 4 commits into
e2b-dev:mainfrom
Merlin0220:feature/entryinfo-concurrent-calls
Open

Merlin0220 wants to merge 4 commits into
e2b-dev:mainfrom
Merlin0220:feature/entryinfo-concurrent-calls

Conversation

@Merlin0220

Copy link
Copy Markdown

Summary

Optimize large volume directory listings by fetching per-entry metadata concurrently, with concurrency scaled by the number of entries and bounded by a configurable limit.

This targets network storage such as NFS, where serial metadata lookups can accumulate significant latency. Small directories continue to use serial lookups to avoid concurrency overhead.

Changes

Adaptive concurrency

Introduce ReadDirScaling to determine concurrency for each directory listing. By default:

  • Fewer than 5,000 entries: process metadata lookups serially.
  • At 5,000 entries: start with 4 concurrent lookups.
  • Add 1 concurrent lookup for every additional 10,000 entries.
  • Cap concurrency at 16.

Use errgroup.SetLimit to bound concurrent metadata lookups.

Configurable scaling

Add Orchestrator configuration and pass it through Builder to each Chrooted filesystem instance.

Environment variable | Default | Description -- | -- | -- VOLUME_READ_DIR_CONCURRENCY_THRESHOLD | 5000 | Entry count at which concurrent lookups begin VOLUME_READ_DIR_CONCURRENCY_BASE | 4 | Initial concurrency at the threshold VOLUME_READ_DIR_CONCURRENCY_STEP | 10000 | Additional entries required to increase concurrency by one VOLUME_READ_DIR_CONCURRENCY_MAX | 16 | Maximum concurrency per listing

Reject invalid configuration during parsing: the threshold must be nonnegative, the base and step must be positive, and the maximum must be at least the base.

Preserve listing behavior

Write metadata results into their corresponding sorted entry positions, preserving name-sorted output regardless of lookup completion order.

Existing behavior is preserved:

  • Return metadata for symbolic links themselves.
  • Skip entries removed during the listing.
  • Return other metadata lookup errors to the caller.
  • Wait for all concurrent lookups before releasing directory resources.

Tests

Add unit tests covering:

  • Configuration defaults, environment overrides, and invalid values.
  • Concurrency thresholds, scaling steps, and upper limits.
  • Zero-value and degenerate scaling parameters.
  • Consistent directory contents and ordering between serial and concurrent execution.

Tests and performance benchmarks were not run while preparing this description.

Merlin0220 and others added 2 commits November 11, 2026 19:11
…dDir

Per-entry stats in ReadDir were serial, making every directory listing
cost one storage round trip per entry. Run them on a bounded errgroup
instead, with the parallelism configurable through
VOLUME_READ_DIR_CONCURRENCY (default 8).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ount

A fixed worker pool paid goroutine churn on small listings and capped
large ones too early. The parallelism of the per-entry stats is now a
function of the listed directory's size: serial below
VOLUME_READ_DIR_CONCURRENCY_THRESHOLD, then
VOLUME_READ_DIR_CONCURRENCY_BASE workers plus one more per
VOLUME_READ_DIR_CONCURRENCY_STEP additional entries, capped at
VOLUME_READ_DIR_CONCURRENCY_MAX (5000/4/10000/16 by default). These
replace the unreleased VOLUME_READ_DIR_CONCURRENCY knob.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Merlin0220 and others added 2 commits November 12, 2026 15:24
…5000/16

A 5000-entry threshold left the worst serial listing at 5000 storage
round trips (~1.5s of in-region NFS RTT) to save microseconds of
goroutine scheduling; 1000 keeps that below ~300ms. Base 8 takes the
cheap serial-to-parallel win, and a 5000-entry step tracks realistic
per-directory sizes (1k-50k) instead of reaching the 16 cap only at
125000 entries. The cap stays 16: past it the per-worker latency gain
is marginal while per-listing outstanding requests, which multiply
across concurrent listings of one volume, keep growing.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant