docs: record db-limited capacity findings

docs/refactor/performance-benchmark-summary-20260630.md

@@ -134,11 +134,26 @@
 
 按 0.05 到 0.2 req/s/人的页面节奏粗略折算，50 worker 舒适吞吐约对应 2,080 到 8,330 名活跃在线学生请求吞吐；100 worker 上沿约对应 1,970 到 7,880 名；150 worker 压力区约对应 1,850 到 7,410 名。生产 4 核 16G 首版容量建议先按这组本地受限资源折算值的 30% 到 50% 保守规划，即约 620 到 4,160 名活跃在线学生请求吞吐，再以上云复测和真实前端埋点修正。
 
+### 2026-07-01 06:26 Docker API + DB 显式受限复核
+
+本轮使用 `BENCHMARK_LIMIT_DB_RESOURCES=true npm run perf:api:docker-4c16g`，API 容器限制为 2 CPU/4G，Supabase PostgreSQL 容器限制为 2 CPU/8G，`DB_POOL_MAX=10`，压测鉴权继续使用 `PERF_AUTH_MODE=app_session`。这比 05:57 只限制 API 容器更接近本地 4C16G 资源压力，但 PostgreSQL 参数仍是本地默认值，并未按 `docs/refactor/postgresql-4c16g-tuning.md` 应用 shared-host profile。
+
+| 场景 | 并发 worker | 时长 | 刷题写入比例 | 请求数 | 错误率 | 吞吐 | P95 | P99 | 门禁结论 |
+| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | --- |
+| 只读上线门禁 | 30 | 120s | 0% | 8,029 | 0.00% | 66.50 req/s | 1188.62 ms | 1697.71 ms | 失败，超过 P95/P99 |
+| 混合读写 | 50 | 60s | 10% | 7,088 | 0.00% | 115.82 req/s | 905.13 ms | 1211.98 ms | 失败，超过 P95/P99 |
+| 混合读写 | 100 | 60s | 8% | 6,383 | 0.00% | 103.63 req/s | 1720.26 ms | 2101.02 ms | 压力区 |
+| 混合读写 | 150 | 60s | 6% | 5,640 | 0.00% | 91.52 req/s | 2688.31 ms | 3284.99 ms | 压力区 |
+
+结论：资源更严格后系统仍保持 0 错误，但延迟不满足上线门禁。该结果不能作为生产容量承诺，反而证明云端正式部署前必须先完成 PostgreSQL shared-host 调参、`pg_stat_statements`、慢 SQL 观察和 4C16G 云服务器复测。尤其是 `learning.trend`、`learning.stats`、`learning.practice_flow.create/detail/answer` 在受限 DB 下最容易抬高 P95，应在云端结合慢 SQL 和 `EXPLAIN (ANALYZE, BUFFERS)` 继续看是否需要预聚合、缓存或索引微调。
+
+按 50 worker 混合读写 115.82 req/s 粗略折算，理论请求吞吐约对应 580 到 2,316 名活跃在线学生，但因为该轮未完成 PostgreSQL 调参且只在本地 Docker Desktop 上运行，只能作为“未调参受限资源下限观察”，不能作为首版生产规划值。首版生产规划仍以上云调参后复测为准。
+
 ## 初步结论
 
-- 本地高资源 Docker Desktop 历史结果显示代码和索引在 50/100 worker 下有较高吞吐；但最新受限 API 容器复核更接近保守上线口径，50 worker 混合读写 P95 约 215ms，100 worker P95 约 415ms，150 worker P95 约 622ms 已经进入压力区。
-- 按最新 416.54 req/s 的 50 worker 舒适吞吐粗略折算，如果未来前端真实埋点显示每名在线学生平均 0.05 到 0.2 req/s，则理论请求吞吐约对应 2,080 到 8,330 名活跃在线学生；按 100 worker 上沿 394.18 req/s 估算约为 1,970 到 7,880 名；按 150 worker 压力区 370.53 req/s 估算约为 1,850 到 7,410 名。这只是吞吐换算，不是生产 SLA。
-- 生产如果使用 4 核 16G 单机，首版容量承诺建议先按最新本地受限资源折算值的 30% 到 50% 保守规划，即约 620 到 4,160 名活跃在线学生请求吞吐，再以云端复测、真实前端埋点、CDN/对象存储和生产 PostgreSQL 调参后结果上调。
+- 本地高资源 Docker Desktop 历史结果显示代码和索引在 50/100 worker 下有较高吞吐；只限制 API 容器时，50 worker 混合读写 P95 约 215ms，100 worker P95 约 415ms，150 worker P95 约 622ms；进一步把 DB 容器也限制为 2 CPU/8G 后，30 worker 只读和 50 worker 混合读写均未通过延迟门禁。
+- 最新 DB 显式受限结果说明：不能仅凭本地 Docker API 受限跑分给生产承诺，生产 4C16G 必须先应用 PostgreSQL shared-host 调参并启用 `pg_stat_statements`，再跑正式只读/混合读写矩阵。
+- 生产如果使用 4 核 16G 单机，首版容量承诺不要再直接沿用 05:57 的 620 到 4,160 人估算；应先以云端调参后复测结果为准。没有云端复测前，可以把 05:57 结果看作“API 受限但 DB 未受限的乐观观察”，把 06:26 结果看作“DB 也受限但未调参的悲观观察”。
 - 正式容量承诺必须在目标 4 核 16G 云服务器、生产 PostgreSQL 参数、对象存储/CDN、真实前端请求节奏和生产网络下复跑。
 
 ## 后续复测