CubeSandbox Performance Benchmarks for Concurrent Sandbox Creation at Scale

CubeSandbox achieves a peak throughput of approximately 181 sandboxes per second at 20 concurrent workers on a 96-core bare-metal node, with per-sandbox amortized latency dropping to 5.5 ms under optimal concurrency.

The TencentCloud/CubeSandbox project provides rigorous performance benchmarks for concurrent sandbox creation at scale, demonstrating how the platform handles high-volume parallel workloads using a dedicated Go benchmark tool. These measurements reveal the system's behavior under stress, from single-threaded cold starts to 50-way concurrent sandbox provisioning, with all tests maintaining a 100% success rate. Understanding these metrics helps operators provision infrastructure appropriately and tune concurrency levels for their specific hardware.

Benchmark Methodology and Hardware Configuration

Test Environment and Infrastructure

All official performance benchmarks for concurrent sandbox creation at scale execute on a Tencent Cloud BMI5 bare-metal node equipped with 96 logical cores, 375 GiB RAM, and XFS-backed storage. The test template specifies a 2 vCPU / 2 GiB sandbox configuration, utilizing the image cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest. This standardized environment ensures reproducible results across different test runs and hardware comparisons.

Benchmark Tool and Measurement Criteria

The project ships a dedicated CLI tool located in examples/cube-bench that implements the core measurement logic in examples/cube-bench/benchmark.go. This tool coordinates concurrent workers to bombard the CubeAPI with sandbox creation requests while capturing detailed latency percentiles. The methodology distinguishes between wall-time latency (total duration per request) and amortized latency (total wall-time divided by the number of requests), revealing how pipelining affects per-sandbox overhead.

Performance Benchmarks for Concurrent Sandbox Creation at Scale

The following table summarizes the create-sandbox operation results across four concurrency tiers:

Concurrency (workers)	Total requests	Avg latency (ms)	Min (ms)	P95 (ms)	Max (ms)	Per-sandbox amortized (ms)	Throughput (sandboxes/s)
1	20	47.8	43.5	57.4	60.4	55.8	17.9
10	200	88.7	45.8	116.9	119.1	9.9	101.4
20	300	98.1	47.7	175.8	232.6	5.5	180.9
50	500	276.1	60.6	508.4	681.3	6.8	147.6

Key observations from the data:

• Cold-start latency remains consistently sub-100 ms for a single worker, averaging approximately 48 ms
• Concurrency scaling delivers dramatic efficiency gains: moving from 1 to 20 workers reduces per-sandbox amortized latency from ~56 ms to ~5.5 ms—a roughly 10× improvement
• 100% success rate across all concurrency tiers demonstrates system stability under load

Analyzing Throughput and Latency Trade-offs

Peak Throughput at 20 Concurrent Workers

The optimal performance benchmarks for concurrent sandbox creation at scale occur at 20 concurrent workers, achieving approximately 181 sandboxes per second throughput. At this concurrency level, the system maximizes CPU utilization and I/O parallelism without excessive queueing overhead. The amortized latency of 5.5 ms represents the most efficient point where the cost of coordination remains lower than the gains from parallelization.

Diminishing Returns Beyond 20 Workers

Increasing concurrency to 50 workers produces diminishing returns on this hardware configuration. While throughput drops slightly to ~148 sandboxes/s, tail latency degrades significantly—the P95 latency spikes to 508 ms compared to 176 ms at 20 workers. This queueing overhead indicates the system has reached its saturation point, where additional parallelism introduces scheduling delays rather than productive work.

Cold-Start vs. Amortized Latency

Cold-start latency (single-worker performance) measures the baseline time to spin up a sandbox from a template without resource contention, averaging 47.8 ms. Amortized latency reveals the true cost per sandbox when the system operates at full pipeline efficiency. The divergence between these metrics—55.8 ms amortized at 1 worker versus 5.5 ms at 20 workers—demonstrates CubeSandbox's ability to batch and parallelize sandbox creation operations through the sdk/go/client.go and sdk/go/sandbox.go SDK implementations.

Reproducing the Benchmarks Locally

You can reproduce these performance benchmarks for concurrent sandbox creation at scale using the provided CLI tool. First, build the binary from the source:

cd examples/cube-bench
make                # produces ./bin/cube-bench

Configure the required environment variables to point to your CubeAPI instance:

export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000               # any non-empty string for local deploys

export CUBE_TEMPLATE_ID=<your-template-id> # from `cubemastercli tpl list`

Execute a create-only benchmark (keeping sandboxes alive) at your chosen concurrency level:

# Example: 20 concurrent workers, 300 total requests

./bin/cube-bench -c 20 -n 300 -w 3 -m create-only

The flag parameters control:

• -c: Concurrency (number of workers)
• -n: Total iterations (requests)
• -w: Warm-up rounds (discarded from results)
• -m: Mode (create-only to skip deletion, or create-delete for full lifecycle)

For a dry-run simulation without requiring a running server:

./bin/cube-bench --dry-run -c 50 -n 500 -m create-only

Generate machine-readable JSON reports for further analysis:

./bin/cube-bench -c 20 -n 300 -w 3 -m create-only -o report_c20.json

Summary

• Peak performance occurs at 20 concurrent workers, delivering ~181 sandboxes per second with 5.5 ms amortized latency per sandbox
• Hardware requirements significantly impact results; the documented benchmarks use a 96-core bare-metal node with XFS storage
• Source locations include the benchmark logic in examples/cube-bench/benchmark.go and the Go SDK in sdk/go/client.go
• Concurrency limits show diminishing returns beyond 20 workers due to queueing overhead and increased tail latency
• 100% success rate across all tested concurrency levels indicates production-ready stability for high-volume workloads

Frequently Asked Questions

What is the maximum throughput CubeSandbox can achieve?

According to the TencentCloud/CubeSandbox performance benchmarks for concurrent sandbox creation at scale, the maximum throughput observed is approximately 181 sandboxes per second when running 20 concurrent workers on a 96-core bare-metal node. Higher concurrency levels (such as 50 workers) actually reduce throughput to ~148 sandboxes per second due to queueing overhead and resource contention.

How does latency change as concurrency increases?

Cold-start latency remains stable at approximately 48 ms for single-worker operations, but amortized latency decreases dramatically as concurrency increases from 1 to 20 workers—dropping from 55.8 ms to 5.5 ms. However, beyond 20 workers, tail latency degrades significantly, with P95 latency reaching 508 ms at 50 workers compared to 176 ms at 20 workers.

What hardware is required to reproduce these benchmarks?

The official benchmarks utilize a Tencent Cloud BMI5 bare-metal instance with 96 logical cores, 375 GiB RAM, and XFS-backed storage. While the examples/cube-bench tool can run on any compatible hardware, performance metrics will vary based on CPU core count, memory bandwidth, and storage I/O capacity. Alternative hardware configurations, such as PVM Cloud Servers, are documented in the repository's separate PVM benchmark report.

Where can I find the benchmark source code?

The complete benchmark implementation resides in examples/cube-bench/benchmark.go, with usage documentation in examples/cube-bench/README.md. The underlying Go SDK that interfaces with CubeAPI—utilizing the Create and Kill methods—is located in sdk/go/client.go and sdk/go/sandbox.go. Detailed methodology and results are published in docs/blog/posts/2026-06-01-cubesandbox-perf-benchmark.md.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}