Files
xiaotutongxue/backend/xt-server
lovife f86a999c52 perf(gate): 门禁成功上限 200→600 —— 250 人同时核验曾挡住 37 个(F-100)
契约 §1.6 只规定了失败侧(同 openid 10 次/小时、同 IP 20 次/分钟),
成功侧 200/分钟是本项目自己加的(防"拿匹配接口批量取数据"),
而当初注释里写的本意是"一个 200 人的年级同时扫码也不该被挡"。

实测(python scripts/load-test.py --only gate --rows 250):
250 个不同学生同时核验(全部正确)→ 213 成功、37 被挡,
提示「当前网络访问过于集中,请稍等 1 分钟再试」。
"全校在同一个出口 IP 集中扫码"(开学第一课集体填报)正是会发生的场景,
而这些人没有一个做错了什么 —— 与 F-92「教室被挡住」同一类,量级放大到一所学校。

上调为 600 的依据:一所学校一次集中填报的峰值。它仍然是限速(600 条/分钟),
而防枚举靠的是失败侧那两个计数器 —— 原样未动,防猜测强度没有降低。

验证:
  250 人 → 250/250(改前 213/37)
  500 人 → 500/500(500 并发 p50 1.4s / p95 2.5s,是排队不是限流)
  scripts/e2e-m3-gate.py → 29/29
文档同步:docs/01 E2(二次修正备案)、docs/09 §9.3 / §9.1。

教训:自己加的"防御性限额"也要过一遍真实场景的量级 ——
否则它与它要防的东西一样,都是事故。
2026-09-30 11:10:05 +08:00
..