遊戲 Lag 白皮書 › L13 伺服器架構與維運
登入排隊上限與重新連線寬限不足 Login queue cap / no reconnect grace
原因 ID in-login-queue · 主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）, 基礎設施團隊（伺服器基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
上市或維護剛結束時連線湧入，登入排隊碰到上限就拒絕新的排隊，正在排隊的玩家只要短暫斷線就會失去位置，回到隊伍最後面。
為什麼 想連線的人比登入伺服器一次能接受的人數多，所以設排隊；排隊太長時，為了保護伺服器會拒絕新的排隊 → 於是 排隊越長等待時間越久，這段期間 Wi-Fi、行動網路只要短暫斷線就會失去排隊位置 → 畫面上 連不上／無限讀取、排隊中出現錯誤並關閉遊戲、又要從最後面重新排隊
- 症狀
- 連不上／無限讀取, 斷線
- 因素
- 停滯
- 誰會遇到
- 整個伺服器, 只有我
- 何時
- 剛登入／維護剛結束, 晚間尖峰時段
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）, 基礎設施團隊（伺服器基礎設施）
- 遊戲開發團隊要做的事
- 伺服器：把排隊上限配合登入伺服器實際能處理的量，排隊中斷線的玩家保留位置一段時間（重新連線寬限），顯示順位與預估等待時間，把排隊長度、拒絕數、排隊中斷線次數記為指標。用戶端：排隊中斷線時不關閉遊戲，自動重新連線回到原來的位置，重試間隔以指數退避加上抖動（jitter）打散。
- 基礎設施團隊要做的事
- 伺服器設備／OS：上市前以負載測試量出登入、大廳伺服器的處理上限，上市時準備好可隨時加上的備用設備，把排隊指標與連線嘗試數放在同一張圖表上看。
- 數值參考
- 2021 年 FINAL FANTASY XIV 資料片上市時，每個邏輯資料中心排隊人數超過 17,000 人就會拒絕新的排隊（Error 2002）。排隊中斷線時，大廳伺服器會等待數十秒～1 分鐘，在這段時間內重新連上就能從排隊中段接續。
- 圖表上
- 碰到上限後持平 · 登入排隊長度、因達上限而拒絕的數量、排隊中斷線次數
- 查看位置
- 把登入、大廳伺服器記錄的排隊長度、平均等待時間、因達上限而拒絕的數量、排隊中斷線次數，與連線嘗試數放在同一張圖表上看
- 符合的跡象
- 上市或維護剛結束時，排隊長度碰到上限而持平，同時拒絕數增加，排隊中斷線集中在 Wi-Fi、行動網路的玩家
- 不符合的跡象
- 排隊很短但登入很慢時，是 DB（db-login-storm）或作業系統連線等待佇列（so-backlog）的問題
- 確認方式
- 需要遊戲伺服器／用戶端的 log 與指標
- 深入了解
- 登入湧入讓 DB 變慢的情況在「登入暴增與 N+1 查詢」說明，作業系統的連線等待佇列滿出來的情況在「連線等待佇列（backlog）溢位」說明。本項談的是遊戲刻意設計的登入排隊在設計上的問題。排隊上限是保護登入伺服器的安全機制，無法拿掉。因為要及早拒絕超出的請求，才能持續處理還處理得了的請求。重點在於減少拒絕與斷線對玩家造成的損失；排隊越長，錯誤就越集中在 Wi-Fi、行動網路這類線路不穩定的玩家身上。
- 實際案例
- Square Enix 2021: FINAL FANTASY XIV 資料片上市的壅塞與登入排隊錯誤
出處
- Response to Congestion (as of Dec. 11) Square Enix
每個邏輯資料中心排隊人數超過 17,000 人時，為避免登入伺服器當機而拒絕新的排隊（Error 2002）；排隊中斷線時大廳伺服器等待數十秒～1 分鐘，期間重新連上就從排隊中段接續，超過就回到最後面 - Using load shedding to avoid overload Amazon Builders' Library
及早拒絕超出的請求、持續處理還能處理的請求的負載卸除（load shedding）
相關原因
同一層：L13 伺服器架構與維運
同一症狀（連不上／無限讀取）在其他層的原因
查看含圖解與實驗的完整版卡片