134 lines
11 KiB
Markdown
134 lines
11 KiB
Markdown
|
# 性能基准
|
|||
|
|
|
|||
|
|
## 测试方法与复现
|
|||
|
|
|
|||
|
|
`benchmark/` 中的应用名为 `benchmark4csql`。它启动真实 `chusql-server`，通过本机 TCP 使用共享客户端协议，服务端调用 Rust 存储；不以纯内存引擎测量代替端到端性能。每次运行创建独立临时数据库，结束后停止服务并清理数据。任一 SQL、结果校验或并发请求失败会使运行失败。
|
|||
|
|
|
|||
|
|
在 `benchmark/` 中构建优化版本，并在 PATH 中放置 release 存储动态库：
|
|||
|
|
|
|||
|
|
```powershell
|
|||
|
|
$env:TMP = 'D:\Workspace\ChuSQL\logs\cli-test-tmp'
|
|||
|
|
$env:TEMP = $env:TMP
|
|||
|
|
$env:PATH = 'D:\Workspace\ChuSQL\chusql-core\storage\target\release;' + $env:PATH
|
|||
|
|
$env:GHC_CHARENC = 'UTF-8'
|
|||
|
|
stack build chusql-core-model chusql-core-engine chusql-interface chusql-server chusql-bootstrap benchmark4csql --force-dirty --ghc-options=-O2
|
|||
|
|
stack exec -- benchmark4csql 10000 50000
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
首次运行前从 `chusql-core/storage/` 执行 `cargo build --release`，并创建上面的临时目录。Linux 使用 `LD_LIBRARY_PATH` 指向 release 存储目录。两个参数分别为用户数、订单数，默认 10,000 / 50,000，均需至少 100。
|
|||
|
|
|
|||
|
|
读取场景先预热一次，再采样七次，记录均值、p50、p95、最大延迟与请求数/秒。p95 使用最近秩；七次采样的 p95 等于最大值，只适合比较本次场景，不能作为稳定的生产尾延迟。并发场景使用独立的已认证 TCP 会话，1、4、8 个客户端各执行 100 次点查，同步开始；吞吐以整个并发阶段的墙上耗时计算，连接与登录不计入该阶段。
|
|||
|
|
|
|||
|
|
加载主表每条 INSERT 包含 500 行。另测逐条持久化提交、200 条 INSERT 的单次事务提交、更新、删除和事务回滚。写入保留正常 WAL、数据刷盘与检查点路径，没有关闭持久化。查询耗时包含 TCP、SQL 解析、语义检查、引擎执行与响应解码；不包含 UI 渲染。读测试主要校验结果行数，加载 COUNT、并发点查值和回滚后值另行校验。
|
|||
|
|
|
|||
|
|
## 实测环境
|
|||
|
|
|
|||
|
|
- 测量日期：2026-10-05，Asia/Shanghai。
|
|||
|
|
- CPU：AMD Ryzen 7 7840H，8 核 / 16 逻辑处理器。
|
|||
|
|
- 可见物理内存：31.2 GiB。
|
|||
|
|
- 系统：Windows 11 专业版，10.0.26200。
|
|||
|
|
- 数据目录：D 盘 NTFS 上的仓库 `logs/` 临时子目录；未测存储设备裸吞吐。
|
|||
|
|
- 编译：GHC 9.10.3，Haskell 本地包 `-O2`；Rust release 动态库。
|
|||
|
|
- 规模：10,000 用户、50,000 订单、5,000 条 512 字节字符串宽行；订单按用户循环分配，年龄按 100 个值循环分布。
|
|||
|
|
|
|||
|
|
## 性能测试结果
|
|||
|
|
|
|||
|
|
完整运行返回退出码 0，输出 `PRESSURE_OK all result checks passed` 和 `BENCHMARK_OK all scenarios completed`。原始日志保存于本机 `logs/benchmark-performance.log`。下面保留该次成功运行的数据；首次失败运行不参与统计。
|
|||
|
|
|
|||
|
|
启动、引导、认证及创建基准库合计 0.62 秒。纯 TCP Ping 200 次平均 0.100 ms；schema catalog 200 次平均 0.267 ms。主键点查另外连续执行 100 次，平均 0.300 ms，100/100 命中。
|
|||
|
|
|
|||
|
|
### 读取场景
|
|||
|
|
|
|||
|
|
每项七个测量样本，单位为毫秒。请求吞吐由总采样耗时计算，为串行吞吐。
|
|||
|
|
|
|||
|
|
| 场景 | 返回行数 | 均值 | p50 | p95 / 最大值 | 请求/秒 |
|
|||
|
|
| --------------------------------------- | -------: | --------: | --------: | -----------: | -------: |
|
|||
|
|
| 用户全表扫描 | 10,000 | 23.768 | 18.961 | 36.309 | 42.07 |
|
|||
|
|
| 订单全表扫描 | 50,000 | 114.094 | 118.676 | 131.074 | 8.76 |
|
|||
|
|
| 主键点查 | 1 | 0.415 | 0.278 | 0.742 | 2,408.23 |
|
|||
|
|
| name 点查，无二级索引 | 1 | 21.776 | 21.908 | 23.257 | 45.92 |
|
|||
|
|
| name 点查，有二级索引 | 1 | 0.338 | 0.312 | 0.466 | 2,961.71 |
|
|||
|
|
| 主键闭区间范围，100 行 | 100 | 0.675 | 0.644 | 0.985 | 1,482.33 |
|
|||
|
|
| 按年龄排序，LIMIT 100 | 100 | 19.361 | 20.748 | 21.720 | 51.65 |
|
|||
|
|
| 100 个年龄值分组计数 | 100 | 18.139 | 17.843 | 22.200 | 55.13 |
|
|||
|
|
| 用户与订单过滤连接 | 4,500 | 144.929 | 142.598 | 158.723 | 6.90 |
|
|||
|
|
| 过滤派生表与订单连接 | 4,500 | 141.797 | 141.535 | 148.438 | 7.05 |
|
|||
|
|
| CTE 后按年龄分组 | 100 | 28.539 | 29.146 | 30.921 | 35.04 |
|
|||
|
|
| 无关联 COUNT 标量子查询，外层 LIMIT 100 | 100 | 30.777 | 29.844 | 34.692 | 32.49 |
|
|||
|
|
| EXISTS，20 个不同外层绑定 | 20 | 2,061.770 | 2,070.403 | 2,123.953 | 0.49 |
|
|||
|
|
| 512 字节字符串宽行全表扫描 | 5,000 | 22.969 | 22.791 | 24.485 | 43.54 |
|
|||
|
|
|
|||
|
|
相关 EXISTS 用派生表先限定外层为前 20 个用户，每次子查询按 `orders.user_id = u.id` 匹配；`orders.user_id` 没有二级索引。每个绑定具有五条订单，外层与内层都读取真实存储。
|
|||
|
|
|
|||
|
|
### 并发点查
|
|||
|
|
|
|||
|
|
每客户端 100 次主键点查。单请求延迟合并所有客户端样本计算；总吞吐用并发阶段墙上时间计算，不能用单请求延迟均值的倒数替代。
|
|||
|
|
|
|||
|
|
| 客户端 | 请求数 | 墙上耗时 ms | 总吞吐 请求/秒 | 单请求均值 ms | p50 ms | p95 ms | 最大 ms |
|
|||
|
|
| -----: | -----: | ----------: | -------------: | ------------: | -----: | -----: | ------: |
|
|||
|
|
| 1 | 100 | 29.094 | 3,437.10 | 0.290 | 0.250 | 0.544 | 1.183 |
|
|||
|
|
| 4 | 400 | 37.862 | 10,564.79 | 0.374 | 0.335 | 0.574 | 1.796 |
|
|||
|
|
| 8 | 800 | 48.877 | 16,367.72 | 0.481 | 0.437 | 0.735 | 2.027 |
|
|||
|
|
|
|||
|
|
### 写入、索引及事务
|
|||
|
|
|
|||
|
|
这些写入阶段各测量一次，不报告分位数。场景按顺序执行，数据库大小、已打开表数量和索引状态会变化。
|
|||
|
|
|
|||
|
|
| 场景 | 处理行数 | 总耗时 ms | 行/秒 |
|
|||
|
|
| ---------------------------------------------- | -------: | ---------: | --------: |
|
|||
|
|
| 用户加载，500 行/提交 | 10,000 | 762.419 | 13,116.15 |
|
|||
|
|
| 订单加载，500 行/提交 | 50,000 | 3,915.697 | 12,769.12 |
|
|||
|
|
| 512 字节宽行加载，500 行/提交 | 5,000 | 1,084.740 | 4,609.40 |
|
|||
|
|
| writes 逐条持久化 INSERT | 200 | 1,119.0 | 178.73 |
|
|||
|
|
| writes 事务中 200 条 INSERT，含 BEGIN / COMMIT | 200 | 67,549.539 | 2.96 |
|
|||
|
|
| batch_t 加载，100 行/提交 | 10,000 | 1,309.4 | 7,637.09 |
|
|||
|
|
| items 加载，100 行/提交 | 50,000 | 6,336.8 | 7,890.42 |
|
|||
|
|
|
|||
|
|
其他单次耗时：
|
|||
|
|
|
|||
|
|
| 操作 | 耗时 ms |
|
|||
|
|
| -------------------------------- | ------: |
|
|||
|
|
| 10,000 行 users 建 name 索引 | 239.7 |
|
|||
|
|
| UPDATE writes 的 400 行 | 16.4 |
|
|||
|
|
| 事务内 UPDATE writes 的 400 行 | 0.5 |
|
|||
|
|
| ROLLBACK 上述修改 | 0.3 |
|
|||
|
|
| DELETE writes 的 200 行 | 10.3 |
|
|||
|
|
| DELETE users 单行 | 48.1 |
|
|||
|
|
| DELETE users 全部剩余行 | 765.7 |
|
|||
|
|
| 50,000 行 items 无索引 code 点查 | 135.2 |
|
|||
|
|
| 50,000 行 items 建 code 索引 | 1,089.8 |
|
|||
|
|
| 建索引后 code 点查 | 0.4 |
|
|||
|
|
|
|||
|
|
回滚后校验 `writes.id = 1` 的 age 仍为 2，事务中写入的 0 没有落入正式数据。删除后 writes 行数为 200。加载、连接及并发点查的结果校验全部通过。
|
|||
|
|
|
|||
|
|
## 性能瓶颈分析
|
|||
|
|
|
|||
|
|
### 1. 事务提交的整库差分是首要排查点
|
|||
|
|
|
|||
|
|
本次 200 条事务 INSERT 比 200 次独立持久化 INSERT 慢约 60 倍。事务阶段开始时，数据库已有 10,000 用户、50,000 订单及 5,000 宽行，事务只修改 writes 表。事务内一次 400 行 UPDATE 仅耗时 0.5 ms，说明不能将整个事务阶段的 67.55 秒简单归因于 SQL 更新计算或 fsync。
|
|||
|
|
|
|||
|
|
代码依据：服务端 [Session.hs](../chusql-server/src/ChuSQL/Server/Session.hs) 的 BEGIN 和 COMMIT 都获取整库快照。`transactionDiffs` 对具有整数 id 的表先走 keyedDiff，即使 staged 与 base 完全相同，也会建立关联列表并对每行执行线性 `lookup` / `any`；50,000 行未修改表仍可能进行平方级比较。COMMIT 分别调用冲突检查和操作生成，可能重复计算差分。这是与实测异常最吻合的瓶颈候选。
|
|||
|
|
|
|||
|
|
当前没有 BEGIN、逐条语句、COMMIT 的独立计时或 CPU profile，不能给各部分分摊比例。下一步应先拆分计时，再对未修改表快速跳过、以 Map / HashMap 做按 id 差分、复用一次差分计算结果，并考虑记录实际修改表与键。整库快照及内存统计重算也需要测量。不能据当前实现假设把 Web 编辑放进一个大事务就会更快。
|
|||
|
|
|
|||
|
|
### 2. 不同绑定的相关子查询仍重复扫描
|
|||
|
|
|
|||
|
|
20 个 EXISTS 绑定平均 2.06 秒，而单次 50,000 行订单扫描约 114 ms；两者量级相符。缓存只能合并相同绑定，这里的 20 个用户 id 都不同，因此仍需多次读取订单。执行路径 [Eval.hs](../chusql-core/engine/src/ChuSQL/Core/Engine/Algebra/Eval.hs) 将子查询逐绑定执行，没有半连接，EXISTS 也先得到子查询结果再判断是否为空。
|
|||
|
|
|
|||
|
|
优先验证 `orders.user_id` 二级索引及基于统计的点查选择，再评估半连接、EXISTS 找到首行即可停止、或单次物化内层匹配键。这个推断有查询结构和耗时量级支持，但本次没有对索引版相关子查询做对照，不把预期收益当作已测结果。
|
|||
|
|
|
|||
|
|
### 3. 扫描、结果传输与全量排序限制大结果查询
|
|||
|
|
|
|||
|
|
50,000 行扫描比 10,000 行扫描慢约 4.8 倍。无索引 name 点查只返回一行，耗时仍接近用户全表扫描；索引后均值下降约 64 倍，说明扫描工作量具有决定性影响。宽行加载吞吐降至约 4,609 行/秒，低于短行的约 1.3 万行/秒。
|
|||
|
|
|
|||
|
|
`sortRows` 使用完整 `sortBy` 后再 LIMIT，返回 100 行并不代表只处理 100 行。当前全表结果会经过存储解码、引擎求值及 TCP JSON 编码。下一步可测 Top-K 排序、分页或流式返回，以及存储、引擎、编码各阶段的时间和分配量。本次没有冷缓存、磁盘裸吞吐、分阶段 CPU 或内存峰值测量，无法把扫描耗时全部归到磁盘。
|
|||
|
|
|
|||
|
|
### 4. 批量提交有效，读并发扩展低于线性
|
|||
|
|
|
|||
|
|
批量加载达到约 1.3 万行/秒，200 次独立提交只有约 179 行/秒。数据和已打开表数量不同，这不是严格的单变量对照；但与 WAL 提交、表刷盘和检查点固定成本被摊薄的执行路径一致。Rust 的 `group_via_wal` 还会刷所有已打开表，应单独测量并评估只刷本组实际修改表的收益及恢复正确性。
|
|||
|
|
|
|||
|
|
8 客户端点查总吞吐约为 1 客户端的 4.8 倍，单请求均值从 0.290 ms 上升至 0.481 ms。表明只读请求有并发收益，也存在共享资源、调度或协议开销。本次没有混合读写或并发写压测，不据此推断写扩展能力；当前每库写独占的限制仍在。
|
|||
|
|
|
|||
|
|
## 使用范围
|
|||
|
|
|
|||
|
|
这是单机回环、主要为热缓存、管理员身份的单次基准，不是生产容量承诺。未覆盖远程网络、鉴权角色开销、崩溃恢复耗时、并发写冲突或大型宽表。七次读采样和单次写测量不足以建立统计置信区间，后续优化应使用相同参数、多次独立运行和分阶段 profile 比较。
|