forked from wangziqi/gongxue-base
test: record capacity guardrails
This commit is contained in:
Codex
@@ -8,7 +8,7 @@
|
||||
|
||||
- 环境：本地 Docker Desktop + 本地 Supabase/PostgreSQL + 本地 API 进程。
|
||||
- 数据：PocketBase 真实导出数据导入新 PostgreSQL 后压测。
|
||||
- 数据规模：当前真实迁移库已包含前期压测写入记录，约 74,117 道题、1,601 个题目合集、3,106 个练习蓝图、3,505 个单词、2,678 条知识手册、3,690 个用户、196,846 条答题记录、38,207 条错题和 466 条权益。
|
||||
- 数据规模：当前真实迁移库已包含前期压测写入记录，约 19 个租户、74,131 道题、1,631 个题目合集、3,120 个练习蓝图、3,519 个单词、2,692 条知识手册、3,722 个用户、72,710 个练习 session、302,585 条答题记录、38,207 条错题、1,501 个内容资源和 472 条权益。
|
||||
- Docker Desktop 资源：当前本机约 20 CPU、62.7GB 内存，高于常见 4 核 16G 云服务器；本地结果只用于观察代码和索引趋势。
|
||||
- 写入流量：混合场景开启真实刷题闭环，包含创建 session、拉取 session detail、提交若干答案、交卷和读取报告。
|
||||
- 商城说明：本地库的订单数据会受 seed、烟测和导入演练影响，当前容量结论聚焦题库读写链路，不用于推断 GMV、支付或订单峰值。
|
||||
@@ -149,11 +149,43 @@
|
||||
|
||||
按 50 worker 混合读写 115.82 req/s 粗略折算，理论请求吞吐约对应 580 到 2,316 名活跃在线学生，但因为该轮未完成 PostgreSQL 调参且只在本地 Docker Desktop 上运行，只能作为“未调参受限资源下限观察”，不能作为首版生产规划值。首版生产规划仍以上云调参后复测为准。
|
||||
|
||||
### 2026-07-01 06:44 Docker API 受限资源复核
|
||||
|
||||
本轮在新增 `scripts/product-scope-guardrails-test.js` 并完成 `npm run test:readiness`、`npm run security:repo`、`npm run audit:runtime`、API/worker/Taro 类型检查、`npm run smoke:taro:h5`、`npm run smoke:taro:h5:interaction` 和 `npm run smoke:launch-persona` 后复跑。压测入口仍为 `npm run perf:api:docker-4c16g`，API 容器限制为 2 CPU/4G，`DB_POOL_MAX=10`，压测鉴权使用 `PERF_AUTH_MODE=app_session`。数据库未额外限制，仍可使用 Docker Desktop 全局资源；排行榜未纳入默认负载。
|
||||
|
||||
| 场景 | 并发 worker | 时长 | 刷题写入比例 | 请求数 | 错误率 | 吞吐 | P95 | P99 | 门禁结论 |
|
||||
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | --- |
|
||||
| 只读上线门禁 | 30 | 120s | 0% | 38,724 | 0.00% | 321.92 req/s | 225.17 ms | 338.35 ms | 通过 |
|
||||
| 混合读写 | 50 | 60s | 10% | 23,810 | 0.00% | 394.19 req/s | 235.96 ms | 320.19 ms | 通过 |
|
||||
| 混合读写 | 100 | 60s | 8% | 23,384 | 0.00% | 386.14 req/s | 417.12 ms | 498.89 ms | 上沿观察 |
|
||||
| 混合读写 | 150 | 60s | 6% | 22,314 | 0.00% | 366.79 req/s | 613.15 ms | 744.50 ms | 压力区 |
|
||||
|
||||
本轮 `npm run perf:summary` 校验结果：
|
||||
|
||||
- 30 worker 只读门禁通过，满足 `errors=0`、`errorRate<=0.001`、`p95<=300ms`、`p99<=800ms`、`duration>=120s`。
|
||||
- 50 worker 混合读写满足 `P95<=500ms/P99<=1200ms`，仍是当前受限 API 容器下的舒适观察区。
|
||||
- 100/150 worker 均 0 错误，但 P95 已进入上沿/压力区，不作为生产承诺。
|
||||
|
||||
按 0.05 到 0.2 req/s/人的页面节奏粗略折算，50 worker 舒适吞吐约对应 1,970 到 7,880 名活跃在线学生请求吞吐；100 worker 上沿约对应 1,930 到 7,720 名；150 worker 压力区约对应 1,830 到 7,330 名。该数字仍是本地 API 受限、DB 未受限观察值，正式容量必须在目标云服务器和真实前端埋点下复跑。
|
||||
|
||||
### 2026-07-01 06:53 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`。PostgreSQL 参数仍是本地默认值，并未应用 `docs/refactor/postgresql-4c16g-tuning.md` 的 shared-host profile。
|
||||
|
||||
| 场景 | 并发 worker | 时长 | 刷题写入比例 | 请求数 | 错误率 | 吞吐 | P95 | P99 | 门禁结论 |
|
||||
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | --- |
|
||||
| 只读上线门禁 | 30 | 120s | 0% | 8,397 | 0.00% | 69.48 req/s | 1183.29 ms | 1697.59 ms | 失败，超过 P95/P99 |
|
||||
| 混合读写 | 50 | 60s | 10% | 6,640 | 0.00% | 109.61 req/s | 996.01 ms | 1303.45 ms | 失败，超过 P95/P99 |
|
||||
| 混合读写 | 100 | 60s | 8% | 6,381 | 0.00% | 104.13 req/s | 1705.51 ms | 2098.41 ms | 压力区 |
|
||||
| 混合读写 | 150 | 60s | 6% | 5,211 | 0.00% | 83.23 req/s | 3006.71 ms | 3699.64 ms | 压力区 |
|
||||
|
||||
结论：资源更严格后系统仍保持 0 错误，但延迟不满足上线门禁。按 50 worker 混合读写 109.61 req/s 粗略折算，理论请求吞吐约对应 548 到 2,192 名活跃在线学生；由于该轮未调 PostgreSQL 参数且只在本地 Docker Desktop 上运行，只能作为“未调参受限资源下限观察”，不能作为首版生产规划值。
|
||||
|
||||
## 初步结论
|
||||
|
||||
- 本地高资源 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 混合读写均未通过延迟门禁。
|
||||
- 本地高资源 Docker Desktop 历史结果显示代码和索引在 50/100 worker 下有较高吞吐；只限制 API 容器时，最新 50 worker 混合读写 P95 约 236ms，100 worker P95 约 417ms，150 worker P95 约 613ms；进一步把 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 单机，首版容量承诺不要直接沿用本地 API-only 的人数估算；应先以云端调参后复测结果为准。没有云端复测前，可以把 06:44 结果看作“API 受限但 DB 未受限的乐观观察”，把 06:53 结果看作“DB 也受限但未调参的悲观观察”。
|
||||
- 正式容量承诺必须在目标 4 核 16G 云服务器、生产 PostgreSQL 参数、对象存储/CDN、真实前端请求节奏和生产网络下复跑。
|
||||
|
||||
## 后续复测
|
||||
|
||||
Reference in New Issue
Block a user