游戏卡顿白皮书 › L9 服务器游戏进程
广播激增 Broadcast fan-out (N×N)
原因 ID sp-broadcast · 主责 研发团队·服务器开发 · 配合 运维团队·系统运维
在含图示和实验的完整版中打开此卡片 →
把一个人的移动发给所有能看到他的人时，要发的更新数量是聚集人数的平方。
起因 把一个人的变化发给所有能看到他的人 → 结果 1,000 人互相能看到时，每个 tick 有 100 万条更新 → 画面表现 发送队列和带宽饱和，产生延迟和丢包（操作延迟、快进、瞬移）
- 症状
- 操作延迟, 瞬移, 快进
- 因素
- 延迟, 丢包
- 谁会遇到
- 特定地点/分线, 全服
- 何时出现
- 人多的时候
- 负责方
- 主责 研发团队·服务器开发 · 配合 运维团队·系统运维
- 研发团队要做的事
- 按距离、重要程度降低更新频率（近处的敌人每个 tick 更新，远处的人每秒几次）；给发往每个人的数据量设上限，从重要的开始填；把多条更新合并到一个包里；限制显示人数。
- 运维团队要做的事
- 把每台服务器的发送带宽、每秒包数与网卡、实例的网络上限对比并告警；大型活动前确认余量。
- 数值参考
- 1,000 人 × 1,000 人 × 20 tick = 每秒 2,000 万条。每条 40 字节的话，全服约 6.4 Gbps，每个接收者约 6.4 Mbps。把可见人数限制在 150 人，全服约 1 Gbps，每人约 1 Mbps。
- 监控图上
- 随人数/负载上升 · 服务器发送包数/字节数、聚集在一处的人数
- 查看位置
- 把 sar -n DEV 1 的 txpck/s、txkB/s（服务器网卡每秒发送的包数、KB）和人数曲线一起看。云实例看 ethtool -S 中的超限计数器（AWS ENA 为 bw_out_allowance_exceeded、pps_allowance_exceeded）
- 确认依据
- 聚集人数增加时，发送包数、字节数比人数增长得更陡（接近平方），从触及上限的时刻起，超限计数器或发送丢弃增加
- 排除依据
- 发送量不变而只有 tick 耗时增加，看视野计算或游戏逻辑
- 确认手段
- 运维工具即可确认（无需游戏代码）
- 真实案例
- CCP Games 2014: EVE Online HED-GP 大规模舰队战中的服务器过载
出处
- HED-GP Technical Retrospective: What a HED-ache CCP Games
n 个人的一次操作要让 n 个人都看到，这种 O(n²) 传输是大规模舰队战无法回避的瓶颈 - Actor Priority in Unreal Engine Epic Games
连接带宽饱和时，按每个 Actor 的优先级（距离、视线、距上次发送的时间）排序，先把带宽分给重要的 - Detailed Actor Replication Flow in Unreal Engine Epic Games
用 NetUpdateFrequency 设定每个 Actor 的更新频率，按优先级顺序发送，连接饱和时剩下的推到下一个 tick - sar(1) — Linux manual page sysstat
sar -n DEV 的 rxpck/s、txpck/s（每秒接收、发送的包数），rxkB/s、txkB/s（每秒接收、发送的 KB） - Monitor network performance for ENA settings on your EC2 instance AWS
因 bw_out_allowance_exceeded（超出发送带宽上限）、pps_allowance_exceeded（超出 PPS 上限）而排队或被丢弃的包数
相关原因
同一层：L9 服务器游戏进程
其他层中同样导致“操作延迟”的原因
查看含图示和实验的原卡片