Performance Tuning — JustAPI Docs

Worker Configuration

Multi-Worker Mode

justapi serve --host 0.0.0.0 --port 8080 --workers 4

Each worker is a separate OS process. Workers share no state — use Redis/Postgres for shared data.

Auto-Scaling Workers

justapi serve --scale --min-workers 2 --max-workers 8 \
  --scale-high 1000 --scale-cooldown 30

Flag	Default	Description
`--workers`	CPU count	Fixed number of workers
`--scale`	off	Enable load-based auto-scaling
`--min-workers`	2	Minimum workers
`--max-workers`	CPU count	Maximum workers
`--scale-low`	100	RPS threshold to scale down
`--scale-high`	1000	RPS threshold to scale up
`--scale-cooldown`	30	Seconds between scaling events

Connection Pool Tuning

app.set_database(
    "postgres://localhost/mydb",
    max_connections=20,               # Pool size
    request_acquire_timeout=1.0,      # Timeout for pool saturation
)

Match pool size to expected concurrency
Set request_acquire_timeout low (1-3s) for fast failure under load
Use connection pooling behind the app for higher concurrency

Body Size Limits

app.run("0.0.0.0:8000", max_body_size=1024 * 1024)  # 1 MiB

Tight limits prevent memory exhaustion under load. Default is 50 MiB.

Request Timeouts

Set timeouts to bound worst-case latency:

justapi serve --timeout 30  # 30 second request timeout

Requests exceeding the timeout return 504 Gateway Timeout.

TLS Overhead

TLS adds approximately 10.7% overhead vs. plain HTTP. For maximum performance:

Terminate TLS at the edge proxy (nginx, Caddy, cloud LB)
Run JustAPI on a private loopback or Unix socket
Pass X-Forwarded-For and X-Forwarded-Proto from the proxy

Compression Trade-offs

Algorithm	Compression Ratio	Speed
None	1.0x	Fastest
gzip (level 1)	~3x	Fast
gzip (level 9)	~5x	Slow
brotli	~4x	Medium
zstd	~5x	Fast

Enable compression only when bandwidth is the bottleneck:

// In Cargo.toml features
justapi-core = { features = ["compression"] }

Route-Lookup Cache

JustAPI automatically caches route lookups for high-traffic paths. No configuration needed — the cache is always active.

Native Fast Path

Maximum throughput comes from the native fast path:

@app.post("/fast", body_schema=Schema, native=True)
def fast_handler(request):
    return {"status": "ok"}  # 724k+ RPS

See Native Fast Path for details.

K8s Overhead

When running in Kubernetes, expect approximately 8.4% throughput degradation due to networking overhead. Mitigate by:

Using host networking mode
Setting resource requests/limits appropriately
Tuning kube-proxy to use iptables mode

Benchmark Methodology

# Warm up: 5 seconds
oha -z 5s http://localhost:8080/hello

# Benchmark: 30 seconds, 100 concurrent connections
oha -z 30s -c 100 http://localhost:8080/hello

# Results: p50, p95, p99 latency, RPS, peak RSS

Run minimum 3 runs per workload to establish distribution.