優化程式碼和基礎結構的建議

適用于此 Azure Well-Architected Framework 效能效率檢查清單建議:

PE:07 優化程式碼和基礎結構。 使用效能不佳的程式碼,並確保其將責任卸載至平臺。 僅針對其核心用途使用程式碼和基礎結構,並在必要時才使用。

本指南說明優化程式碼和基礎結構效能的建議。 若要優化您的程式碼和基礎結構,您應該只針對其核心用途使用您的元件,並在必要時才使用。 當您過度使用程式碼和基礎結構時,它會建立不必要的資源耗用量、瓶頸和緩慢的回應。 若要補償這些效率不佳,您必須新增更多資源來完成相同的工作。

定義

詞彙 定義
並行 一次執行多個工作或進程,但不一定完全相同時。
CPU 架構 影響電腦運作方式的元件和原則。
資料壓縮 藉由將備援資料最小化來減少檔案大小的動作。
堆積 記憶體中用於執行時間記憶體配置的區域。
記憶體流失 當不再需要記憶體之後,工作負載無法釋放配置的記憶體時。
平行處理原則 同時執行多個工作或進程時。

主要設計策略

優化程式碼和基礎結構需要微調程式碼和支援基礎結構,以改善效能效率。 它需要快速執行工作的高效能程式碼,而且不會浪費資源。 它需要經過妥善設計的基礎結構,以避免不必要的複雜度。 工作負載應該使用平臺的固有功能。 這是一種方法,可協助確保程式碼和基礎結構主要用於其核心用途,且僅在必要時使用。

優化程式碼效能

若要將程式碼效能優化,請修改程式碼以減少資源使用量、將執行時間降到最低,以及增強效能。 您可以修改程式碼以改善軟體程式的效率與速度。 請勿遮罩暴力密碼破解的效能問題。 暴力密碼破解表示新增計算資源來補償程式碼效能,例如新增額外的容量,而不是解決來源。 您需要修正優化效能問題。 當您優化程式碼效能時,它有助於將系統資源的使用率最大化、改善回應時間、減少延遲,以及增強使用者體驗。

實作您的程式碼

檢測程式碼是指將程式碼片段或程式庫新增至在執行時間收集資料和監視程式碼效能的程式碼的做法。 程式碼檢測可讓開發人員收集重要計量的相關資訊,例如資源耗用量 (CPU、記憶體使用量) 和執行時間。 藉由檢測程式碼,開發人員可以深入瞭解程式碼熱路徑、識別效能瓶頸,並將程式碼優化以提升效能效率。

在理想的環境中,您應該在軟體發展生命週期初期進行程式碼分析。 您稍早攔截程式碼問題,修正程式碼的成本會比較便宜。 您想要盡可能自動化此程式碼分析。 使用動態和靜態程式碼分析工具來減少手動工作。 不過,請記住,此測試仍是生產環境的模擬。 生產環境可讓您清楚瞭解程式碼優化。

取捨:程式碼監視工具可能會增加成本。

識別經常性路徑

藉由檢測程式碼,您可以測量不同程式碼路徑的資源耗用量。 這些度量可協助您識別經常性路徑。 經常性路徑對效能和資源使用量有顯著的影響。 它們是需要高效能和低延遲之程式的重要或經常執行的區段。 若要識別程式碼熱路徑,請考慮下列步驟:

  • 分析執行時間資料:收集執行時間資料並加以分析,以識別耗用大量資源的程式碼區域,例如 CPU、記憶體或 I/O 作業。 尋找經常執行的模式或程式碼區段,或需要很長的時間才能完成。

  • 測量效能:流量分析工具或效能測試架構來測量不同程式碼路徑的執行時間和資源耗用量。 這有助於找出瓶頸和改善領域。

  • 考慮商務邏輯和使用者效果:根據應用程式功能或重要商務作業的相關性,評估不同程式碼路徑的重要性。 判斷哪些程式碼路徑對於為使用者提供價值或符合效能需求至關重要。

優化程式碼邏輯

優化程式碼邏輯是關於精簡程式碼的結構和設計,以使用較少的資源來執行工作。 改善的邏輯可減少不必要的作業。 其會以較少的資源耗用量來建立更快的執行速度。 您應該在可能會影響效能的程式碼路徑內移除任何不必要的作業。 排定優化熱路徑的優先順序,以查看最大的效能效率提升。 若要優化程式碼邏輯,請考慮下列策略:

  • 移除不必要的函式呼叫:檢閱您的程式碼,並識別對所需功能而言不重要的任何函式,而且可能會影響效能。 例如,如果函式調用執行稍早在程式碼中完成的驗證,您可以移除不必要的驗證函式呼叫。

  • 最小化記錄作業:記錄有助於偵錯和分析,但過多的記錄可能會影響效能。 評估每個記錄作業的需求,並移除對效能分析而言不重要的任何不必要的記錄呼叫。

  • 優化迴圈和條件:分析程式碼中的迴圈和條件,並識別任何可排除的不必要反復專案或條件。 簡化和優化這些結構可以改善程式碼的效能。 將迴圈內的函式呼叫最小化,並消除多餘的計算。 請考慮在迴圈外部移動計算,或使用迴圈取消註冊。

  • 減少不必要的資料處理:檢閱您的程式碼是否有任何不必要的資料處理作業,例如備援計算或轉換。 消除這些不必要的作業,以改善程式碼的效率。

  • 優化資料結構。 若要有效率地儲存和擷取資料,請選取適當的資料結構,例如陣列、連結清單、樹狀目錄和雜湊表。 選擇特定問題的最佳資料結構。 適當的資料結構可改善應用程式效能。

  • 將網路要求降到最低:如果您的程式碼牽涉到提出網路要求,請將要求數目降到最低,並優化其使用方式。 盡可能批次要求,並避免不必要的來回行程以改善效能。

  • 最小化配置:找出發生過多記憶體配置的區域。 藉由減少不必要的配置,並盡可能重複使用現有的資源,將程式碼優化。 藉由將配置降到最低,您可以改善記憶體效率與整體效能。 針對您的程式設計語言使用適當的記憶體管理和垃圾收集策略。

  • 減少資料結構大小:評估資料結構的大小,例如類別,並識別可能縮減的區域。 檢閱資料需求,並排除任何不必要的欄位或屬性。 選取適當的資料類型並有效率地封裝資料,以優化記憶體使用量。

  • 使用效能優化的 SDK 和程式庫。 使用原生 SDK 或效能優化的程式庫。 原生 SDK 的設計目的是要與平臺上或架構內的服務和資源互動。 例如,雲端原生 SDK 使用雲端服務資料平面比使用自訂 API 存取更好。 SDK 在處理網路要求和優化互動時會很擅長。 效能優化的程式庫,例如 Math.NET,包含效能優化的函式。 當您適當地套用函式時,可以改善工作負載的效能。

  • 跨領域實作:考慮跨領域實作的影響,例如中介軟體或權杖檢查,並評估它們是否對效能造成負面影響。

檢閱您正在使用之程式設計語言的特定效能建議。 根據這些建議評估您的程式碼,以找出改善的區域。

取捨

  • 優化程式碼和熱路徑需要開發人員在識別程式碼效率不佳方面具有專長,而且可能對於其他工作需要高度技能的個人。
  • SDK 提供便利性,並消除與 API 互動的複雜性。 但是 SDK 可能會限制自訂程式碼的控制項和自訂選項。

優化記憶體管理

優化記憶體管理牽涉到精簡工作負載使用、配置及釋放記憶體資源的方式,以改善效率。 適當的記憶體管理可改善程式碼效能,因為它可降低記憶體作業的額外負荷。 有效率的記憶體使用量可減少延遲、防止系統變慢或當機,並將計算工作的輸送量最大化。 請考慮下列策略來優化記憶體管理。

偵錯記憶體問題。 記憶體傾印是應用程式記憶體快照集。 他們會在特定時間點擷取應用程式的記憶體狀態。 記憶體傾印可讓您回溯分析記憶體相關問題。 根據您嘗試診斷的問題本質和可用的資源,選取適當的記憶體傾印類型。 您應該使用縮排傾印進行例行偵錯,以及針對複雜、重大問題的完整傾印。 此策略提供資源使用量與診斷功能之間的平衡。 許多程式碼裝載服務都支援記憶體偵錯。 您應該偏好支援記憶體分析的服務,而非不支援的服務。 以下是偵錯記憶體問題的基本步驟:

  1. 擷取記憶體傾印:從設定機制開始,以在應用程式的執行時間期間擷取記憶體傾印。 您可以手動、自動觸發擷取,或在符合像是過度耗用記憶體 () 等特定條件時觸發。 某些雲端服務可能已經提供此程式。

  2. 分析記憶體傾印:收集記憶體傾印之後,請加以分析。 許多工具可協助您檢查這些傾印,例如適用于 Windows 應用程式的 WinDbg 或 Unix 型系統的 GDB。

  3. 識別記憶體流失:專注于在分析期間識別記憶體流失。 當應用程式佈建記憶體但不再需要記憶體時無法釋放記憶體時,就會發生記憶體流失。 搜尋即使應該解除配置的物件或資料結構,仍會保留在記憶體中。

  4. 修正並測試:識別有問題的程式碼時,請專注于解決記憶體問題。 解決方案可能涉及正確釋放記憶體、優化資料結構,或重新評估記憶體管理做法。 確認您的解決方案經過嚴格的測試,以確保其效力。

  5. 逐一查看並監視:記憶體管理是連續的程式。 定期監視應用程式的記憶體使用量,並保存在生產環境中收集記憶體傾印。 定期重新流覽分析和優化階段,以確保記憶體問題不會隨著後續的程式碼修改而重新出現。

藉由將記憶體傾印分析併入軟體發展生命週期,您可以放大應用程式的可靠性與效率。 這有助於降低生產環境中記憶體相關問題的可能性。

減少記憶體配置。 將記憶體配置降到最低,以減少程式碼的整體記憶體使用量。 您的工作負載可以有效率地利用可用的記憶體。 垃圾收集行程不需要回收未使用的記憶體,而且可減少垃圾收集週期的頻率和持續時間。 記憶體配置的成本可能很高,特別是如果您經常執行記憶體配置。 最小化記憶體配置,讓程式碼可以快速且有效率地執行。

快取會儲存接近處理器的經常存取資料,以改善效能。 當您將記憶體配置降至最低時,快取空間的競爭較少,因此您可以有效地利用快取。 大量記憶體配置可能會降低應用程式效能並產生錯誤。 將記憶體配置最小化的其他方式包括:

  • 區域變數:使用區域變數,而不是全域變數,將記憶體耗用量降到最低。

  • 延遲初始化:實作延遲初始化,以延遲建立物件或資源,直到需要它們為止。

  • 緩衝區:有效地管理緩衝區,以避免配置大型記憶體緩衝區。

  • 物件共用:請考慮物件共用來重複使用大型物件,而不是配置和解除配置它們。

如需詳細資訊,請參閱 減少記憶體配置Windows 系統上的大型物件堆積

使用並行和平行處理原則

使用並行和平行處理原則牽涉到同時或以重迭的方式執行多個工作或進程,以有效率地使用運算資源。 這些技術會增加整體輸送量,以及工作負載可以處理的工作數目。 當您同時或平行執行工作時,它會減少應用程式的執行時間,並減少延遲並增加回應時間。 並行和平行處理原則可讓您有效率地利用運算資源,例如 CPU 核心或分散式系統。 並行和平行處理原則可有效地將工作負載分散在運算資源之間。

使用平行處理原則。 平行處理原則是系統在多個運算資源上同時觸發多個工作或進程的能力。 平行處理原則會將工作負載分成較小的工作,以平行方式執行。 您可以使用多重處理或分散式運算等技術來達成平行處理原則。 將工作分散到多核心處理器,以優化工作負載管理。 將程式碼優化,以利用 CPU 架構、執行緒模型和多核心處理器。 當您平行執行程式碼時,效能會改善,因為工作負載會分散到多個核心。

使用並行。 並行是系統執行多個工作或進程的能力。 並行可讓程式的不同部分獨立進行進度,進而改善整體效能。 您可以使用多執行緒等技術來實作平行存取,其中多個執行緒會在單一進程內同時執行。 您也可以使用非同步程式設計,其中會同時觸發工作。

  • 非同步程式設計:非同步程式設計是觸發工作而不封鎖主執行緒的方法。 非同步程式設計可讓程式在等候長時間執行的作業完成時觸發工作。 透過非同步程式設計,程式可以起始多個工作,並等候它們以非同步方式完成。 程式不需要等待每個工作完成,再繼續進行下一個工作。

    根據程式設計語言和平臺而定,有許多非同步程式設計技術和模式。 其中一個常見的方法是使用非同步關鍵字和建構,例如 和 await ,以 async C# 等語言。 透過這些關鍵字,您可以定義非同步方法。 針對 HTTP 流量,請考慮使用 非同步 Request-Reply 模式

    許多架構和程式庫都提供非同步程式設計的內建支援。 例如,在 .NET 平臺中,您可以使用工作 架構非同步模式事件架構非同步模式等模式來實作非同步作業。 非同步程式設計的特定實作會根據應用程式的程式設計語言、平臺和需求而有所不同。

  • 佇列:佇列是位於要求元件 (產生者) 與工作負載 (取用者) 之間的儲存體緩衝區。 單一佇列可以有多個取用者。 隨著工作增加,您應該調整取用者以符合需求。 產生者會將工作放在佇列中。 佇列會儲存工作,直到取用者具有容量為止。 佇列通常是將工作交出給處理服務的最佳方式,其體驗需求尖峰。 如需詳細資訊,請參閱 佇列型負載撫平模式 和服務 匯流排佇列

使用連接共用

連線共用是重複使用已建立的資料庫連結,而不是為每個要求建立新的連線。 建立資料庫連線的成本可能很高。 您必須建立與遠端資料庫伺服器的已驗證網路連線。 對於經常開啟新連線的應用程式而言,資料庫連線特別昂貴。 連線共用會重複使用現有的連線,並免除為每個要求開啟新連線的費用。 連線共用可減少連線延遲,並在伺服器上每秒) 啟用高資料庫輸送量 (交易。 您應該選擇可處理比您目前擁有更多的連線的集區大小。 目標是讓連線集區快速處理新的傳入要求。

瞭解連線共用限制。 某些服務會限制網路連線的數目。 當您超過此限制時,連線可能會變慢或終止。 您可以使用連線共用在啟動時建立一組固定的連線,然後維護這些連線。 在許多情況下,預設集區大小可能只包含幾個在基本測試案例中快速執行的連線。 您的應用程式可能會耗盡規模下的預設集區大小,並建立瓶頸。 您應該建立集區大小,以對應至每個應用程式實例上支援的並行交易數目。

測試連線集區。 每個資料庫和應用程式平臺對於設定和使用集區的需求稍有不同。 測試您的連線集區,以確保其可在負載下有效率地運作。

風險:連線共用可以建立 集區片段 並降低效能。

優化背景工作

許多應用程式都需要獨立于 UI 執行的背景工作。 應用程式可以啟動作業,並繼續處理使用者的互動式要求。 背景作業的範例包括批次作業、處理器密集的工作,以及長時間執行的進程,例如工作流程。 背景工作不應該封鎖應用程式,或在系統負載不足時造成延遲作業所造成的不一致。 若要改善效能,您可以調整裝載背景工作的計算實例。 如需詳細資訊,請參閱背景作業和調整和效能考慮

優化基礎結構效能

優化基礎結構效能表示增強和調整基礎結構元素,以確保尖峰作業和最適合工作負載的資源使用。 藉由微調基礎結構,您可以將浪費降到最低、減少延遲,並使用可用的資源來達成更多目標。 它可確保工作負載以可靠且快速方式執行,進而改善使用者體驗和節省成本。 若要將基礎結構效能優化,請考慮下列策略:

新增使用限制。 您可以在某些工作負載元件上實作使用限制。 例如,若要移除不穩定的 Pod,您可以在 Azure Kubernetes Service (AKS) 中定義 Pod CPU 和記憶體限制。 若要將效能優化,您可以在 java 虛擬機器中定義記憶體限制, (VM)

簡化基礎結構。 簡化您的工作負載,以減少互動、相依性和相容性問題的可能性。 當您簡化工作負載時,可將記憶體的資源使用率、處理能力和儲存體優化。

降低負載。 若要減少工作負載負載,請將應用程式上的需求降到最低,並讓資源能夠執行其主要工作。 例如,在程式碼或個別計算實例上執行安全性解決方案是常見的做法。 相反地,Web 服務器應提供 HTTP 要求。 Web 應用程式防火牆和閘道資源可以處理安全性檢查。 下列策略可協助減少工作負載的負載:

  • 最終一致性:採用最終一致性模型,藉由允許資料稍有日期來增強效能。 最終一致性可減少固定資料更新的 CPU 週期和網路頻寬的立即需求。

  • 委派工作:將伺服器工作委派給用戶端或媒介,例如搜尋索引和快取。 委派排序資料、篩選資料或轉譯檢視等工作。 當您卸載這些工作時,您會減少伺服器上的工作負載,並改善效能。

優化網路。 若要將工作負載網路優化以達到效能,請設定並微調網路基礎結構。 請確定工作負載可以在最高效率層級運作。

  • 網路通訊協定:升級至新式通訊協定,例如 HTTP/2,可讓多個要求透過單一連線傳送。 新式通訊協定可減少建立新連線的額外負荷。

    取捨:新式通訊協定可能會排除較舊的用戶端。

  • 網路聊天:一起批次網路要求以減少要求數目。 不要提出多個小型要求,而是將它們合併成較大的要求,以減少網路負荷。

  • 資料庫查詢:確定資料庫查詢只擷取必要的資訊。 避免擷取大量的不必要的資料,這可能會導致網路流量增加,且效能變慢。

  • 靜態資料:利用內容傳遞網路來快取接近使用者的經常存取靜態內容。 當您快取資料時,它不需要經過長距離的移動。 快取可改善回應時間並減少網路流量。

  • 記錄收集:僅收集並保留支援需求所需的記錄資料。 設定資料收集規則並實作設計考慮,以優化 Log Analytics 成本。

  • 資料壓縮:壓縮並組合 HTTP 內容檔案資料 ,以允許用戶端和伺服器之間的快速傳輸。 壓縮會壓縮頁面或 API 傳回的資料,並傳送回瀏覽器或用戶端應用程式。 壓縮會將網路流量優化,以加速應用程式通訊。

    取捨:壓縮會新增伺服器端和用戶端處理。 應用程式必須壓縮、傳送和解壓縮資料。 多播通訊或多位收件者的通訊可能會產生解壓縮額外負荷。 您必須在實作資料壓縮之前和之後測試及測量效能變化,以判斷它是否適合您的工作負載。 如需詳細資訊,請參閱 ASP.NET Core 中的回應壓縮

Azure 設施

檢測程式碼:Azure 監視器 Application Insights 支援自動檢測 (自動結構) 和手動檢測應用程式程式碼。 自動結構可啟用遙測收集,而不需觸碰應用程式的程式碼。 手動檢測需要程式碼變更,才能實作 Application Insights 或 OpenTelemetry API。 您可以使用 Application Insights Profiler 來協助優化熱路徑。

優化程式碼邏輯:Azure 提供 SDK 和程式庫,供各種程式設計語言與 Azure 服務互動。 使用 SDK 來簡化應用程式與 Azure 資源之間的互動。 SDK 提供與 Azure 服務的最佳互動,以減少延遲並提升效率。

優化記憶體管理:使用 Application Insights 的智慧偵測功能 來分析記憶體耗用量,並協助識別和解決記憶體流失。

Azure App 服務具有分析工具和記憶體傾印收集和分析功能。 App Service自動調整功能可以自動擷取 .NET 和 JAVA 應用程式的記憶體傾印和設定檔追蹤。

使用並行和平行處理原則:不同的 Azure 服務可為並行提供獨特的支援,例如Azure Cosmos DBAzure FunctionsBlob 儲存體。 針對平行處理原則,服務 AKS 支援部署容器化應用程式,以改善平行處理。

Azure Batch是雲端式作業排程服務,可讓您用來啟用平行和高效能運算,而不需要進行基礎結構設定。 如需詳細資訊,請參閱 背景工作

優化基礎結構效能:實作Azure Resource Manager範本,以使用程式碼來定義和部署基礎結構。 使用這些範本來實作有效率、可重複且一致的資源部署。 Azure 原則提供治理功能,以確保資源部署遵守組織最佳做法和標準。

針對非同步程式設計,請使用可調整的佇列服務,例如Azure 佇列儲存體Azure 服務匯流排,以利非同步程式設計。 您可以將工作排入佇列,並獨立處理它們。 為了支援非同步作業,Azure Marketplace提供可與 Azure 服務整合的協力廠商佇列和工具。

效能效率檢查清單

請參閱一組完整的建議。