Wolves Crash — 承載 / 壓測報告

1. 這個數字是怎麼量的

• 在正式機上量：雲端主機 2 vCPU / 2 GB（東京）、資料庫 MySQL —— 跟線上服務同一台機器、同一份設定。 容量是機器的性質，拿開發機的數字對外承諾是不誠實的（同一份程式在開發機上明顯更好看）。
• 🔴 但不打線上服務：壓測的每一注都是真的會進錢包與注單的，打線上會污染營運數字。 作法是在同一台機器上另起一個獨立實例 + 獨立資料庫，量完整包移除；量測期間線上服務全程正常。
• 模擬真人：每位虛擬玩家每局下注，並在自己的目標倍率手動收手（不是自動收手）， 這樣量到的才是「手指按下去到畫面成交」的完整往返。
• 壓測程式跟伺服器跑在同一台機器（避開網路延遲，只量伺服器本身）—— 它自己也吃 CPU，所以這是偏保守的數字。

2. 為什麼「共享局」的容量要另外算

一般單人遊戲：送一個請求、算一次、回一次，容量就是「每秒能處理幾次」。
Wolves Crash 是全場玩同一局 —— 同一架飛機、同一個爆點，所以吃的是完全不同的三件事：

• 畫面同步：飛行中每 200 毫秒要對每一條連線送一次校正 → 700 人 ＝ 每秒 3,500 則。
• 開局瞬間的下注潮：8 秒的下注窗內，全場的扣款要處理完。
• 整局結算：爆炸後把全場的注單與派彩在一個交易裡寫完，不能寫一半。

所以判斷「撐不撐得住」要同時看四個延遲 —— 只看其中一個會得出錯誤結論。

3. 實測數據

合格線（超過就感覺得到）：下注確認 p99 ≤ 500ms、收手成交 p99 ≤ 150ms、畫面同步 p99 ≤ 300ms、 失敗率 0、無人被斷線。

到 1,000 人為止沒有任何一筆失敗、沒有人被斷線，但 1,000 人時三項延遲一起越線 （而且重跑的數字很不穩定，代表那台機器已經在邊緣）。所以認列 700 人為單房穩定容量。

資源用量（700 人在玩時）

• 記憶體：約 34 ~ 55 MB。
• CPU：尖峰約 84%（2 核 ＝ 200%），多數時間 10 ~ 30%。

4. 這一天怎麼從 400 人做到 700 人

每一步都是「先量出瓶頸在哪，再改」—— 前兩次憑經驗猜，兩次都猜錯。

🔴 玩家自己的收手回覆一直是當場立刻送的 —— 合批的只有「別人收手了」這種給全場看的通知。 收手是這款遊戲最關鍵的一秒，任何優化都不會拿它去換。

5. 連線洪峰是另一個數字

「同時在玩 700 人」跟「同一瞬間一起連進來 700 人」不是同一件事。 實測若讓幾百條連線在同一毫秒握手，作業系統的連線佇列會滿並直接拒絕 —— 那是連線洪峰的極限，不是算力的極限。

• 真實玩家是陸續進場的，不會在同一毫秒湧入。
• 真正會出現洪峰的是「伺服器重啟後全體重連」，而玩家端本來就有退避重連（每個人等的時間不一樣），會自然錯開。

6. 換算：可以接多少人

• 單房 700 人＝同一款遊戲、同一局、同時在玩的人數。
• 大廳與沒進房的人不佔這個額度 —— 沒進房就沒有畫面同步的成本。
• 多款遊戲各自獨立：每款一間房、各跑一條執行緒，互不搶資源；但共用同一個資料庫， 實際同時開幾款要重測，不能直接相乘。
• 再往上：先分房（同一款開多間房分流），不夠再加機器。 以 1,000 人時三項延遲一起越線來看，那台 2 核機器是整體到頂，不是單一環節的問題。

7. 這份數字的適用範圍

• 換機器、換資料庫、或改動伺服器之後都要重跑同一份壓測再重新認列，不能沿用舊數字。
• 本報告的數字全部來自同一支工具、同一台機器、同一組參數，可重現。