# CubeSandbox Performance Benchmarks for Concurrent Sandbox Creation at Scale

> Discover CubeSandbox performance benchmarks for concurrent sandbox creation at scale. Achieve 181 sandboxes/sec and 5.5 ms latency with optimal concurrency.

- Repository: [Tencent Cloud/CubeSandbox](https://github.com/TencentCloud/CubeSandbox)
- Tags: performance
- Published: 2026-07-12

---

**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`](https://github.com/TencentCloud/CubeSandbox/blob/main/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`](https://github.com/TencentCloud/CubeSandbox/blob/main/sdk/go/client.go) and [`sdk/go/sandbox.go`](https://github.com/TencentCloud/CubeSandbox/blob/main/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:

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

```

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

```bash
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:

```bash

# 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:

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

```

Generate machine-readable JSON reports for further analysis:

```bash
./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`](https://github.com/TencentCloud/CubeSandbox/blob/main/examples/cube-bench/benchmark.go) and the Go SDK in [`sdk/go/client.go`](https://github.com/TencentCloud/CubeSandbox/blob/main/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`](https://github.com/TencentCloud/CubeSandbox/blob/main/examples/cube-bench/benchmark.go), with usage documentation in [`examples/cube-bench/README.md`](https://github.com/TencentCloud/CubeSandbox/blob/main/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`](https://github.com/TencentCloud/CubeSandbox/blob/main/sdk/go/client.go) and [`sdk/go/sandbox.go`](https://github.com/TencentCloud/CubeSandbox/blob/main/sdk/go/sandbox.go). Detailed methodology and results are published in [`docs/blog/posts/2026-06-01-cubesandbox-perf-benchmark.md`](https://github.com/TencentCloud/CubeSandbox/blob/main/docs/blog/posts/2026-06-01-cubesandbox-perf-benchmark.md).