Standard hosted runner for required benchmarks
必需 benchmark 使用标准托管运行器
Wall-clock performance checks need an isolated execution lane and a consistent runner class. Routing them through the enterprise Linux failover switch makes their measurements depend on either larger hosted capacity or a shared self-hosted VM, while also consuming capacity needed by parallel correctness checks.
English
Problem
Wall-clock performance checks need an isolated execution lane and a consistent runner class. Routing them through the enterprise Linux failover switch makes their measurements depend on either larger hosted capacity or a shared self-hosted VM, while also consuming capacity needed by parallel correctness checks.
Decision
The required benchmark job in ci.yml uses the standard GitHub-hosted ubuntu-24.04 runner independently of Linux failover. It always attempts to restore the pnpm store cache and retains a standalone benchmark lane. The complete job has a 15-minute timeout covering setup, installation, builds, and measurements. This bounds infrastructure execution, not an individual performance assertion.
The Session performance decision continues to own workloads, timing and memory budgets, worker isolation, and calibration. Only current-generation open uses an endpoint-specific 50 ms standard-runner expectation with the existing 1.25× headroom, giving a 63 ms limit. All other performance budgets and the worker, test, and hook deadlines remain unchanged. Successful raw measurements remain in the Actions log through step-local DSH_GATE_VERBOSE=1. The hardware-comparison workflows retain their deliberately different runner sizes.
Alternatives considered
- Enterprise or shared self-hosted routing retains more build capacity but ties the measurement environment to unrelated failover operations.
- Increasing performance thresholds without endpoint measurements conflates a bounded CI execution with a regression allowance. Threshold changes require measured calibration and positive and negative controls.
Consequences
A standard runner trades parallel build capacity for a fixed measurement class without removing the required verdict. Cache misses and runner variation can still affect total duration. Each runner change needs an actual hosted benchmark run before its job timeout is treated as validated; local workflow assertions alone cannot establish execution time.
The owning workflow tests pin runner routing, unconditional cache restoration, required status, and the job timeout. Negative controls reject failover routing, a cache condition, and the former 30-minute job bound.
中文
问题
壁钟性能检查需要独立执行的 lane 和一致的运行器类别。通过企业 Linux 故障转移开关路由这些检查，会让测量取决于大型托管运行器或共享自托管虚拟机，同时占用并行正确性检查所需的容量。
决定
ci.yml 中的必需 benchmark job 使用标准 GitHub 托管 ubuntu-24.04 运行器，不受 Linux 故障转移影响。它始终尝试恢复 pnpm 存储缓存，并保留独立的 benchmark lane。整个 job 的超时为 15 分钟，覆盖准备、安装、构建和测量。这限制的是基础设施执行时间，而非单项性能断言。
Session 性能决策 继续拥有工作负载、时间和内存预算、worker 隔离及校准。仅当前 generation open 使用端点专属的 50 ms 标准运行器预期值，乘以既有 1.25 倍余量后得到 63 ms 上限。其他性能预算以及 worker、测试和钩子的截止时间均保持不变。步骤级 DSH_GATE_VERBOSE=1 使成功运行的原始测量保留在 Actions 日志中。硬件比较工作流保留有意设置的不同运行器规格。
考虑过的替代方案
- 企业或共享自托管路由保留更多构建容量，但使测量环境受无关故障转移操作影响。
- 没有端点测量就提高性能阈值，会混淆有界 CI 执行与退化容许量。阈值调整需要实测校准及正反例。
后果
标准运行器以并行构建容量换取固定测量类别，不移除必需判定。缓存未命中和运行器波动仍会影响总耗时。每次更换运行器都需要实际托管 benchmark 运行，才能认定 job 超时经过验证；本地工作流断言无法单独证明执行耗时。
所属工作流测试 固定运行器路由、无条件缓存恢复、必需状态及 job 超时。反例验证拒绝故障转移路由、缓存条件和原来的 30 分钟 job 上限。