遊戲 Lag 白皮書 › 同步設計
依序往返過多的協定（chatty） Chatty protocol / sequential round trips
原因 ID sy-chatty · 主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）
在含圖解與實驗的完整版中開啟卡片 →
一次操作需要依序與伺服器往返好幾次時，ping 會乘上這個次數。
為什麼 開啟商店 → 請求清單 → 確認價格 → 購買 → 更新背包，每一步各自請求 → 於是 收到前一個請求的回應後才送出下一個請求 → 畫面上 ping 150ms 時買一次東西要將近 1 秒。載入特別久
- 症狀
- 輸入延遲, 連不上／無限讀取
- 因素
- 延遲
- 誰會遇到
- 只有特定功能, 只有我
- 何時
- 做特定動作時, 剛登入／維護剛結束
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）
- 遊戲開發團隊要做的事
- 伺服器：修改協定，把多個步驟合併成一次請求與回應（例：在購買回應中一併放入更新後的背包）。用戶端：預先取得需要的資料，採用不必等待結果的 UI。
- 數值參考
- 耗時 ≈ 往返次數 ×（ping + 伺服器處理 + tick 等待）。5 次的話，ping 150ms 時約 0.85～1 秒。
- 圖表上
- 一開始就一直偏高 · 各功能的完成時間、一次操作的往返次數
- 查看位置
- 在伺服器端的封包擷取（Wireshark）中，用測試帳號執行一次商店購買、登入之類的操作，計算期間請求與回應交替往返幾次及其間隔。有伺服器請求 log 的話，以 session ID 分組，查看請求數與每個請求的抵達、回應時間
- 符合的跡象
- 一次操作中，請求要等前一個回應後才依序往返多次，完成時間約為往返次數 × RTT，且 ping 越高的地區，玩家使用同一功能就越慢，大致成正比
- 不符合的跡象
- 往返只有一兩次、卻是某個回應花很久時，是伺服器處理或 DB 端的原因。與 ping 無關、所有玩家都一樣慢時，要查伺服器負載
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
出處
- Chatty I/O antipattern Microsoft Azure
小型 I/O 請求很多時，累積延遲會大幅降低回應性。建議把請求合併成更大、更少的批次
相關原因
同一層：同步設計
同一症狀（輸入延遲）在其他層的原因
查看含圖解與實驗的完整版卡片