Deployment

中文版：deployment_CN.md

The deployment model for rust-bench, derived from the build and runtime artifacts in the repository. For step-by-step runbooks see the deploying-site guide and deploying-collector guide.

Components to deploy

Component	Where	Backend	Source
Site (web server + job-queue tick + platform API)	Docker image or bare process	Postgres	Dockerfile, site/src/main.rs
Collector(s) (benchmark executor)	bare-metal benchmark machine, collect-job-queue.sh loop	Postgres	collector/collect-job-queue.sh, collector/src/bin/collector.rs
Database	Postgres 16	—	docker-compose.yml (test instance)

SQLite is supported only for local single-machine runs (bench_runtime_local); the distributed queue requires Postgres.

Site

The Site binary is target/release/site. It serves HTTP on port 2346 (PORT) and the webhook endpoint at /perf/webhook (site/src/server.rs:343).

Docker

The Dockerfile is a multi-stage build (frontend → site binary → minimal runtime image):

node:18 (build frontend)  →  ubuntu:20.04 base (Rust + cargo-chef)  →  build  →  ubuntu:20.04 binary

• Stage 1 builds the TypeScript frontend (site/frontend) with npm ci && npm run build.
• Stage 2 installs build deps and Rust (stable) via rustup, using USTC/TUNA mirrors (set for China network).
• Stage 3 uses cargo-chef to cache dependencies, then builds site and postgres-to-sqlite.
• Final image copies site and postgres-to-sqlite binaries; CMD ./rustc-perf-site.

Run with:

docker build -t rust-bench-site .
docker run -p 2346:2346 -e DATABASE_URL=postgres://... -v $(pwd)/site-config.toml:/app/site-config.toml rust-bench-site

Postgres for testing

docker-compose.yml provides a throwaway Postgres 16:

docker compose up      # starts pg_test on :5432 (user=postgres, pass=testpass, db=postgres)

Environment

Env	Default	Purpose	Source
DATABASE_URL	results.db	DB connection URL.	main.rs:24-30
PORT	2346	HTTP port.	main.rs:31-34
QUEUE_UPDATE_INTERVAL_SECONDS	30	Job-queue tick interval.	main.rs:35-38
SELF_PROFILE_STORAGE_S3	unset	If set, self-profile from S3; else local.	main.rs:39-49

Plus the platform env vars when site-config.toml is absent (see configuration.md §7).

Startup flow

On start (site/src/main.rs:16), the Site:

1. Loads site-config.toml (or env), validates [keys] (degraded mode if absent, hard-fail if empty) — load.rs:299-349, 478-496.
2. Connects to the DB and loads the index (artifacts, commits, metrics).
3. Creates one PlatformApi client per configured repo key.
4. Starts the HTTP server and the job-queue tick task (panic-bounded: if the tick panics it restarts).
5. Seeds benchmark_request rows for the last 30 days of merge commits per repo (seed_master_commits, load.rs:541-613).

Collectors

Each collector runs on a dedicated benchmark machine via collector/collect-job-queue.sh (not Docker — it needs direct hardware access and perf_event).

The run loop

collector/collect-job-queue.sh (37 lines) expects DATABASE and COLLECTOR_NAME env vars and loops forever:

1. git pull && git reset --hard @{upstream} — update rust-bench itself.
2. rustup update stable then cargo +stable build --release -p collector --features s3-sdk.
3. target/release/collector benchmark_job_queue --db $DATABASE --check_git_sha --git_sha $(git rev-parse HEAD) --collector_name $COLLECTOR_NAME.
4. On non-zero exit: sleep 60 then retry; on success: immediately loop.

Registration

Before first run, register the collector name in Postgres (see job-queue.md):

./target/release/collector add_collector --db "postgres://..." --collector_name "Kunpeng 920B" --is_active

The collector_name must match an entry in [collectors].tags in site-config.toml.

Machine preparation

Benchmark fidelity requires a quiet machine. Required settings (per benchlib/src/measure/perf_counter/linux.rs:84-100 and the README checklist):

Item	Setting	Why
perf_event_paranoid	sudo bash -c 'echo -1 > /proc/sys/kernel/perf_event_paranoid'	Allows userspace perf_event_open for HW counters. The library errors with this hint on failure.
CPU frequency	Pin to a fixed frequency (disable dynamic scaling)	Reduces wall-time noise.
ASLR	sudo bash -c 'echo 0 > /proc/sys/kernel/randomize_va_space'	Optional; the collector also disables ASLR per-process via setarch -R (runtime/mod.rs:215).
Turbo / SMT	Disable	Reduces run-to-run variance.

Collector tag examples (multi-architecture)

The repo's site-config.toml ships with two collector tags representing two architectures:

[collectors]
tags = ["Kunpeng 920B", "AMD EPYC 9654"]

• Kunpeng 920B — an ARM (aarch64) server.
• AMD EPYC 9654 — an x86_64 server.

Deploy one collect-job-queue.sh loop per machine, each with its own COLLECTOR_NAME. The Site will fan out one job per (benchmark_group, collector_tag), so both architectures are benchmarked in parallel and the comparison comment includes per-tag links plus cross-machine (<tag_i> vs <tag_j>) links (site/src/github/comparison_summary.rs:26-134).

The actual hardware specifications (CPU model, RAM, kernel) are operator-specific and not encoded in the repository. Document your machine's specifics in an internal runbook; the framework only requires the four machine-preparation settings above and a matching COLLECTOR_NAME.

Operational notes

• Stopped collector halts the queue. Collector tags are statically assigned — there is no work-stealing. If a collector with an in-progress job stops, the whole system waits until that job is retried/completed. See job-queue.md.
• Status page. Collector heartbeats (collector_config.last_heartbeat_at) are visible on the status page; a heartbeat older than ~1 h means the collector is likely down.
• Self-profile storage. Build the collector with --features s3-sdk and set SELF_PROFILE_STORAGE_S3 on the Site to store self-profile archives in S3; otherwise they land in a local directory.