한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

廣播量暴增 Broadcast fan-out (N×N)

原因 ID sp-broadcast · 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）

在含圖解與實驗的完整版中開啟卡片 →

把一個人的移動送給所有看得到他的人時，要送出的狀態更新數量會是聚集人數的平方。

為什麼 把一個人的變化傳送給所有看得到的人 → 於是 1,000 人互相看得到時，每個 tick 有 100 萬筆狀態更新 → 畫面上 傳送佇列與頻寬飽和，造成延遲與遺失（輸入延遲、快轉、瞬移）

症狀: 輸入延遲, 瞬移, 快轉
因素: 延遲, 遺失
誰會遇到: 特定地點／頻道, 整個伺服器
何時: 人潮湧入時
負責單位: 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）
遊戲開發團隊要做的事: 依距離與重要程度降低更新頻率（近處的敵人每個 tick 更新，遠處的人每秒幾次）；為送給每個人的資料量設上限，從重要的開始填入；把多筆狀態更新打包進一個封包；限制顯示人數上限。
基礎設施團隊要做的事: 將各伺服器的傳送頻寬與每秒封包數與 NIC、執行個體的網路上限比較並設警示；大型活動前確認餘裕。
數值參考: 1,000 人 × 1,000 人 × 20 tick = 每秒 2,000 萬筆。每筆 40 位元組時，整台伺服器約 6.4Gbps，每位接收者約 6.4Mbps。把可見人數限制在 150 人時，整體約 1Gbps，每人約 1Mbps。
圖表上: 隨人數／負載上升 · 伺服器傳送的封包數與位元組數、聚集在同一處的人數
查看位置: 把 sar -n DEV 1 的 txpck/s、txkB/s（伺服器 NIC 每秒送出的封包數、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 上限）：因此排入佇列或被丟棄的封包數

廣播量暴增 Broadcast fan-out (N×N)

出處

相關原因

同一層：L9 伺服器遊戲程式

同一症狀（輸入延遲）在其他層的原因