[情報] 月付 12 美金伺服器能扛多少人？
一、一台機器、三件東西全塞進去
Arjay 本來想用 AWS，帳號一堆鳥事之後改租 DigitalOcean 的 Basic Droplet：月付 12 美金、1 顆共享 vCPU、2 GB RAM、50 GB SSD，系統是 Ubuntu 24.04。
流量進來先過 Nginx（反向代理），再丟給 Node.js 後端，資料放 Postgres。三個都在同一台。沒有 Redis、沒有 CDN、沒有外面託管的資料庫、沒有自動擴展、沒有 Docker、沒有 Kubernetes——刻意用「有人會真的這樣上線」的極簡架構。
二、應用不是 Hello World
他做了一個迷你社群：讀 feed、開單篇、按讚、發文（幾個 GET／POST）。資料庫先灌好 5 萬用戶、50 萬貼文、兩百多萬讚，約 360 MB，有該有的 index，Postgres 也依記憶體調過——不是故意做爛來衝戲劇數字。
三、「使用者」是什麼？用 k6 模擬真人
k6 是產生虛擬使用者的壓測工具。每個虛擬使用者會：讀 feed → 等 3–7 秒 → 開貼文 → 再等 → 15% 機率按讚、2% 機率發文 → 再等幾秒 → 迴圈。平均一圈約 20 秒、兩次多一點請求，所以一個「同時活躍的人」大概只有 0.1 req/s。
重點：不是同一毫秒打 2,500 發；是 2,500 個人各自在逛。每個人有自己的帳號跟 JWT，不是共用同一個身分。
四、壓測機跟被測機分開
流量產生器若跟被測應用同機，會吃掉你要量的 CPU／RAM，實驗就髒了。他另租一台較大的 droplet（4 vCPU／8 GB），整個實驗只開約四小時，費用不到一美金；兩台同在紐約機房，RTT 不到 1 ms，量到的幾乎是應用本身，不是跨網延遲。
五、過關標準先講清楚
- p95 延遲 < 500 ms（95% 請求在半秒內做完）
- p99 延遲 < 1 s
- 錯誤率 < 1%
只回 200 但每頁等 30 秒，這種「撐住了」沒人要用。
六、基準結果：大約 2,500 同時活躍
- 1,000 人：約 83 req/s，中位數 ~5 ms、p95 ~19 ms、p99 ~50 ms——伺服器幾乎無感。
- 2,000 人：約 166 req/s，中位數還好（~6 ms），但 p95 跳到 161 ms、p99 到 276 ms——尾巴先壞。
- 4,000 人：直接炸，中位數 2.7 s、p95 4.5 s、p99 近 13 s。
- 來回試：3,000 掛、2,750 p99 不過、約 2,500 連續三輪 PASS（p50 ~11 ms、p95 ~288 ms、p99 ~775 ms、0 錯誤，每輪約 9 萬多請求）。
記得：這是「同一瞬間在用」的人，不是註冊數或日活。2,500 concurrent 換算成日活，可能是好幾萬，看流量尖峰怎麼長。
七、到底是什麼壞掉？
不是 RAM（才用約一半、沒有 swap）、不是 Postgres（活躍查詢很少）、不是磁碟（幾乎全在記憶體、cache hit 極高）、不是網路（遠低於 1 Gbit）。
是 CPU。 2.5k 約 80%、3k 進 90%、4k 接近 99%。請求進來比 CPU 做完還快，佇列越堆越長，延遲就爆炸。共享 CPU 的 steal 大多只有 0–2%，這次可忽略。
八、優化一：在 Node 裡快取 feed
幾千個人其實在讀「同一份」公開 feed，卻每次都打到 Postgres 重組 JSON。他在 Node 裡加約 1 秒的記憶體快取，miss 時用 single-flight 讓同時間的請求共用一次查詢；發文會清掉快取。沒有 Redis、沒有多一台機器。
效果：同時活躍上限從約 2,500 → 4,000。同樣 4,000 人，p95 從 4.5 秒掉到約 260 ms。
九、優化二：快取再往前推到 Nginx
每個請求還是要進 Node。Nginx 自己也會做 proxy cache——資料再靠近一點使用者。觀念是：資料庫最遠，再來是 app 記憶體、API gateway／Nginx、CDN、最後是使用者裝置。
單點狂打 GET /feed 的原始上限約 280 req/s → Node cache 約 1,200 → Nginx cache 超過 10,000（壓測機先爆）。換回真人行為模型：4,000、5,000 都過，大約 5,200 踩到門檻（p95 ~160 ms、p99 ~474 ms、0 錯誤）。
十、所以答案是多少？
看你的請求在幹嘛。每發都在生 AI 圖、轉碼、跑超重查詢——可能只剩兩位數。讀多、高度可快取——一台便宜機器衝到幾千同時活躍並不神祕。
想自己測：先看真實使用者怎麼打 API，用 k6 建成虛擬使用者，依自己的失敗門檻一路加流量。多數 coding agent 也寫得動 k6 script，重點是你要先定義「壞掉」長什麼樣子。
十一、看完可以帶走的
- 先講清楚過關門檻（p95／p99／錯誤率），再談「能撐多少人」。
- 中位數好看時，先盯尾巴；系統常是尾巴先壞。
- 便宜共享 CPU 這次不是兇手，兇手是算力跟不上。
- 低垂的果實常常是「重複算同一份結果」——先快取、再談加機器。
- 快取越靠近使用者越省，但也越難除錯；發文／按讚要記得失效策略。
※ 來源：YouTube／Arjay McCandless《How Many Users Can a $12 Server Handle?》（13:18，2026-09-25）。非官方圖文整理，數字以影片口述與畫面為準。