Performance Baseline zh

性能基线

本页记录 SPACK Refine AOT 基准在本机环境下的性能结果。目标是用于回归追踪，不是生产 SLA。

范围

本次基准对比同一份前端构建产物的两种运行模式：

模式	说明
直接目录运行时	spack-runtime 直接服务前端 dist 目录。
AOT bundle 运行时	spack-compiler 把同一份 dist 编译成 app.spack，再由 spack-runtime 服务 bundle。

每轮会执行四组 k6 workload：

场景	含义
direct page	面向直接目录运行时的完整前端页面加载模型。
AOT page	面向 AOT bundle 运行时的完整前端页面加载模型。
direct static	面向直接目录运行时的热静态资源请求。
AOT static	面向 AOT bundle 运行时的热静态资源请求。

命令

$env:PATH='D:\msys64\usr\bin;' + $env:PATH
$env:SPACK_RUNTIME_BENCH_BUILD='false'
$env:SPACK_COMPILER_BENCH_BUILD='false'
$env:SPACK_PERF_ROUNDS='3'
$env:K6_VUS='256'
$env:K6_DURATION='2m'
task perf:aot:refine:baseline

图片矩阵变量会透传到 compiler 容器。保持 SPACK_IMAGE_ENABLE=false 可以得到纯静态资源基线；打开后可测量 compiler 生成图片变体的场景。

生成文件：

tmp/k6/results/refine-aot-baseline-summary.md
tmp/k6/results/refine-aot-baseline-summary.json
tmp/k6/results/*-baseline-rN.json
tmp/k6/results/refine-aot-startup-baseline-rN.json

测试环境

运行日期：2026-06-26。

项目	值
宿主机系统	Microsoft Windows 11 专业工作站版，version 10.0.26200，build 26200
宿主机 CPU	AMD Ryzen 7 9800X3D 8-Core Processor
宿主机 CPU 拓扑	8 物理核心，16 逻辑处理器
宿主机内存	61.56 GiB
Docker Desktop	Client 29.5.3，Server 29.5.3，Compose 5.1.4
Docker 引擎系统	Docker Desktop Linux VM，x86_64，WSL2 kernel 6.18.33.1-microsoft-standard-WSL2
Docker VM 资源	16 CPU，32,360,771,584 bytes 内存，约 30.13 GiB
Go	go1.26.4 windows/amd64
Node.js	v24.15.0
pnpm	10.33.4
Bash	MSYS2 Bash 5.3.15
runtime 基准镜像	spack-k6-bench:local，sha256:86d46ba8b02ece272d54e3b92d35508ebc2c45223eddea5adaef3ea1ec944f56
compiler 基准镜像	spack-compiler-bench:local，sha256:5d35e5926fb24e493379720505851d0a8ed34d697a742798f15a8fa6b6ec7247
k6 镜像	grafana/k6:latest，sha256:632ddbc81a4a9fdc9e597da91ab1d8fcf1916dd988b43b4a4559d2f8d8e73d47

启动就绪时间采样

Refine AOT benchmark 现在会在 Docker Compose 启动 direct 和 AOT runtime 容器后，立即记录启动就绪时间。每一轮都会写入：

tmp/k6/results/refine-aot-startup-baseline-rN.json

每个文件包含 direct runtime ready 毫秒数和 AOT runtime ready 毫秒数。这组数据用于捕获 bundle 启动解压和 direct catalog bootstrap 的回归。

基线结果

配置：3 轮，256 VU，每个 k6 workload 运行 2 分钟。

场景	最大失败率	平均 requests/s	requests/s 标准差	平均 p95	平均 p99
direct page	0.000000	1272.67	220.76	3170.03 ms	4460.87 ms
AOT page	0.000000	1780.89	180.80	2368.22 ms	3117.54 ms
direct static	0.000000	1533.28	238.38	836.82 ms	1696.54 ms
AOT static	0.000000	2202.64	46.09	597.17 ms	1345.95 ms

AOT 收益

对比	requests/s 变化	p95 变化	p99 变化
AOT page 相比 direct page	+39.94%	-25.29%	-30.11%
AOT static 相比 direct static	+43.66%	-28.64%	-20.66%

结论

在这组本地 Docker Desktop 基线里，AOT 路径的优势比较稳定：

• 页面加载吞吐约提升 40%。
• 热静态资源吞吐约提升 44%。
• 页面和静态资源 workload 的 p95、p99 都更低。
• 三轮所有场景都没有失败请求。

直接目录运行时仍然需要保留，它是零编译、低门槛部署路径。AOT runtime 更适合作为可在 CI 或镜像构建阶段运行 compiler 的性能路径。

注意事项

这些数字只代表本机环境，不应该当作生产性能承诺。

主要波动来源：

• Docker Desktop 与 WSL2 调度。
• k6 与 SPACK 容器运行在同一台宿主机。
• Windows 文件系统和 bind mount 行为。
• 测试时本机 CPU 负载。
• benchmark compose 文件里的 grafana/k6:latest 目前还没有按 digest 固定。

如果要作为 release 级别的性能基线，应该把原始 k6 JSON、机器配置、镜像 digest、运行配置和 commit SHA 一起保存到 release artifact。