CONCEPT Cited by 1 source

Lambda fan-out benchmark

Definition

A Lambda fan-out benchmark uses AWS Lambda's horizontal-concurrency scaling as the load generator for a downstream system. Many Lambda function invocations run in parallel; each establishes some number of concurrent connections / requests against the target; the aggregate concurrency is the product of the two dimensions. The benchmark measures how quickly — and how stably — the target accepts the aggregate load.

The shape is natural on Lambda because:

• Lambda scales horizontally on demand (no harness node provisioning).
• Each Lambda container is process-isolated (per-connection state doesn't cross workers).
• Billing is per-invocation-duration (a 5-minute benchmark at 1,000 workers is cheap).

The shape is constrained by two Lambda runtime defaults that cap per-worker and total concurrency:

Constraint	Default	Where it binds
open_files per container	1024	max per-worker concurrent connections
function_concurrency per fn	1000	max simultaneously-running workers

Both are soft defaults (the second is raisable via AWS account-level limit-increase), but benchmarks designed to stay within defaults make the test reproducible by any observer without AWS-support-ticket involvement.

Canonical benchmark: PlanetScale's 1M-connections test

Liz van Dijk (PlanetScale, 2022-11-01) uses this pattern to benchmark PlanetScale's concurrent-connection ceiling:

"by default, the Lambda runtime environment has a hard open_files limit of 1024 and a function concurrency limit of 1000. As such, we configured our test to run a total of exactly 1000 'worker functions', each of which established exactly 1000 connections, so we could stay within the Lambda runtime limits." (Source: sources/2026-04-21-planetscale-one-million-connections.)

Fan-out geometry: 1,000 workers × 1,000 connections/worker = 1,000,000 concurrent connections, staying within the per-container and per-function-concurrency defaults by a 1-connection safety margin on open_files.

Per-worker loop:

1. Open a MySQL connection using go-sql-driver/mysql.
2. Send one simple query to validate the connection works.
3. Wait on a barrier for the other ~999 workers to finish establishing their 1,000-connection slice.
4. Hold all connections open for a few minutes at the 1M-concurrent plateau.
5. Close connections.

Aggregate ramp-to-plateau: under 2 minutes. Plateau duration: ~5 minutes before drain.

Properties of the methodology

What it measures well

• Connection-establishment scaling — the fan-out geometry stresses the acceptance pipeline directly.
• Sustained connection-count plateau — workers are parked during the hold phase, so the target sees a stable population of open sessions.
• Cold-start-from-zero scaling — Lambda workers don't pre-warm (unless Provisioned Concurrency is enabled); the benchmark naturally tests the target's cold-ramp behaviour.

What it doesn't measure

• Sustained query throughput under the plateau — the per-worker loop sends a single handshake-probe query. A "1M concurrent connections" benchmark does not imply "1M QPS." See caveats on sources/2026-04-21-planetscale-one-million-connections.
• Tail latency under load — the single-probe-per-worker design gives one data point per connection.
• Per-connection CPU/memory footprint at target — Lambda workers don't report target-side resource usage.

What bakes in noise

• Lambda cold-start distribution — workers don't spin up in the same millisecond; the 2-minute ramp is likely dominated by Lambda's own scale-up behaviour, not by the target's acceptance rate.
• Lambda runtime initialisation overhead per invocation (~50-200 ms) adds to per-worker setup latency before the first connection even opens.
• Regional Lambda placement — workers may be distributed across AZs, adding variable RTT to the target.

Generalisation

The benchmark shape is not MySQL-specific. Any target that accepts many concurrent clients — an HTTP service, a Redis cluster, a WebSocket fleet — can be load-tested with the same workers × clients-per-worker fan-out geometry. Key design points:

• Choose clients-per-worker ≤ open_files default (1024).
• Choose workers ≤ function_concurrency default (1000) unless you control the AWS account.
• Use a rendezvous barrier (SQS / SNS / SSM parameter store / DynamoDB atomic-counter / shared S3 object) so the aggregate plateau is reached before any worker starts its hold timer.
• Instrument target-side metrics (the benchmark harness sees only the aggregate; the target sees the distribution).
• Keep per-worker logic minimal so the measurement is about the target, not the harness.

Seen in

• sources/2026-04-21-planetscale-one-million-connections — canonical wiki disclosure of the 1,000 × 1,000 fan-out harness as the measurement rig behind the "1M concurrent connections" claim on PlanetScale; explicit design choice to stay within Lambda runtime-default limits to make the benchmark reproducible.

Related

• systems/aws-lambda — the benchmark harness; runtime defaults are load-bearing design parameters.
• patterns/custom-benchmarking-harness — the general pattern of building a purpose-specific load generator rather than using a generic tool (sysbench, jmeter).
• concepts/max-connections-ceiling — the target-side constraint this benchmark pressure-tests.
• concepts/serverless-tcp-socket-restriction — companion Lambda constraint: Lambda can open MySQL TCP sockets for a benchmark (it's server-side Lambda), but production serverless frontend runtimes (Vercel Edge, Cloudflare Workers, Netlify Edge) cannot; hence the HTTP-API path the 1M benchmark motivates.