遊戲 Lag 白皮書 › L9 伺服器遊戲程式
序列化與壓縮的成本 Serialization / compression cost
原因 ID sp-serialize · 主要負責 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
把要送出的資料轉成位元組並壓縮也要耗用 CPU，人多時這項成本會暴增。
為什麼 每筆狀態更新都要把結構轉成位元組並壓縮 → 於是 成本與人數的平方成正比增加 → 畫面上 傳送變慢，出現輸入延遲
- 症狀
- 輸入延遲
- 因素
- 停滯, 延遲
- 誰會遇到
- 特定地點／頻道
- 何時
- 人潮湧入時
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發）
- 遊戲開發團隊要做的事
- 把做好一次的封包重複用於多人、改用輕量格式。
- 圖表上
- 隨人數／負載上升 · 伺服器 CPU 使用率、產生封包的執行緒的 CPU
- 查看位置
- 用 perf top -p 看遊戲處理程序的 CPU 時間中，序列化、壓縮、加密函式（包含 zlib、LZ4、OpenSSL 等函式庫的函式）所占的比例，並比較人少與人多時的差異
- 符合的跡象
- 人越多，序列化、壓縮、加密函式的占比越大，產生封包的執行緒 CPU 最先飽和
- 不符合的跡象
- 這些函式的占比很小時，問題在視野計算或遊戲邏輯
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 深入了解
- 如果連線會加密封包（TLS、DTLS 等），加密與解密也要耗用 CPU。加密是每條連線分別進行，所以即使把做好一次的封包重複用於多人，加密成本仍與接收人數成正比。AES-GCM 這類對稱加密快到一個核心每秒能處理數 GB，平時占比很小，但速度會隨一次加密的單位（record）大小而有很大差異，像遊戲這樣小封包很多時，每位元組的成本就會變高。每次連線進行一次的交握（handshake）中，伺服器要用憑證金鑰簽章並計算金鑰交換（ECDHE）。一個核心每秒的簽章次數約 1,100 次（RSA 2048）到 1 萬 8 千次（ECDSA P-256），金鑰交換約 9 千次，登入湧入時會形成負擔。
出處
- Introduction to Iris in Unreal Engine Epic Games
把要複製（replication）的狀態保存為一份量化後的副本，減少昂貴的運算，並讓多條連線共用這份成果 - VALORANT's 128-Tick Servers Riot Games
每個畫格為每個用戶端比較複製變數、打包變更值的方式，需要四處讀取記憶體，速度慢，會耗用大量伺服器 CPU - How "expensive" is crypto anyway? Cloudflare
BoringSSL 量測：AES-128-GCM 每秒約 3.7GB（依 record 大小差異很大）；一個核心每秒可做 RSA 2048 簽章 1,120 次、ECDSA P-256 簽章 18,477 次、P-256 ECDHE 9,394 次；Cloudflare 邊緣伺服器上 TLS 函式庫使用的 CPU 約 1.8% - perf-top(1) — Linux manual page perf
依函式（symbol）即時顯示執行中處理程序（-p）的 CPU 使用占比
相關原因
同一層：L9 伺服器遊戲程式
同一症狀（輸入延遲）在其他層的原因
查看含圖解與實驗的完整版卡片