Brotli 压缩传输
正式站- 动作
- 由 Vercel CDN 对 WASM 响应协商 Brotli 编码。
- 结果
- 本地 q5 样本从 57.23 MiB 降到 13.48 MiB，减少 76.45%。线上已观察到 br 响应。
加载
WASM 传输体积
br 响应和一年强缓存，完整传输量待测。原始二进制构成
- 代码段
- 43.46 MiB
- 数据段
- 13.30 MiB
内容哈希与强缓存
正式站- 动作
- 用 WASM 内容哈希生成地址，对该地址设置一年 immutable 缓存。
- 结果
- 线上响应确认一年缓存并观测到 CDN HIT。浏览器热启动耗时待测。
按设备触发 preload
正式站- 动作
- 支持的桌面浏览器启动时动态插入 preload。触屏和移动设备等用户点击后再插入。
- 结果
- 模拟手机点击前 0 次引擎请求，点击后只发起 1 次主 WASM 请求。
gzip 分片与重试
正式站- 动作
- 主请求失败后加载清单，按序接收 265 个分片，最多并发 3 片，每片最多尝试 3 次。
- 结果
- 打包 gzip 为 16.52 MiB。模拟主请求断流及一个分片失败，共发起 266 次分片请求，重试后 SQL 通过。
显示实际下载进度
正式站- 动作
- 按解码后的字节计数，分别显示连接、主下载和分片下载状态。
- 结果
- 线上样本在 7.44 s 显示 0%，33.88 s 显示 0.2%。
加载阶段的备选方案
静态镜像
待验证- 动作
- 在目标网络可达的 CDN 部署同版本的整站静态资源。
- 结果
- 目标网络的完整传输时间和成功率待测。
HTTP Range 续传
待验证- 动作
- 用版本化压缩对象按区间补取缺失字节。
- 结果
- 现有静态分片返回 206。完整对象续传待验证。
离线资源缓存
待验证- 动作
- 按需用 Cache Storage 保存已经请求的版本化 WASM。
- 结果
- 预期减少重复传输。当前已有 HTTP 强缓存，额外收益待测。
编译
函数校验与下载的重叠时间
流式编译主响应
正式站- 动作
- 将下载中的字节流交给 WebAssembly.compileStreaming，边接收边编译。
- 结果
- 本地延迟尾包实验中，V8 在尾包放行前 871 ms 已开始校验函数。
分片边解压边编译
正式站- 动作
- 按顺序把 gzip 分片送入流式解压，解码后直接交给同一个 WASM 编译流。
- 结果
- 本地断流样本中，V8 在备用流结束前 1,161 ms 已开始校验函数，最终 SQL 通过。
按体积优化构建
构建流程- 动作
- C/C++ 编译与链接使用 -Oz，Rust WASM 使用 panic=abort，Rust 标准库使用 ThinLTO。
- 结果
- 当前原始 WASM 为 57.23 MiB。各参数的独立体积收益待测。
复用构建产物与缓存
构建流程- 动作
- 发布时复用已导入的 WASM 与加载器并校验哈希，构建重跑复用 Bazel action cache。
- 结果
- 本地成功重跑 84.63 s，命中 2,489 个 action cache。
编译阶段的备选方案
裁剪代码与静态数据
待验证- 动作
- 按符号和运行轨迹定位可移出首启路径的代码或数据，分别评估裁剪、外置和按需加载。
- 结果
- 代码段 43.46 MiB，数据段 13.30 MiB。裁剪后体积与 SQL 兼容性待测。
编译产物复用
待验证- 动作
- 保留页内 Module 复用，单独评估原生编译缓存和多个大模块时的编译并发。
- 结果
- 当前只有一个 WASM 模块。跨刷新编译缓存命中与收益待测。
实例化
初始线性内存
- 线性内存增长上限
- 2 GiB
- 引擎逻辑预算下限
- 1 GiB
启动配置对照
- 桌面正式版预热
- 64 个 pthread Worker
- 移动正式版预热
- 32 个 pthread Worker
- 桌面样本就绪
- 65 个 Worker
- 模拟手机样本就绪
- 45 个 Worker
把编译后的 Module 交给 Worker
现有实现- 动作
- 启动器完成流式编译，数据库 Worker 接收同一个 Module 并创建实例。
- 结果
- 本地真实引擎样本只发起 1 次主 WASM 请求，启动后可执行 SQL。
减少 pthread 预热
正式站- 动作
- 移动版将预热数从 64 改为 32。WASM 字节与桌面版一致，两条路径选用各自的 JS 加载器。
- 结果
- 模拟手机就绪时观察到 45 个 Worker，桌面样本为 65 个。
降低初始线性内存
本地实测- 动作
- 重新链接 384 MiB 和 256 MiB 两组配对产物，分别加载对应的 WASM 与 JS。
- 结果
- 两组首条 SQL 均通过。256 MiB 版在就绪、空闲 12 秒和首条 SQL 后均为 256 MiB。
验证引擎逻辑预算下限
本地实测- 动作
- 用同一产物测试 512 MiB 的引擎预算配置。
- 结果
- JS 校验通过，原生启动返回 exit 1。当前原生配置要求至少 1 GiB 逻辑预算。
实例化阶段的备选方案
单线程独立构建
待验证- 动作
- 为当前依赖线程的启动路径做单独构建和适配。
- 结果
- 启动、存储行为与 SQL 兼容性待验证。
执行
就绪后 Worker 数仍在增长
cpuCount=2cpuCount=1
43
42
就绪
80
78
空闲 12 s
80
78
首条 SQL 后
真实 SQL 验收
- 桌面 Playwright
- 8 项通过
- 模拟手机与桌面
- CRUD 通过
- 256 MiB · 首条查询
SELECT 42→ 42- 256 MiB · 查询后
- 线性内存仍为 256 MiB
在 Worker 中执行和关闭数据库
现有实现- 动作
- SQL 在数据库 Worker 中运行。正常关闭等待引擎完成清理，再终止 Worker。
- 结果
- 桌面回归覆盖 CRUD、取消、错误恢复和刷新清空。
调整 CPU 预算
本地实测- 动作
- 对同一 256 MiB 构建分别使用 cpuCount=2 和 cpuCount=1，观察就绪、空闲与首次 SQL。
- 结果
- 空闲 12 秒后，两组分别观察到 80 和 78 个 pthread Worker，首条 SQL 均通过。
执行阶段的备选方案
定位就绪后新增线程
待验证- 动作
- 按原生服务追踪 Worker 创建，并评估演示版可裁剪的后台工作。
- 结果
- 默认 CPU 样本就绪后从 43 增至 80 个 pthread Worker。进程内存收益待测。
独立云端演示
待验证- 动作
- 由服务端执行 seekdb SQL，浏览器负责输入与结果展示。
- 结果
- 属于独立执行模式，尚未实现。