xiongyuxing/gongxue-base
1
0
Fork 0
forked from wangziqi/gongxue-base
Code Pull Requests Activity

test: deepen taro h5 admin smoke and record capacity

Browse Source
This commit is contained in:
Codex
2026-07-01 08:07:05 +08:00
parent 08791bd5f6
commit 6ea6d154d8
5 changed files with 834 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/refactor/performance-benchmark-summary-20260630.md
View File

@@ -181,11 +181,30 @@
结论：资源更严格后系统仍保持 0 错误，但延迟不满足上线门禁。按 50 worker 混合读写 109.61 req/s 粗略折算，理论请求吞吐约对应 548 到 2,192 名活跃在线学生；由于该轮未调 PostgreSQL 参数且只在本地 Docker Desktop 上运行，只能作为“未调参受限资源下限观察”，不能作为首版生产规划值。
### 2026-07-01 07:59 Docker API 受限资源复核
本轮在增强 `scripts/taro-h5-interaction-smoke.js` 后复跑。H5 真实交互烟测已覆盖学生端核心旅程、租户后台内容导入/公共题库/学生运营/营销 CRM 分佣/主题角色成员写操作，以及平台后台租户/账务/题库授权/员工写操作，结果为 32/32 通过。随后使用 `npm run perf:api:docker-4c16g` 在真实迁移库上复跑 30/50/100/150 阶梯；API 容器限制为 2 CPU/4G，数据库未额外限制，压测鉴权为 `PERF_AUTH_MODE=app_session`。排行榜仍未纳入默认负载，头像相关链路不参与压测，因为学生头像产品策略已固定为男女预设头像。
| 场景 | 并发 worker | 时长 | 刷题写入比例 | 请求数 | 错误率 | 吞吐 | P95 | P99 | 门禁结论 |
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | --- |
| 只读上线门禁 | 30 | 120s | 0% | 36,800 | 0.00% | 305.59 req/s | 241.46 ms | 351.17 ms | 通过 |
| 混合读写 | 50 | 60s | 10% | 24,120 | 0.00% | 398.79 req/s | 231.28 ms | 325.94 ms | 通过 |
| 混合读写 | 100 | 60s | 8% | 22,462 | 0.00% | 370.86 req/s | 445.26 ms | 532.32 ms | 上沿观察 |
| 混合读写 | 150 | 60s | 6% | 20,708 | 0.00% | 340.74 req/s | 689.67 ms | 833.08 ms | 压力区 |
本轮结论：
- 30 worker 只读门禁通过，满足 `errors=0`、`errorRate<=0.001`、`p95<=300ms`、`p99<=800ms`、`duration>=120s`。
- 50 worker 混合读写满足 `P95<=500ms/P99<=1200ms`，仍是当前受限 API 容器下的舒适观察区。
- 100 worker 混合读写 0 错误但 P95 已到 445.26ms，适合作为上沿观察；150 worker 0 错误但 P95 已到 689.67ms，只作为压力区观察。
按 0.05 到 0.2 req/s/人的页面节奏粗略折算，50 worker 舒适吞吐约对应 1,994 到 7,976 名活跃在线学生请求吞吐；100 worker 上沿约对应 1,854 到 7,417 名；150 worker 压力区约对应 1,704 到 6,815 名。该数字仍是本地 API 受限、DB 未受限观察值，正式容量必须在目标云服务器和真实前端埋点下复跑。
## 初步结论
- 本地高资源 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 混合读写均未通过延迟门禁。
- 本地高资源 Docker Desktop 历史结果显示代码和索引在 50/100 worker 下有较高吞吐；只限制 API 容器时，最新 50 worker 混合读写 P95 约 231ms，100 worker P95 约 445ms，150 worker P95 约 690ms；进一步把 DB 容器也限制为 2 CPU/8G 后，30 worker 只读和 50 worker 混合读写均未通过延迟门禁。
- 最新 DB 显式受限结果说明：不能仅凭本地 Docker API 受限跑分给生产承诺，生产 4C16G 必须先应用 PostgreSQL shared-host 调参并启用 `pg_stat_statements`，再跑正式只读/混合读写矩阵。
- 生产如果使用 4 核 16G 单机，首版容量承诺不要直接沿用本地 API-only 的人数估算；应先以云端调参后复测结果为准。没有云端复测前，可以把 06:44 结果看作“API 受限但 DB 未受限的乐观观察”，把 06:53 结果看作“DB 也受限但未调参的悲观观察”。
- 生产如果使用 4 核 16G 单机，首版容量承诺不要直接沿用本地 API-only 的人数估算；应先以云端调参后复测结果为准。没有云端复测前，可以把 07:59 结果看作“API 受限但 DB 未受限的乐观观察”，把 06:53 结果看作“DB 也受限但未调参的悲观观察”。
- 正式容量承诺必须在目标 4 核 16G 云服务器、生产 PostgreSQL 参数、对象存储/CDN、真实前端请求节奏和生产网络下复跑。
## 后续复测