从延迟定位到公网容量实测：BluffKing 优化了什么

1）怎么定位到延迟的？

9 月 8 日凌晨 01:22，我们让 100 张九人桌、900 个模拟玩家连接持续打牌，同时每秒发出 1,000 次历史记录、会话和统计查询。60,000 次 HTTP 请求中，4,655 次返回 503，失败率约 7.76%；整体 HTTP p99 为 422.73ms，统计接口达到 654.19ms。出牌到同桌九人收到结果的 p99 则为 108.41ms。p99 表示约 99% 的测量样本不超过这个耗时。

第一轮说明查询链路存在明显问题，但不能仅凭一个 p99 判断原因。我们把一次请求拆成几段：压测器等待发送、网络传输、服务器收包后等待程序读取、业务处理，以及结果向所有玩家发送。同步检查数据库查询、线程调度、连接上限和后台计算。

生产诊断抓到了一条很有代表性的请求：完整服务端耗时约 111.85ms，业务处理只有 0.048ms，约 111.78ms 花在请求已经到达服务器、程序却还没有读取的阶段。其中，线程等待 CPU 的时间约 80.74ms。只看业务函数的计时，会漏掉真正拖慢响应的等待。

压测器本身也会干扰结果：定时器落后后集中补发请求，挤占处理回包和牌桌消息的机会。于是，诊断既要追踪服务器，也要确认测量工具能按计划发送和接收。

2）降低延迟做了哪些改进？

减少实时操作对数据库的等待。牌桌当前状态、实时战绩、大厅和房间查询改用内存视图；同一手牌的玩家记录与行动时间线批量保存；历史查询增加索引、按已提交版本失效的缓存和批量版本检查，减少重复读取与数据库往返。

把必要落库与可延后的分析分开。必要写入进入有界、有序的后台队列，资金、成员状态和结算成功仍以数据库提交为准。恢复快照和新旧进程接管保护一起保留。胜率估算移出实时处理线程，赛后分析使用独立后台计算线程，并在 Linux 上降低可延后分析的优先级。

少算、少构造相同内容。翻牌前点数和同花关系相同的手牌共享胜率缓存；河牌公共牌固定后，在一次模拟内复用已经算过的牌力，保留原有随机抽样、模拟次数和结果。同一手牌的公共字段和相同广播内容复用构造、序列化结果，同时保留消息顺序和私牌可见范围。

消除系统层面的额外等待。HTTP 与 WebSocket 关闭 Nagle 小包缓冲；牌桌服务禁止使用 swap；文件描述符上限从 1,024 提高到 65,536，为 900 个玩家连接之外的 HTTP 和数据库连接保留空间。容器提高 CPU 调度权重，并修正调度层级，让优先权在与宿主机其他任务竞争时也能生效。

本轮最后一个优化提交是 23:20 的 111f247d，合入主线后为 e89e574f：压测器每补发八个请求，就让出一次执行机会处理网络 I/O，保留原定请求量和超时口径。这改进了测量工具的调度，不能直接算作玩家端的加速。

最初测的是本地历史查询混合负载，最后测的是生产实时查询。机器、接口与压测器均有变化，因此本文不把两轮数字写成受控的整体加速比例。最初 4,655 次 HTTP 失败、最后一轮全部成功，也是不同测试条件下的结果。

3）目前是否还有性能提升空间？

有，接下来应重点减少排队和抖动。9 月 8 日最后一轮测量中，实时 HTTP 业务处理 p99 只有 0.171ms，但服务器完整收包到写出的 p99 为 7.08ms。WebSocket 从服务器收包到向同桌九人全部写出，p99 为 12.20ms。处理器之外的等待、牌桌任务调度和广播尾段，仍值得继续分析。

测量工具也还没有完全消除干扰：该轮 HTTP 发送调度延迟 p99 仍达 618.80ms，包含这段等待的端到端 p99 为 625.09ms。这不能全部归因于服务器，也不能从验收中直接删掉。后续公网测试改用独立压测机，并在测试前用独立回显进程校准 900 个连接：5,000 次九人组动作的全组收齐 p99 为 21.16ms，发送调度 p99 为 2.20ms。这证明压测器能处理本轮计划的连接数和动作量，但不能替代公网测量。

进一步隔离后台分析、减少重复状态传输，以及按牌桌分配到多个服务实例，都有优化空间，但需要分别验证收益。各分段独立统计的 p99 不能直接相加；服务端耗时也不等于玩家看到画面更新的时间。该轮结果仍未全部达到原先服务端 p99 低于 10ms 的目标。

9 月 9 日的公网补测进一步说明长尾仍有优化空间：225 人按每桌 2.5 秒一次动作运行时，p95 为 114.55ms，p99 却达到 4.03 秒。后续应同步测量动作期间的线程等待、广播队列和公网发送，定位这些尖峰。本轮不能据此认定唯一瓶颈，也不能把平均动作频率按比例换算成容量。

4）prod 最多能让多少人同时打牌，且 p99 低于 500ms？

本轮公网实测：较慢节奏最高重复通过 117 人；高频场景 45 人通过，54 人已出现跨门槛波动。在每桌目标每秒五次动作的高频场景中，45 人三分钟 p99 为 267.41ms；54 人两轮分别为 506.12ms 和 290.04ms，已经不稳定；63 人三分钟为 536.41ms。因此，45 人是本轮测试中低于波动边界的通过点，54 人是测得的最高单轮通过点，不能把后者当作稳定承诺。

下面是同一生产版本的全部高频结果。频率是目标动作机会，牌局切换或等待前一动作确认时不会强行发送无效操作；表中列出实际确认的动作样本数。每张桌九个已认证模拟玩家，使用 H5 的 compact-v1 协议过牌或跟注，牌桌之间错开发送时刻；计时从计划出牌到同桌九人全部收到结果，包含压测器发送等待和公网传输。最大值也一并列出：p99 低于 500ms，并不代表每次操作都低于 500ms。

较慢节奏的最高通过点是 13 桌、117 人。按每桌目标 2.5 秒一次动作，两轮各三分钟的 p99 分别为 215.48ms 和 142.37ms，样本数分别为 906 和 905。相邻的 14 桌、126 人 p99 为 606.36ms，15 桌为 638.93ms，18 桌为 1,534.61ms，25 桌为 4,031.06ms。因此，在本轮公网路径与该负载下，117 人是重复通过的最高档，126 人已越过 500ms 上限。这里的较慢节奏是测试模型，并非从真实用户行为统计得到。

测试怎样绕过单出口的连接数量限制？生产普通 WebSocket 上限为 900，另有 100 个返回连接预留，每个公网 IP 最多 12 个连接。我们给已认证的测试账号使用限时计数许可，绑定来源 IP、测试批次、运行版本、账号名单和到期时间，只调整这些账号的每 IP 连接计数；全站和账号级保护保持有效。连接实际经过 https://app.bluffking.ai 的公网网络、TLS 和反向代理，没有改走内网。测试后移除了许可并核对测试座位全部释放。这使单出口可以测量公网服务容量，但不等同于多个地区、运营商和设备的体验测试。

所有表中列出的正式窗口都完成了预定时长，每桌实际完成牌局；连接零掉线，动作全部确认，必要落库与筹码守恒检查通过。225 人测试另有一桌离席步骤超时，因此清理验收项也未通过；最终数据库核对所有测试座位均已释放，其余各档清理检查通过。不叠加 HTTP 查询压力。旧测试还要求 p99 不超过 200ms、最大值不超过 1,000ms，其失败结果保留；本文按用户关心的 p99 严格低于 500ms 单独判断，未改写原始报告。

为什么之前可以测到 900 人？9 月 8 日 23:29 的测试在 2 vCPU、约 4GB 内存的生产宿主机上运行，压测器与服务同机，直达内网地址。100 桌、900 个连接、每桌目标每秒五次动作，另加每秒 1,000 次实时 HTTP 查询，约一分钟完成 24,665 次动作和 681 手牌，出牌 p99 为 214.64ms；60,000 次 HTTP 全部成功，但 HTTP 端到端 p99 为 625.09ms。它证明了这组条件下的内网处理能力，没有覆盖公网传输。文章首版发布后的单桌公网补测则为 355.33ms p99、253 次动作。

这些结果回答的是指定版本、路径和负载下的实测边界，不是任意网络环境下的永久最大值。三分钟窗口仍短，混合查询、较长时间运行、不同运营商和移动网络可能进一步降低可用容量。“完全感受不到延迟”也不能仅凭服务器或收包时间承诺，还要测真实设备的按钮反馈与画面更新。普通连接配置为 900，并不保证 900 人在公网同时出牌仍低于 500ms。

时间均为新加坡时间。优化过程覆盖 2026-09-08 的 01:22 基线至 23:20 提交 111f247d（主线 e89e574f）。9 月 9 日公网阶梯测试运行版本为 web-2026.09.09.3（bb0d2c9c）。表中每行独立统计，未把不同窗口的 p99 取平均。