gbrain (PostgreSQL) 性能测试报告

Codex 核验(2026-10-09):保留 2026-06-23 原始测量,本次未重跑。原文以 list_pages/health 的耗时作 search 的基线,不能推出“写后 35x 退化”或写锁阻塞;写后 search 均值 1.1s 反而低于此页普通 search 均值 1.4s。未记录并发发起方式、内部阶段计时与数据库版本,因此只可作为该环境的小样本端到端记录。

日期: 2026-06-23
引擎: PostgreSQL(数据库版本未记录;原记 v0.42.42.0,疑似应用版本,待核验)
嵌入模型: ZeroEntropy zembed-1 (1280d)
搜索模式: balanced
环境: WSL Ubuntu, ${LOCALIP}:8920

测试说明

通过 MCP HTTP 协议直接对 gbrain 发请求(initialize → notifications/initialized → tools/call 三步握手),记录写延迟、读延迟、写后搜索和连续探活;真正并发与阻塞需要匹配对照另测。

1. 写延迟 (put_page)

大小内容量样本P50均值范围
tiny~50 字3593ms750ms437-1220ms
small~500 字3398ms409ms398-429ms
medium~4000 字3661ms649ms615-670ms
large~20000 字33.7s3.7s3.3-4.0s

结论: 小样本中 small (500字) 约400ms,large 约3.7s。embedding、分块和数据库写入都可能贡献耗时;未提供分阶段计时,无法断定 PostgreSQL 写入瞬间完成或唯一瓶颈在嵌入 API。

2. 读延迟

操作P50均值说明
get_health32ms46ms纯 HTTP 往返 + 简单 SQL 探活
get_stats27ms24msCOUNT 聚合查询
list_pages (200条)12ms11ms最快的读操作
search (向量搜索)1.3s1.4s慢在 embedding 查询 API + HNSW 搜索
query12ms—❌ 返回 internal_error;缺推理模型是待核验的原因假设

结论: list_pages/stats/health 的端到端 P50 为12–32ms,search 为1.3s;不能据此拆分 HTTP、SQL、embedding 与检索各阶段耗时。query 当次返回错误,12ms 不计为成功查询性能,故障原因待核验。

3. 写后搜索记录(未证明阻塞)

5 轮交替:写入 medium 内容 → 立即搜索回读。

统计写读(紧随写后)
平均706ms1.1s
最小574ms1.0s
最大747ms1.2s

对比: list_pages 与 search 是不同操作,不能作为同一基线比较。写后 search 均值1.1s,普通 search 均值1.4s;这些样本不支持“35x退化”或写锁/索引刷新阻塞的结论。确认阻塞需使用相同查询、模型、连接与并发条件进行写前/写后对照并采集内部计时。

4. 连续探活 (10x get_health;并发发起方式未记录)

指标值
P5027ms
P9531ms
均值27ms
范围23-31ms

结论: 这10次探活延迟集中在23–31ms;若是连续串行调用,只能说明此批探活稳定,不能证明 PostgreSQL 并发性能。

5. MCP 连接开销

场景耗时
新连接含握手 (init+notify)~25ms
复用连接纯调用~5ms

建议: 持续会话复用 HTTP 连接,避免每次重连。

总结

维度评级说明
读性能🟢 优秀list_pages/stats/health 10-30ms
写性能🟡 小样本记录400-700ms 小内容,大内容3.7s;瓶颈未分阶段计时
阻塞⚪ 未证明写后search均值1.1s;与普通search均值1.4s不能推出退化
连续探活🟢 当批稳定未记录真正并行调用,不能评价并发能力
向量搜索🟡 端到端记录P50约1.3s,内部瓶颈未测
Query 工具🔴 当次失败internal_error,根因待核验
PostgreSQL vs PGLite⚪ 无对照结论本文没有同条件A/B测试,不能给出相对性能评级