雲端應用程式的效能測試和反模式

效能反模式，就像設計模式一樣，是組織內常見的有缺陷程序和實作。這些是應用程式承受壓力時，可能會導致延展性問題的常見做法。瞭解這些做法有助於簡化軟體從業者之間高層級概念的溝通，而檢閱程式代碼或診斷效能問題時，反模式的知識可能會很有説明。

以下是常見的案例：應用程式在效能測試期間表現良好。它已發行至生產環境，並開始處理實際工作負載。此時，它會開始執行效能不佳—拒絕使用者要求、停滯或擲回例外狀況。然後開發小組會面臨兩個問題：

第一個問題的答案很簡單。很難在測試環境中模擬實際使用者，以及其行為模式和他們可能執行的工作量。了解系統在負載下運作方式的唯一完全確定方式，就是在生產環境中觀察它。為了清楚起義，我們不建議您略過效能測試。效能測試對於取得基準效能計量至關重要。但是，您必須準備好在即時系統中出現效能問題並加以修正。

第二個問題的解答，如何修正問題，較不直接。任何數目的因素都可能會造成，有時問題只會在特定情況下顯示。檢測和記錄是尋找根本原因的關鍵，但您也必須知道要尋找什麼。

根據我們與 Microsoft Azure 客戶的參與，我們已找出客戶在生產環境中看到的一些最常見的效能問題。針對每個反模式，我們描述反模式通常發生的原因、反模式的癥狀，以及解決問題的技術。我們也提供範例程式代碼，說明反模式和建議的延展性解決方案。

當您閱讀描述時，其中一些反模式看起來可能很明顯，但它們的發生頻率會比您可能想像的要多。有時候應用程式會繼承在內部部署環境中運作的設計，但不會在雲端中進行調整。或者，應用程式可能從非常乾淨的設計開始，但隨著新功能的新增，其中一或多個反模式會逐漸蔓延。無論如何，本指南都會協助您識別並修正這些反模式。

反模式目錄

以下是我們識別的反模式清單：

Antipattern	描述
忙碌資料庫	卸除太多處理至數據存放區。
忙碌前端	將需要大量資源的工作移至背景線程。
Chatty I/O	持續傳送許多小型網路要求。
無關的擷取	擷取的數據超過所需的數據，導致不必要的 I/O。
不正確的具現化	重複建立和終結設計為要共用和重複使用的物件。
整合型持續性	針對具有非常不同使用模式的數據使用相同的數據存放區。
沒有快取	無法快取數據。
嘈雜的鄰居	單一租使用者會使用不成比例的資源數量。
重試 Storm	對伺服器重試失敗的要求太常。
同步 I/O	在 I/O 完成時封鎖呼叫線程。

如需效能微調的詳細資訊，請參閱效能微調分散式應用程式