Benchmark runbook

​

Rules

• Publish only rows with a date and a hardware label. Anything unmeasured stays marked not yet measured.
• Rows with client_saturated above zero are invalid. Rerun with a bigger load generator.
• Never mix laptop and server numbers in one table. Say what each row ran on.
• Keep the raw JSON in docs/benchmark-results/ next to the table.

​

Provision by hand

• Server: one Linux VPS, a size you will name in the row (for example 4 vCPU, 8 GB). Install Levelrail with install.sh, then deploy the fixture app with 2 replicas behind the load balancer with a domain.
• Load generator: a second VPS in the same region and network segment, never the server itself. 4 vCPU or more.
• For a node drain row, add a second node to the server’s placement (see Add a node).
• Build the fixture on the server: docker build -t bench-app test/fixtures/bench-app.
• Make a note of the network between the two machines (region, private or public).
• Create an API token on the server for the load generator.
• Destroy both machines when done; billing is on you.

​

Run

export BENCH_HOST=203.0.113.10 BENCH_USER=root
export BENCH_INSTALL_URL=https://levelrail.example.com
export BENCH_TOKEN=...
export BENCH_APP_URL=https://bench.example.com/
export BENCH_REPLICA_URL=http://REPLICA_IP:8080/
scripts/bench/run-vps.sh --dry-run
scripts/bench/run-vps.sh

​

Scenarios

​

Publish

• The script writes docs/benchmark-results/<date>-vps-*.json and <date>-vps-fragment.md. The hardware line comes from lscpu, free, uname and docker version on the server.
• Check the fragment: saturated is 0, hardware line is complete, date is today.
• Paste the fragment under “Results” in docs/benchmarks.md and update the matching rows in the scenario status table. Rows you did not run keep their not yet measured status.
• Add the load generator size and network note to the paragraph above the table.