Benchmarks

Performance measurements for Asobi on a single node. All tests run client and server on the same machine (8 cores, shared schedulers), so real-world deployments with separate client machines will see higher server throughput.

Test environment

• CPU: 8 cores
• OTP: 28
• PostgreSQL: 17 (Docker, max_connections=500, shared_buffers=256MB)
• DB pool: 200 connections
• Single Erlang node, no clustering

WebSocket throughput

Heartbeat round-trip: client sends session.heartbeat, server replies with timestamp. Measures the full WebSocket pipeline including JSON encode/decode.

Peak sustained: ~83,000 messages/sec with 3,500 concurrent connections.

At 7,000 connections the per-message throughput drops because the benchmark client competes with the server for CPU on the same machine.

Blast mode

Fire-and-forget: all messages sent before waiting for replies. Measures raw server processing capacity.

All messages delivered with zero loss.

HTTP REST API

100 concurrent players, each running the full lifecycle: register, login, then API reads.

Registration and login are slow by design: pbkdf2 with 100,000 iterations is CPU-intensive but correct for password security. API reads are sub-15ms p50.

Game type suitability

Mobile / casual (turn-based, party, puzzle)

Excellent fit. Sub-10ms WebSocket RTT, 3,000+ CCU per node. Most mobile games need <100 messages/sec per player, so a single node handles thousands of concurrent players comfortably.

MMO (persistent world)

Viable for zone servers. 3,000-7,000 concurrent connections per node with good latency. A 20,000 CCU MMO would need 5-10 nodes. Erlang's pg-based clustering is designed for this.

Competitive real-time (FPS, fighting, racing)

Not the target. WebSocket (TCP) has a 5-25ms RTT floor. These genres need UDP transport with <3ms latency. Consider Photon or a custom UDP relay alongside Asobi for the game state, using Asobi for everything else (auth, matchmaking, economy, social, leaderboards).

Bottlenecks and tuning

Authentication under load

pbkdf2 saturates CPU during login storms (1,000+ simultaneous registrations). Mitigations:

• Reverse proxy rate limiting on /auth/* endpoints
• Auth result caching for repeated token validations
• Multiple nodes behind a load balancer to spread pbkdf2 work

Database pool

The default pool size matters. With 10 connections, 100+ concurrent DB operations queue up. Recommended:

Memory

WebSocket connections use ~13-20KB each. A node with 8GB RAM can sustain ~100,000 connections from memory alone. The practical limit is CPU (message processing) not memory.

Running benchmarks

# HTTP load test (default 100 players)
ASOBI_LOAD_N=500 rebar3 ct --suite=asobi_load_bench

# WebSocket benchmark
# Phase 1: Register players (cached after first run)
# Phase 2: Connect and blast heartbeats
ASOBI_BENCH_PLAYERS=5000 \
ASOBI_WS_N=5000 \
ASOBI_WS_MSGS=2000 \
ASOBI_WS_WAVE=200 \
rebar3 ct --suite=asobi_ws_bench

Environment variables: