效能微調分散式應用程式
在此系列中，我們會逐步解說數個雲端應用程式案例，示範開發小組如何使用負載測試和計量來診斷效能問題。 這些文章是以開發範例應用程式時所執行的實際負載測試為基礎。 GitHub 上提供每個案例的程式碼。
案例：
什麼是效能？
效能經常以輸送量、回應時間和可用性來測量。 效能目標應以商務作業為基礎。 客戶對向工作可能比產生報告等作業工作更嚴格的需求。
定義服務等級目標 （SLO），以定義每個工作負載的效能目標。 您通常會將效能目標分成一組關鍵效能指標（KPI），例如：
- 特定要求的延遲或回應時間
- 每秒執行的要求數目
- 系統產生例外狀況的速率。
效能目標應明確包含目標負載。 此外，並非所有的使用者都會收到完全相同的效能層級，即使同時存取系統並執行相同的工作也一樣。 因此，SLO 應該以百分位數來框架。
的範例 SLO 可能是：「用戶端要求在 500 毫秒 @ P90 內有回應，最多載入 25 K 個要求/秒。」
效能微調分散式系統的挑戰
診斷分散式應用程式中的效能問題可能特別困難。 其中一些挑戰如下：
單一商務交易或作業通常涉及系統的多個元件。 很難取得單一作業的整體端對端檢視。
資源耗用量會分散到多個節點。 若要取得一致的檢視，您必須在一個地方匯總記錄和計量。
雲端提供彈性規模。 自動調整是處理負載尖峰的重要技術，但它也可以遮罩基礎問題。 此外，很難知道哪些元件需要調整和何時調整。
工作負載通常不會跨核心或執行緒進行調整。 請務必瞭解工作負載的需求，並探討更佳的優化大小。 某些大小提供受限的核心和停用的超執行緒，以改善單一核心導向和每個核心授權工作負載。
串聯失敗可能會導致根問題的上游失敗。 因此，問題的第一個訊號可能會出現在與根本原因不同的元件中。
一般最佳做法
表演調整既是藝術，也是一種科學，但它可以通過系統的方法更接近科學。 以下是一些最佳做法：
啟用遙測來收集計量。 檢測您的程式碼。 請遵循 監視 的最佳做法。 使用相互關聯的追蹤，以便檢視交易中的所有步驟。
監視 90/95/99 百分位數，而不僅僅是平均值。 平均值可以遮罩極端值。 計量的取樣率也很重要。 如果取樣率太低，它可以隱藏可能表示問題的尖峰或極端值。
一次攻擊一個瓶頸。 一次變更一個變數，以形成假設並加以測試。 移除一個瓶頸通常會發現另一個瓶頸，進一步上游或下游。
錯誤和重試可能會對效能造成很大影響。 如果您看到後端服務正在對系統進行節流，請相應放大或嘗試優化使用量（例如微調資料庫查詢）。
尋找常見的 效能反模式 。
尋找平行處理的機會。 瓶頸的兩個常見來源是訊息佇列和資料庫。 在這兩種情況下，分區化有助於。 如需詳細資訊，請參閱 水準、垂直和功能性資料分割 。 尋找可能表示讀取或寫入負載不平衡的經常性分割。
下一步
讀取效能微調案例