scheduler_ceiling

Overview ¶

Command scheduler_ceiling is Load Experiment 1: the scheduler ceiling.

It measures how the leader scheduler's per-tick wall-time scales with the number of active runs N, so we can find where a tick's cost approaches the loop interval (~1s by default). The leader loop calls Scheduler.Step once per tick; Step's dominant read is Store.ActiveRuns, which issues 1 + 2N DB queries (one list, then GetDagVersionByID + ListTaskInstancesByRun per run) plus N spec unmarshals, and then advances every run serially. This harness drives the REAL scheduler over a REAL Postgres so those costs are measured, not modeled.

It boots no cluster and no executor: it seeds N synthetic DAGs, each with one run pinned in `running` with a `running` task instance. Such a run stays in the active set across ticks and Step's advance is a cheap no-op for it (nothing to dispatch, nothing to finalize) — so what we time is the steady-state read + per-run advance cost, which is exactly Experiment 1's target.

It is harness-only: it imports the storage/scheduler packages the same way the integration tests do and touches no product code path.

Usage (see test/load/README.md for the full runbook):

# 1. bring up Postgres and migrate + seed the `default` tenant
docker compose -f docker-compose.dev.yaml up -d
go run ./cmd/dexaflow db reset --yes
# 2. run the experiment
DATABASE_URL='postgres://leoflow:leoflow@localhost:5432/leoflow_dev?sslmode=disable' \
  go run ./test/load/scheduler_ceiling --n 50,200,500,1000 --window 5s