Adobe Experience League

效能樹

範圍

下圖旨在指導您執行哪些步驟以排除效能問題。它分成5個區段，以方便閱讀。

圖中的每個步驟都會連結至檔案資源或建議。

先決條件和假設

假設在指定頁面（AEM主控台或網頁）上會出現效能問題，而且可以一致地重制。在開始調查之前，必須具備測試或監控效能的方式。

分析從步驟0開始。其目標是判斷哪個實體（發送器、外部主機或AEM）負責效能問題，然後決定應調查的區域（伺服器或網路）。

區段 1

chlimage_1-103

區段 2

chlimage_1-104

區段 3

chlimage_1-105

區段 4

chlimage_1-105

第5節

chlimage_1-107

參考連結

步驟	標題	資源
步驟 0	分析請求流程	您可以在瀏覽器中使用標準HTTP請求分析來分析請求流程。如需如何在Chrome上執行此動作的詳細資訊，請參閱： https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/resource- loadinghttps://developers.google.com/web/tools/chrome-devtools/profile/network-performance/understanding-resource-timing
步驟 2	請求是否來自外部主機？	您可以在瀏覽器中使用標準HTTP請求分析來分析請求流程。請參閱上述連結，瞭解如何在Chrome上執行此動作。
步驟 3	是否可快取請求？	有關可快取請求和一般Dispatcher效能優化建議的詳細資訊，請參閱Dispatcher Performance Optimization。
步驟 4	請求是否來自Dispatcher?	請查看Dispatcher除錯檔案以查看請求是否已正確快取。
步驟 5	Dispatcher是否嘗試透過AEM驗證每個請求？	在傳送快取資源之前，請檢查發送器是否會傳送`HEAD`要求給AEM以進行驗證。您可以在AEM `access.log`中尋找`HEAD`請求來完成此作業。如需詳細資訊，請參閱記錄。
步驟 6	Dispatcher的地理位置離用戶是否很遠？	將Dispatcher移至更靠近使用者的位置。
步驟 7	Dispatcher的網路層是否正常？	調查網路層的飽和度和延遲問題。
步驟 8	慢速度是否可透過本機執行個體重現？	使用Tough Day從生產實例複製「真實世界」條件。如果這對您的開發方案不現實，請務必在不同的網路內容中測試生產實例（或相同的測試實例）。
步驟 9	伺服器的地理位置是否遠離用戶？	將伺服器移至使用者附近。
步驟10和29	調查網路層	調查網路層的飽和度和延遲問題。對於作者層，建議延遲不超過100毫秒。如需效能最佳化秘訣的詳細資訊，請參閱本頁。
步驟 11	更靠近伺服器或在每個區域添加一個
步驟 12	疑難排解AEM伺服器	請查看圖中的以下子步驟，以瞭解詳細資訊。
步驟 13	檢查硬體需求	查看硬體尺寸指南的文檔。
步驟 14	檢查效能問題的常見原因
步驟 15	尋找慢速請求	您可以分析`request.log`或使用`rlog.jar`來檢查慢速請求。有關使用rlog.jar的詳細資訊，請參見此頁。請參閱使用rlog.jar查找持續時間較長的請求。
步驟 16	設定檔伺服器	如需可與AEM搭配使用之分析工具的詳細資訊，請參閱監視和分析效能的工具。
步驟 17	在分析中尋找慢速方法
步驟 18	分析的常見情況	請參閱「效能優化」部分的分析特定方案。
步驟 19	100% CPU	https://helpx.adobe.com/experience-manager/6-3/sites-deploying/monitoring-and-maintaining.html#MonitoringPerformance
步驟 20	記憶體不足	記憶體不足我的應用程式會拋出記憶體不足的錯誤分析幫助上的記憶體問題。
步驟 21	磁碟I/O	請參閱「監視和維護」文檔中的磁碟I/O部分。
步驟22和22.1	快取比	請參閱計算Dispatcher快取比率。
步驟 23	慢速查詢	查詢和索引的最佳做法
步驟 24	儲存庫優化	效能調整提示效能配置儲存庫效能優化
步驟 25	執行的工作流程	併發工作流處理為特定工作流配置隊列定期清除工作流實例瞬態工作流程
步驟 26	MSM Infrastructure	多站點管理器最佳實踐
步驟 27	資產調整	資產同步服務多個DAM實例效能調整提示文章這裡和這裡。
步驟 28	未關閉的會話	檢查未關閉的JCR會話
步驟 30	更靠近調度程式（每個「地區」添加一個？）
步驟 31	在Dispatcher前面使用CDN	搭配使用 Dispatcher 與 CDN
步驟 32	使用分派器層級的作業管理來卸載AEM伺服器	啟用安全會話
步驟 33	讓請求可快取	一般調度程式配置配置Dispatcher快取如何提高快取率；使請求可快取（Dispatcher最佳做法）此外，請考慮以下設定以優化快取配置為非GET的HTTP請求設定無快取規則將查詢字串設定為不可快取請勿快取遺失副檔名的URL 快取驗證標題（自Dispatcher 4.1.10版起可能）
步驟 34	升級調度程式版本	您可以在以下位置下載最新的Dispatcher版本：追蹤連結
步驟 35	配置調度程式	配置Dispatcher
步驟 36	檢查快取失效	作者層的快取失效；發佈層的快取失效。
步驟37和38	延遲載入	請參閱「AEM Web Performance的Gem工作階段」。
步驟 39	使用預連接以減少連接開銷	請參見上述Gem會話。此外，W3c: https://www.w3.org/TR/resource-hints/#dfn-preconnect上的其他檔案已預先連線
步驟40和41	外部主機延遲和響應時間	調查外部主機的延遲和響應時間。
步驟45 和47	使用HTTP/2	有關步驟37、38和39，請參見Gem會議。此外，請查看此論壇帖子有關HTTP/2支援。
步驟 49	縮減負載大小	啟用 Gzip並縮小影像大小。
步驟42和43	Keep-Alive	`Keep-Alive`標題是否存在於重新使用連接的不同請求中？否則，這表示每個請求都會導致另一個連接建立，這會帶來不必要的開銷。（瀏覽器中的標準HTTP請求分析）您可以檢查Proxy Server工具以檢查Keep-Alive連接。
步驟 44	提出多少要求？	在瀏覽器中執行標準HTTP請求分析。
步驟 46	減少請求數	串連資源（影像、CSS精靈、JSON等） Clientlibs內嵌：建立用戶端程式庫資料夾 -請參閱「使用內嵌功能將請求減至最少」標題
步驟 48	有效載荷的大小是多少？	瀏覽器中的標準HTTP請求分析
步驟50和51	JS程式碼封鎖	https://docs.adobe.com/ddc/en/gems/aem-web-performance.html