Benchmark
What？
Benchmark 是一種用來測試、評估或比較系統性能的標準化方法。簡單來說，它就像是一個「測速相機」，可以告訴你某個系統在特定條件下的表現如何，通常以數值形式呈現，例如延遲 (Latency)、吞吐量 (Throughput) 或資源使用率 (Resource Utilization)。
舉例來說，假設你正在開發一個需要處理大量資料的 API，你會想知道這個 API 在高並發請求下的效能如何，這時候就可以透過 Benchmark 來進行模擬測試，並依據結果進行優化。
Who？
主要使用 Benchmark 的對象包括但不限於以下人群：
- 後端工程師：用來檢測伺服器或 API 的效能。
- 資料庫管理員 (DBA)：測試查詢語句或索引對資料庫的影響。
- 運維工程師：評估基礎架構（如雲端伺服器、負載平衡器）的表現。
- 產品經理：需要了解產品效能是否達到預期指標。
受影響的範圍則可能涵蓋整個技術堆疊，例如應用程式層、資料庫層甚至網路層。
When？
Benchmark 通常會在以下情境中被使用：
- 系統上線前：驗證是否達到性能需求，例如支持每天 100 萬次請求。
- 升級硬體或軟體版本後：確保新版本沒有引入性能退化。
- 問題排查時：當系統變慢時，用 Benchmark 幫助找出瓶頸。
- 競品分析時：比較自家產品與其他解決方案的性能差異。
例如，如果你剛剛將某台伺服器從 8 核心升級到 16 核心，你可能會想知道處理速度是否真的提升了兩倍。
Where？
Benchmark 通常出現在以下架構部分：
- 應用程式層級 (Application Layer)：測試 API 回應時間或業務邏輯執行效率。
- 資料存取層級 (Data Access Layer)：針對資料庫查詢進行壓力測試。
- 網路層級 (Network Layer)：分析延遲與吞吐量。
- 基礎設施層級 (Infrastructure Layer)：例如虛擬機、容器或裸機伺服器的性能評估。
Why？
Benchmark 的主要目的是解決「未知」效能帶來的風險。具體而言：
- 驗證系統是否能滿足特定需求（功能性和非功能性）。
- 找出系統中的瓶頸並提供優化方向。
- 測量不同技術選型（例如 NoSQL vs SQL）的實際效果差異。
- 提供數據支持，幫助團隊做出更明智的決策。
舉例來說，如果你的網站有 Black Friday 活動，你可以利用 Benchmark 預先模擬高併發流量，避免活動當天因負載過高而崩潰。
How？
🛠️ 建立階段
建立 Benchmark 測試環境通常需要以下步驟：
- 定義目標和指標：
- 確定需要測量什麼（如 Latency 或 Throughput）。
- 設定可接受範圍，如「平均延遲不能超過 200ms」。
- 構建可重現環境：
- 使用工具，例如 Docker 或 Kubernetes，保證環境一致性。
- 設計工作負載模型：
- 模擬真實場景，例如每秒 X 個請求，每個請求大小為 Y KB 等等。
- 執行初步測試：
- 使用工具生成負載（如 Apache JMeter 或 Locust）。
- 優化配置並反覆迭代：
- 根據初步結果調整參數，例如增加記憶體分配或改良演算法。
🔍 查詢階段
查詢階段是分析 Benchmark 結果的核心，通常包含以下流程：
- 收集結果數據，包括但不限於：
- 平均延遲、90/95/99 百分位延遲值、錯誤率等指標。
- 可視化結果：
- 使用 Grafana 或其他工具繪製圖表，幫助理解趨勢和異常點。
- 比較基準線與目標值：
- 判斷是否符合最初設定的目標需求。例如，「平均延遲降至 150ms」這樣的一個 KPI 是否達成？
- 深入分析瓶頸位置並提出改進方案：
補充說明
📌 範例比較
假設我們比較兩套不同架構（A 和 B）在相同場景下的 Benchmark 結果：
| 指標 | 架構 A | 架構 B |
|---|---|---|
| 平均延遲 | 120ms | 150ms |
| 吞吐量 | 500 req/s | 450 req/s |
| 錯誤率 | 0% | 0% |
結論: 架構 A 的效能較佳，但如果開發成本更高，就需要權衡其他因素再做決策。
🧠 延伸／常見誤解
誤解一：「只有快就是好」
- 實際上，不同情境下需要考慮多維度。例如，高吞吐量可能伴隨著高延遲，那就不一定適合即時互動型應用程式。
誤解二：「所有結果都是真實環境」
- Benchmark 通常是模擬場景，未必完全等同於生產環境，所以建議將重要部分直接在生產環境中進行小規模驗證。
誤解三：「結果一次到位」
- 性能問題往往是反覆迭代改善才能找到最佳解，因此不要期待第一次就得到完美答案。