效能規劃建議
適用於此 Power Platform Well-Architected 性能效率檢查表建議：
| PE：02 | 進行效能規劃。 應在預測使用模式變更前完成效能規劃。 預測的變化包括季節性變化、產品更新、營銷活動、特殊事件或法規變化。 |
|---|
本指南介紹了有關效能和容量規劃的建議。 效能並不是突然發生的事情，您需要像任何其他需求一樣對其進行規劃。 容量規劃是指確定滿足工作負載效能目標所需資源的過程。 它涉及估計支援工作負載的效能要求（如存儲、輸送量和網路頻寬）所需的資源量。 容量規劃可確保工作負載有足夠的資源來處理預期的工作負載需求，而不會遇到效能下降或瓶頸。 它還有助於防止過度配置和不必要的成本。 缺乏效能和容量規劃可能會導致效能問題、資源瓶頸、成本增加、分配效率低下、可擴充性挑戰和不可預測的工作負載效能。
定義
| 詞彙 | 定義 |
|---|---|
| 容量規劃 | 預測工作負載滿足其效能目標所需的資源的過程。 |
| 功能要求 | 工作負載實現其預期目的所必須具備的特性和功能。 |
| 技術需求 | 滿足功能要求所需的代碼和基礎結構。 |
| 趨勢分析 | 歷史資料分析以預測未來需求。 |
關鍵設計原則
容量規劃是一個前瞻性過程，涉及根據預期的工作負載需求和模式做出決策。 其目標是最佳化連續負載和尖峰負載場景下的工作負載效能。 透過了解使用情況的變化 (例如季節性變化或產品發布)，您可以策略性地分配資源，防止高需求期間出現系統壓力。 這種主動策略可減少中斷並提高效能效率。 通過分析過去的使用趨勢和增長資料，您可以預測短期和長期需求。 您可以查明潛在的瓶頸和擴展問題，確保一致且高效的工作負載效能。
規劃效能
設計工作負載時要考慮效能，以將工作負載執行後的重構減到最少。 在效能方面，請考慮工作負載要求。 效能注意事項會影響工作負載的許多方面：
數據策略：您是否有需要連線的現有數據和數據存儲？ 您需要儲存多少資料？ 資料量會影響使用者存取的速度嗎？ 使用者將如何存取資料？
集成策略：您能否在不減慢系統速度的情況下進行即時集成？ 您可以在一定時間內進行批量集成嗎？ 您的資料在哪裡? 您是否需要內部部署資料閘道策略？
對話量：在構建 Copilot 時，瞭解消息或對話的目標量及其預期增長非常重要。 您的期望是否驗證了目標架構？ 規模呢？
數據建模：您是否需要簡化數據結構以加快查詢速度？
安全建模：您的安全規則是否適用於大量用戶和數據？ 有任何瓶頸嗎？
環境策略：您是否有用於性能測試的測試環境？ 和生產環境類似嗎？ 您是否為效能測試做好了預算？
開發：開發人員是否遵循性能最佳實踐？ 他們是否達到了特定的效能目標？ 使用者是否知道什麼是可能的，什麼是不可能的？
測試設計和方法：如何衡量性能？ 什麼足夠好，什麼不夠好？ 您是否使用真實的場景和資料進行測試？ 您是否正在測試當前和未來的需求？
使用者接受度和採用度：如何跟蹤性能？ 使用者的期望是否切合實際？
規劃您的資源
績效需要時間、金錢、精力和人員。 從項目開始就明智地分配資源。 例如，開發人員可能需要額外的時間來找到實現業務邏輯和最佳化代碼的有效方法。 您還需要一個測試環境和一個團隊來執行效能測試。
效能不是一次性的活動。 隨著工作負載使用情況的變化和平台的發展，您需要重新審視程式碼並繼續尋找最佳化效能的方法。
規劃資料遷移和集成
從先前系統遷移資料時，請仔細規劃遷移。 以下是一些可幫助您避免問題的提示：
瞭解要遷移的資料的業務需求。 遷移的資料不要超過使用者需要的資料。 例如，您可能不需要將 10 年的舊潛在客戶導入您的銷售系統。
考慮執行整合的時間和頻率。 避免在使用者與系統互動時運行資源密集型進程。 將繁重的進程安排在非高峰時段或使用異步處理。
設計整合時，請注意平台限制和最佳做法。
收集效能資料
收集工作負載利用率資料需要收集和分析有關工作負載如何使用資源及其執行方式的資訊。 應收集有關現有工作負載的歷史模式的資料以及新工作負載的預測度量值。 此過程有助於將業務目標轉換為技術要求，對於預測容量至關重要。 請考慮下列建議。
了解現有工作負載
了解現有工作負載以進行容量規劃涉及分析與工作負載如何利用資源相關的歷史資料。 它包含資源利用率、效能資料和工作負載模式等指標。 這種理解可確保有效的資源分配，將業務目標轉化為技術要求，並有助於識別潛在的瓶頸。
了解數據：查看可用的歷史數據，並瞭解其結構、格式和與容量規劃的相關性。 審查可能包括資源利用率指標、工作負載模式、效能指標和其他相關資料點。 了解商務程序和應用程式的重要性。 確定高峰使用時間、用戶負載、事務率和其他相關指標。
清理和預處理數據：通過刪除任何不一致、錯誤或異常值來準備數據以進行分析。 準備資料可能涉及資料清理技術，例如資料插補、缺失值的處理或規範化。
確定關鍵指標：確定與容量規劃相關的指標。 計量可以包括交易量、網路輸送量和回應時間。
識別瓶頸：測量輸送量和回覆時間，以識別隨著工作負載增長而可能成為瓶頸的系統特定元件。 使用返工和根本原因分析等程序探勘分析功能來識別端到端流程中的瓶頸。
可視化數據：創建可視化效果 (如圖表或繪圖)，以更好地了解歷史數據。 可視化可以説明您識別資料中的模式、趨勢和異常，讓您更清楚地瞭解工作負載行為。 使用程序探勘工具通過流程圖可視化資料，從而對流程進行深入分析。
瞭解新工作負載
了解新的工作負載以進行容量規劃是指在沒有歷史資料的情況下，預測未來任務的資源需求。 在沒有歷史資料的情況下預測新工作負載的未來需求可能具有挑戰性。 此程序可確保您在引入工作負載時有效地分配資源，並使分配與工作負載目標保持一致。
請考慮下列建議：
使用者研究：進行使用者研究以了解使用者如何處理當前工作負載，可以提供有關對新工作負載的潛在需求的寶貴見解。 研究可能涉及使用者訪談、調查或觀察執行現有工作負載的使用者。
專家判斷：具有行業經驗的主題專家或專業人員的意見可以説明您估計對新工作負載的需求。 他們的專業知識和見解可以為預測提供寶貴的建議。
試點專案或原型：小規模試點專案或原型可以説明您收集實時數據和反饋。 然後，您可以使用此資料來通知容量規劃流程並調整預測需求。
外部數據源：行業報告、市場研究或客戶調查等外部數據源可以提供其他資訊，用於估計新工作負載的需求。 這些來源可以提供有關客戶偏好、市場趨勢和潛在需求驅動因素的寶貴見解。
需求預測
預測需求涉及使用工作負載資料來預測服務或產品的未來需求。 容量規劃必須確保有效的資源分配、預測增長模式併為潛在的需求激增做好準備。 當您預測未來需求時，您可以使用資料來了解未來需求。 您將統計分析、趨勢分析或預測建模技術應用於您必須預測未來需求的資料。 這些方法考慮到歷史或預期的模式，並將其預測到未來，以提供對預期工作量需求的估計。 若要預測需求，請考慮以下策略。
考慮各種方案
作為效能規劃的一部分，您需要針對可能發生的不同方案進行規劃。 這種規劃應包括可預測的增長模式和意外的需求激增。 使用模式可能會增加或減少。 它們可以是有機的 (或多或少的使用者) 或無機的 (事件或安全事件)。 您需要在使用變更之前的關鍵時間進行規劃：
- 設計 (預測)
- 定期高峰 (上午 8:00 登入高峰)
- 啟動 (預測驗證)
- 商業模式變更
- 收購或合併
- 行銷發送
- 季節變更
- 功能啟動
- 定期
使用預測技術
預測服務或產品的未來需求涉及使用統計分析、趨勢分析和預測建模等技術。
下面概述了如何使用這些技術：
統計分析：統計方法可以幫助發現歷史數據中的模式和關聯。 您可以使用這些模式來預測未來需求。 您可以使用時間序列分析、回歸分析和移動平均等技術來識別資料中的趨勢、季節性和其他模式。
趨勢分析：趨勢分析涉及檢查歷史數據以確定一致的模式並將這些模式外推到未來。 例如，如果工作負載需求在過去一年中增加了 10%，則可以預測此趨勢將持續下去。 在分析一段時間內的歷史需求資料時，可以確定增長或減少趨勢。 利用這些趨勢作為預測未來需求的基礎。 趨勢分析還可以識別導致流量快速變化 (無機) 的一次性事件影響。 例如，功能發佈可能會持續增加 5% 的需求。 如果一年有四個主要版本，則應計劃每次增長 5%。
預測建模：預測建模是構建數學模型的過程，這些模型使用歷史數據和其他相關變數來預測未來需求。 您可以使用機器學習演算法、神經網路或決策樹等技術。 這些模型可以考慮多個因素和變數，以提供更準確的預測。
使預測與工作負載目標保持一致
使預測與工作負載目標保持一致涉及調整預測容量模型，以確保它們滿足給定工作負載的特定目標和需求。 此對齊可確保充分預配資源，從而防止利用率不足和潛在的工作負載過載。 例如，如果您的目標是支援每晚 100 萬次更新的集成，但當前資料顯示更新速度較慢，則需要調整系統。 與利益相關者交談以掌握工作負載的要求至關重要。 確保您的計劃與服務提供者的承諾（SLA）對齊。 此調整可確保您的容量滿足預期需求，並有助於找出系統中可能需要變更的區域。
確定資源需求
一個工作負載可以擁有許多資源，因此無法藉由觀察一個計量來確定資源需求。 您需要在資源級別測量容量才能獲得有意義的結果。 根據歷史資料、市場趨勢和業務預測估計資源的預期需求。 考慮事務數、併發用戶數或任何其他相關指標。
根據預測的需求，計算滿足該需求所需的資源。 考慮 API 請求容量、網路頻寬、儲存容量和人員等因素：
網路頻寬：評估支援預期流量級別所需的網路頻寬。 應同時包括入站和出站資料傳輸速率，以確保伺服器和客戶端之間的通信順暢高效。
存儲容量：估計工作負載在預測需求期間生成或處理的數據量。 考慮資料庫大小、檔案存儲要求以及特定於應用程式的任何其他資料存儲需求等因素。
API 請求：根據可用容量和服務保護限制評估 API 請求消耗量。 考慮資料的初始負載和潛在的使用高峰等因素。
人員：評估管理和維護基礎設施、處理客戶支援、執行系統維護和確保順利運營所需的人力資源。 考慮工作負載分佈、技能集和所需專業知識等因素。
了解資源限制
工作負載中的資源具有效能限制。 效能限制適用於每個服務中的功能。 您需要瞭解工作負載中資源的局限性，並將這些限制納入設計決策。 例如，您應該知道資源限制是否要求您更改設計方法或完全更改資源。
您還需要確定可達到的限制，這涉及確定工作負載的最大閾值或邊界。 這些限制通常適用於基礎架構 (運算、儲存體、網路)、應用程式 (同時連線、回應時間、可用性) 和服務 (每秒請求數)。 當容量規劃確定可達到的限制時，您需要在限制產生效能問題之前修改工作負載。 效能基線、持續監視和測試對於驗證限制和解決方案至關重要。
權衡：誤判容量規劃可能會導致資源過度預置或預置不足。 過度配置可能會導致更高的成本。 預配不足可能會導致效能不佳。 您可能還會遇到更高的誤報警報率，這可能會導致浪費時間調查不存在的效能問題。 嘗試找到適當的平衡。
Power Platform 簡易化
收集容量數據和預測需求： Azure Monitor 使你能夠從應用程式和基礎結構收集和分析遙測數據。 它支援監視各種 Azure 資源，包括虛擬機、容器和儲存帳戶。 主要工具包括 Application Insights 和 Log Analytics。 通過配置資料收集並定義要監控的指標和記錄，您可以收集有價值的工作負載資料進行分析。 對於網路監視，請將 Azure 監視器與 Azure 網路監看員、Azure 監視器網路深入解析和 Azure ExpressRoute 監視結合。
Azure Monitor 允許你分析歷史資料並應用預測技術來預測未來的工作負荷趨勢和容量要求。 您可以生成可幫助您進行容量規劃的預測。 這些預測有助於透過使用預測的需求模式來估計伺服器容量、網路頻寬、儲存容量和其他資源需求。
確定資源要求：由於 Azure 工具和服務提供了廣泛的配置，因此可以説明您定義技術要求。 您可以將工作負載需求與可用的 Azure 資源保持一致，確保選擇適當的元件和設定來滿足您的功能需求。
瞭解資源限制： Power Platform 提供文檔和資源，説明您瞭解每種不同服務的性能限制。 考慮這些限制可以説明您做出明智的設計決策，並最佳化工作負載體系結構以提高效能和成本效益。
您應該注意設定和服務中的縮放限制。 您可以閱讀文件或執行測試。 如需詳細資訊，請參閱：
使用來自畫布應用的數據調用：來自畫布應用的數據調用流通過 OData 協定使用連接器將數據發送到表格數據源。 OData 要求流程到後端層，以到達目標資料來源並為用戶端擷取資料，或將資料提交到資料來源。 基於動作且支援 API 的連接器以相同的方式運作。
了解 OData 和 API 的要求如何在畫布應用程式中流動，將有助於您最佳化畫布應用程式效能和後端資料來源。 若要瞭解詳細資訊，請參閱 畫布應用中的資料調用流。
相關資訊
效能效益檢查清單
請參閱完整的建議集。