共用方式為

最佳化程式碼和基礎架構的架構策略

適用於此 Azure Well-Architected 架構效能效率檢查清單建議：

體育：07 優化程式代碼和基礎結構。 使用高效能的程式碼，並確保它將責任卸載給平台。 僅將程式碼和基礎架構用於其核心目的，並且僅在必要時使用。

本指南說明最佳化程式碼和基礎結構效能的建議。 若要最佳化程式碼和基礎結構，您應該僅將元件用於其核心目的，並且僅在必要時使用。 當您過度使用程式碼和基礎設施時，會產生不必要的資源消耗、瓶頸和緩慢的回應。 為了彌補這些低效率，您必須新增更多資源來完成相同的任務。

定義

術語 Definition
Concurrency 當多個任務或流程同時執行，但不一定同時執行時。
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 架構、執行緒模型和多核心處理器。 當您平行執行程式碼時，效能會改善，因為工作負載會分散在多個核心上。

使用並行。 並發性是系統運行多個任務或進程的能力。 並發使得程式的不同部分能夠獨立地進行，從而提高整體效能。 您可以使用多執行緒等技術來實作並行，其中多個執行緒在單一進程中同時執行。 您也可以使用非同步程式設計，其中會同時觸發作業。

  • 非同步程式設計：非同步程式設計是一種在不阻塞主執行緒的情況下觸發任務的方法。 非同步程式設計可讓程式在等待長時間執行的作業完成時觸發作業。 透過非同步編程，程式可以啟動多個任務並等待它們非同步完成。 該程序不必等待每項任務完成即可繼續下一個任務。

    有許多非同步程式設計技術和模式，具體取決於程式語言和平台。 一種常見的方法是在 C# 等語言中使用非同步關鍵字和結構，例如 async 和 await。 使用這些關鍵字，您可以定義非同步方法。 對於 HTTP 流量，請考慮使用 非同步 Request-Reply 模式。

    許多框架和函式庫都提供了對非同步程式設計的內建支援。 例如，在 .NET 平臺中，您可以使用非 同步模式 和非同步模式等模式來實作非同步作業 Task-BasedEvent-Based 非同步模式。 非同步程式設計的具體實作因程式語言、平台和應用程式的要求而異。

  • 佇列：佇列是位於工作負載的請求元件 （生產者） 和處理元件 （取用者） 之間的儲存緩衝區。 單一佇列可以有多個取用者。 隨著任務的增加，您應該擴展消費者以滿足需求。 生產者將任務放在佇列中。 佇列會儲存工作，直到取用者有容量為止。 佇列通常是將工作移交給需求高峰的處理服務的最佳方式。 如需詳細資訊，請參閱 Queue-Based 負載平準模式 和 儲存體佇列和服務匯流排佇列。

使用連線集區

連線集區是重複使用已建立的資料庫連線的做法，而不是為每個請求建立新的連線。 建立與資料庫的連線可能會很昂貴。 您必須建立與遠端資料庫伺服器的已驗證網路連線。 資料庫連線對於經常開啟新連線的應用程式來說尤其昂貴。 連線集區會重複使用現有的連線，並消除為每一個要求開啟新連線的費用。 連線集區可減少連線延遲，並在伺服器上啟用高資料庫輸送量 （每秒交易數）。 您應該選擇可以處理比目前更多的連線的集區大小。 目標是讓連線集區快速處理新的傳入要求。

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

測試連線集區。 每個資料庫和應用程式平台對設定和使用集區的需求略有不同。 測試您的連線池，以確保它在負載下有效率地運作。

風險：連線集區可能會造成 集區碎片 並降低效能。

最佳化背景作業

許多應用程式都需要獨立於 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 分析器 來協助優化經常性路徑。

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

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

Azure App Service 具有分析器和記憶體傾印收集和分析功能。 App Service 自動修復功能 可以自動取得 .NET 和 Java 應用程式的記憶體傾印和設定檔追蹤。

使用並行和平行處理原則：不同的 Azure 服務提供並行的獨特支援，例如 Azure Cosmos DB、 Azure Functions 和 Blob 儲存體。 針對平行處理原則，服務 AKS 支援部署容器化應用程式，以改善平行處理。

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

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

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

效能效益檢查清單

請參閱一組完整的建議。

效能效益檢查清單

  • Last updated on