延迟定位与容量测试

处理器很快，请求仍可能很慢

2026 年 9 月 8 日的延迟调查中，一条生产请求在服务器边界内耗时约 111.85ms，业务处理器只用 0.048ms；约 111.78ms 发生在请求到达后、程序读取前，其中约 80.74ms 是线程等待 CPU。只给 handler 计时，会漏掉这类等待。

当时的初始负载为 100 张九人桌、900 个模拟连接，加每秒 1,000 次历史、会话和统计查询。60,000 次 HTTP 请求有 4,655 次返回 503。后续最终测试换了机器、查询组合与压测器，因此不能用初始和最终数字计算受控的整体加速比例。

把业务、持久化和测量分开

当时的改动包括内存读视图、批量持久化、历史查询索引与缓存，以及公共广播复用。必要资金与结算写入仍以数据库提交为准，不能把可跳过的分析与必需落库混为一谈。当前相关实现分别可查 server/src/live_directory.rs、server/src/session_registry.rs、server/src/write_behind.rs 和 server/src/outbound.rs。

9 月 9 日还对当时的赛后分析线程限额，并把连接写出合并成最多 16 条一批。前者是历史实现，不能据此声称当前版本仍有相同分析线程或配额；当前有界批次转发位于 server/src/ws/socket.rs。压测器自身改为每补发八个请求让出执行机会，这是测量工具修复，不是玩家端加速。

900 条连接究竟证明了什么

9 月 9 日 web-2026.09.09.5 的生产宿主机内网测试，压测器与服务共享两颗 vCPU：100 张九人桌、每桌每秒五次目标动作机会，叠加每秒 1,000 次实时 HTTP 查询。约一分钟内完成 25,030 次动作、688 手牌，60,000 次 HTTP 全部成功。

服务端与端到端耗时不是同一个指标；各阶段独立统计的 p99 也不能相加。同机压测器、Postgres 与服务争用资源，内网路径绕过了公网、TLS 和反向代理。这不是 900 名公网玩家的体验保证，更不证明当前版本容量。

公网结果受到测试路径限制

同日 web-2026.09.09.3 的单客户端公网阶梯中，较慢节奏（每桌目标 2.5 秒一次动作）117 人两轮各三分钟 p99 为 215.48ms、142.37ms，126 人为 606.36ms。高频节奏下 45 人三分钟为 267.41ms，54 人两轮为 506.12ms、290.04ms，已跨过 500ms 门槛波动。

后续诊断显示该客户端并发连接增加时，查询延迟明显上升，而游戏服务进程负载较轻；完整 900 连接的公网尝试未完成。上述结果界定的是该测试客户端和路径能送达的量，不能当作服务上限。225 人一轮还出现退座超时，清理验收失败；最终数据库核对测试座位已释放，不能把整轮称为全部通过。

重新证明容量需要源码匹配的版本、完整动作与请求关联、经过校准的独立压测器，以及明确的路径、负载和验收预算。真实设备上的按钮反馈与画面更新还需单独观察。