硬體規格 (雙 CPU、128GB RAM、4TB SSD) 無法直接換算支援用戶數。真正的瓶頸取決於應用程式特性與實際負載模式。
| 瓶頸類型 | 症狀 | 硬體指標正常但... |
|---|---|---|
| 網路頻寬 | 用戶連線緩慢、逾時 | CPU 0.001%、記憶體充足，但 100Mbps 頻寬塞滿 |
| CPU 運算 | 回應時間飆升 | 記憶體、網路正常，但複雜運算佔滿所有核心 |
| 記憶體 | OOM、Swap 暴增 | CPU、網路正常，但記憶體洩漏或快取過大 |
| 磁碟 I/O | 查詢緩慢、IOPS 達上限 | CPU、記憶體正常，但隨機讀寫拖垮效能 |
| 資料庫鎖競爭 | 並發下降、死鎖 | 所有硬體指標正常，但邏輯鎖限制並發 |
| 應用程式架構 | 無法水平擴展 | 單點瓶頸 (Session、檔案鎖、全域鎖) |
Thread Group:
- Number of Threads: 100 (虛擬用戶)
- Ramp-Up Period: 60 秒 (逐步啟動)
- Loop Count: Forever / 指定次數
HTTP Request:
- Server: your-server.com
- Path: /api/login
- Method: POST
- Body: {"username":"user${__threadNum}","password":"pass"}
Listeners:
- Summary Report (統計)
- Response Time Graph (圖表)
- Aggregate Report (彙總)
| 策略 | 適用瓶頸 | 成本 |
|---|---|---|
| 垂直擴展 (升級硬體) | 單機資源不足 | 高、有上限 |
| 水平擴展 (增加節點) | CPU、網路、連線數 | 中、需無狀態設計 |
| 快取 (Redis/Memcached) | 資料庫讀取壓力 | 低、效果立竿見影 |
| 資料庫讀寫分離 | 資料庫寫入/讀取不平衡 | 中 |
| CDN 靜態資源 | 頻寬、延遲 | 低 |
| 非同步處理 (MQ) | 尖峰流量削峰 | 中、架構複雜度增加 |
結論：不要猜，要測。用壓力測試數據說話，才是專業的容量規劃態度。
