達成並維持效能
 防止系統在使用中以及發展時的效能降低。 |
|---|
開發不是一次性工作。 這是持續的過程。 隨著功能的變更，預期效能也會變更。 使用者模式和設定檔有所差異，即使是其他 Azure 架構完善支柱中的最佳化變更也是一樣。 任何變更都可能會讓工作負載資源變得緊張。
保護系統免於變更，使其不會出現效能目標倒退。 在開發程序中整合測試與監視。 使用實際負載來測試系統在生產環境中的效能，並在進入生產環境之前使用自動化測試來模擬該負載。 在這兩種情況下，您應該具備用於驗證的監視做法。
在整個開發生命週期，於不同的階段進行各種類型的測試。 在初始階段中，測試概念證明，以確定效能結果不會完全非預期。 隨著開發的進展，進行手動、低工作測試，以建立效能評定。 在建置階段，開始開發自動化例行效能測試，以評估測試方案中所定義的延遲、壓力層級、負載容量和其他特性。
監視必須是該工作不可或缺的一部分，而不是隔離的練習。 您可以看到系統和其資源一段時間的效能。 然後，您可以對其進行微調以將其價值最大化，並確保其持續符合效能標準。
請記住，效能目標會隨著時間而不同，以回應變更。 根據測試過和受監視的計量來更新效能模型。 清楚指出增加、減少或不會影響流程的效能。
請隨時準備好與商務利害關係人重新交涉以及重設預期。
範例案例
Contoso Event Solutions 提供一項產品，讓活動入口工作人員可以用來掃描行動裝置上的票證，並快速允許進入已獲授權者的票證場地。 系統提供完全離線模式，也可以作為雲端連線版本，以供擔心票證重複的場地使用。 離線模式非常高效能，但連線模式遺漏其效能目標。 開發小組最近已投資幾個開發週期來對其進行處理，而效能現在得到大幅改善並達到目標。 商務利害關係人希望擴大其客戶群，以盡快支援更大的場地。
測試開發環境中的效能
將效能測試正式化為品質關口，以核准或拒絕發行升級和最終部署到生產環境。
這些檢查點可確保部署的每個階段都先符合所需的效能標準，再繼續進行下一個作業。 檢查點有助於防止非預期的效能迴歸。 例如，如果效能明顯低於預期，則除非有所改善，否則您可能會封鎖發行。
Contoso 的挑戰
- 小組已投入相當長的時間和精力來達到應用程式連線版本的可接受效能，但目前沒有任何系統可防止迴歸。
- 他們計劃新增的下一個功能是讓場地選擇顯示出席者的照片，以及掃描以取得其他驗證。 額外的相片查閱和下載可能會讓程序變慢。
- 如果沒有正式程序，則連線和離線版本的效能可能會受到其他功能的負面影響，而且可能會低於其目標。
套用方法和結果
- 小組會將自動化效能測試整合至建置管線。 在建置管線中實作嚴格的效能型「執行/不執行」準則，小組可更確信新功能發行時不會具有效能迴歸。
- 小組很明智地實作此測試，因為其在建置的最新版本中攔截到錯誤。 掃描器設定為離線模式時，錯誤會強制應用程式嘗試連線至網際網路來下載影像，導致每次票證掃描時都會發生逾時。 使用自動化測試來攔截此錯誤，可讓小組在發行新版本之前修正錯誤。
透過可觀察性進行最佳化
設定可重複的程序來監視生產環境中的實際交易，以及針對您效能目標的偏差。 此外，在生產環境中使用綜合交易，以及設定效能迴歸的監視警示。
您想要深入瞭解處於無法透過測試所模擬的實際負載下的系統實際效能。 然後，您可以主動識別問題和改進領域，例如潛在瓶頸、未充分利用的資源和其他疑慮。
Contoso 的挑戰
- 在使用連線票證驗證的事件期間，會大量使用後端系統。
- 已有應用程式效能監視 (APM) 系統，但尚未用來監視生產交易的健康情況。
套用方法和結果
- 小組已決定採用更新過的程序，以更妥善地擷取健康情況計量：
- 他們會根據效能百分位數並針對效能極端值來設定警示。 沒有警示指出系統是在大部分票證掃描的可接受範圍內執行。
- 離線事件完成之後，會批次上傳票證掃描的遙測，而且這些計量也會經過程序，以尋找與可接受效能的偏差。
- 小組也會實作綜合交易測試，以增強其效能監視。 因為幾乎所有事件都是在週末和晚上進行，所以小組會在整個星期內使用綜合交易測試來產生更一致的效能基準。
智慧處理工作負載變更
解決隨著使用量增加、功能變更和一段時間的資料累積所導致的效能流失，以維持效能。 如果微調只帶來短期的好處，則請重設預期，並建立新的目標。
採用此方式，即可在降低發生對使用者體驗的負面影響超出可接受範圍的問題之前保留效能狀態。
變更目標會重設效能模型，而且您不會浪費時間來最佳化已達其容量的系統。
Contoso 的挑戰
- 銷售小組一直在積極將新的事件場地上線至系統。 生意很好。
- 工作負載監視系統已開始注意到效能預算隨著時間越來越長而越來越多，即使未引進新功能也是一樣。
- 如果沒有變更，則此軌跡可能會導致無法接受的效能迴歸，讓工作負載在事件發生時面臨中斷的風險。
套用方法和結果
- 小組意識到，隨著更多客戶上線，連線事件的資料查閱機制將會對許多查詢的資料執行非常大的掃描。
- 某個查詢最佳化有助於防止使用量增加而造成額外傷害。 接下來的幾個月，小組計劃將不同的事件分成不同的資料分割，以減少查詢掃描的需求。 這將支援持續擴增工作負載。
- 他們也意識到，可以移除舊事件中的票證資料，以進一步最佳化系統的成長。 搜尋舊事件並非票證驗證系統應該需要執行的動作，因此資料可以移至報告和歷史查閱專用的存放區。