主執行緒封包處理瓶頸 Network processing on the main thread

原因 ID cg-net-mainthread · 主要負責 遊戲開發團隊（用戶端開發） · 協同遊戲開發團隊（伺服器開發）

每個畫格只處理固定數量的已接收封包時，一次湧入的封包會不斷延到下一個畫格。

為什麼 人多的地方每秒湧入數千筆更新 → 於是主執行緒碰到每畫格的處理量上限，讀不完 → 畫面上 其他人的動作越來越晚反映，而且一次湧入

症狀: 快轉, 輸入延遲
因素: 停滯, 延遲
誰會遇到: 特定地點／頻道, 只有我
何時: 人潮湧入時
負責單位: 主要負責 遊戲開發團隊（用戶端開發） · 協同遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 用戶端：接收與解析交給獨立執行緒，同一對象的舊位置更新合併後只套用最新的一筆。伺服器：人多的地方降低遠處角色的更新頻率，減少傳輸量。
數值參考: 未處理的封包一旦累積，只要幾秒就會落後 1 秒的份量。
圖表上: 隨人數／負載上升 · 未處理的接收封包數、從接收到套用的延遲
查看位置: 把用戶端每個畫格處理不完而剩下的封包數，以及封包從抵達到套用至遊戲的延遲記進 log，對照周圍人數查看
符合的跡象: 人多的地方剩餘封包數與套用延遲持續增加，同一時間 ping 與伺服器的傳送間隔正常
不符合的跡象: 沒有套用延遲、封包本身卻晚到時，問題在網路區段。畫格時間大幅上升時，是「大量角色同畫面的渲染負載」
確認方式: 需要遊戲伺服器／用戶端的 log 與指標

出處

Actor Priority in Unreal Engine Epic Games
頻寬不足時，依 actor 與觀看者的距離、距上次複製（replication）經過的時間排定優先順序，不會每次都複製全部 actor
Replication Graph in Unreal Engine Epic Games
連線人數與複製對象多的遊戲（MMORPG 等）要依位置分組、只傳送需要的對象，才能避免伺服器 CPU 瓶頸