效能最佳化 performance-optimization

關鍵問題是您的網站回應訪客要求所需的時間。 雖然此值會因每個請求而有所不同，但您可以定義平均目標值。 一旦這個值被證實既可達到又可維持，就可用來監視網站的效能並指示潛在問題的發展。

您針對的回應時間在製作和發佈環境上有所不同，這反映了目標對象的不同特性：

作者環境 author-environment

輸入和更新內容的作者會使用此環境。 它必須迎合個別使用者在更新內容頁面和這些頁面上的個別元素時，各自產生大量需要大量效能的要求的需要。

發佈環境 publish-environment

此環境包含您提供給使用者使用的內容。 在此，請求數量甚至更多，速度也一樣重要。 但由於要求的本質較不動態，可套用其他效能增強機制，例如快取內容或負載平衡。

效能最佳化方法 performance-optimization-methodology

AEM專案的效能最佳化方法可歸納為五個簡單的規則，從一開始就避免效能問題：

這些規則通常適用於Web專案，並與專案經理和系統管理員相關，以確保他們的專案在啟動時不會面臨效能挑戰。

最佳化計畫 planning-for-optimization

針對效能最佳化階段規劃約10%的專案工作量。 實際的效能最佳化需求取決於專案的複雜程度以及開發團隊的經驗。 雖然您的專案可能（最終）不需要配置時間，但最好一律在建議區域規劃效能最佳化。

如有可能，專案應先軟性啟動給有限的對象，以收集真實生活體驗並執行進一步的最佳化，而不是完整公告之後的額外壓力。

「即時」後，效能最佳化仍未結束。 現在您會在系統上體驗「實際」負載。 在啟動後，請務必規劃額外的調整。

由於您的系統負載會變更，而且系統的效能設定檔會隨著時間而改變，因此效能「調校」或「健康狀態檢查」應該以6到12個月的間隔排程。

模擬現實 simulate-reality

如果您使用網站，然後在啟動後發現您遇到效能問題，可能是因為您的負載和效能測試未充分模擬現實。

模擬現實很困難，您想投入多少精力才能變成「真實」取決於專案的性質。 「真實」不僅表示「真實的程式碼」和「真實的流量」，也表示「真實的內容」，尤其是關於內容大小和結構。 您的範本可能會因存放庫的大小和結構而表現出不同的行為。

建立堅實的目標 establish-solid-goals

正確建立效能目標的重要性不可低估。 通常，在人們專注於特定績效目標後，即使這些目標基於假設，也很難在之後變更這些目標。

建立良好、堅實的效能目標確實是最困難的領域之一。 通常最好從可比較的網站（例如新網站的前身）收集真實記錄和基準。

保持相關 stay-relevant

一次最佳化一個瓶頸很重要。 如果您嘗試同時執行一些作業而沒有驗證單一最佳化的影響，您可能會無法追蹤哪個最佳化測量有幫助。

敏捷反複專案週期 agile-iteration-cycles

效能調整是一個反複的過程，涉及測量、分析、最佳化和驗證，直到達到目標為止。 考慮到這一點，請在最佳化階段實施敏捷驗證流程，而不是在每次反複之後實施更沈重的測試流程。

此焦點表示實施最佳化的開發人員應可快速判斷最佳化是否已達到目標。 這項資訊很有價值，因為達到目標時，最佳化就會結束。

基本效能准則 basic-performance-guidelines

一般而言，請將未快取的html要求保留少於100毫秒。 更具體地說，以下可作為指引：

上述數字假設以下條件：

有些問題經常會導致效能問題，包括：

JVM和OS層級調整通常不會導致效能大幅提升，因此應該在最佳化週期的最後階段執行。

內容存放庫的結構方式也會影響效能。 為獲得最佳效能，附加至內容存放庫中個別節點的子節點數量不應超過1,000 （依規則）。

您最好的朋友在平常效能最佳化練習中會選擇：

載入和編輯Digital Assets時的效能 performance-when-loading-and-editing-digital-assets

由於載入和編輯數位資產時涉及大量資料，效能可能會成為一個問題。

影響效能的因素有二：

若要改善效能，請考量下列事項：

效能監控 performance-monitoring

效能（或缺乏效能）是使用者最先注意到的事項之一，因此對於任何具有使用者介面的應用程式而言，效能是關鍵重要性。 若要最佳化AEM安裝的效能，請監視執行個體的各種屬性及其行為。

如需有關如何執行效能監視的資訊，請參閱監視效能。

造成效能問題的問題通常很難追蹤，即使這些問題造成的影響很容易觀察。

當系統正常運作時，最基本的起點就是對系統有良好的瞭解。 除非您知道環境在正確執行時「外觀」和「行為」如何，否則在效能惡化時，就很難找出問題。 請花點時間調查您的系統是否順利執行，並確保收集效能資訊是一項持續的工作。 這麼做可為您提供在效能受損時進行比較的基礎。

下圖說明請求AEM內容可以採取的路徑，以及可能影響效能的不同元素數量。

效能也是容量與容量之間的平衡：

您可以在網頁鏈的不同位置展示效能。

通常有幾個功能區域會影響效能：

有關效能的基本規則 basic-rules-regarding-performance

最佳化效能時，請謹記特定規則：

設定效能 configuring-for-performance

AEM的某些層面（和/或基礎存放庫）可設定為最佳化效能。 以下是一些可能性和建議，您必須確定您是否或如何在進行變更之前使用相關功能。

搜尋索引 search-indexing

從AEM 6.0開始，Adobe Experience Manager使用Oak型存放庫架構。

您可以在這裡找到更新的索引資訊：

並行工作流程處理 concurrent-workflow-processing

若要改善效能，請限制同時執行的工作流程數量。 依預設，工作流程引擎會平行處理的工作流程數量，與Java™ VM可用的處理器數量相同。 當工作流程步驟需要大量處理資源(RAM或CPU)時，同時執行多個這些工作流程可能會對可用的伺服器資源造成高需求。

例如，上傳影像（或一般DAM資產）時，工作流程會自動將影像匯入DAM。 影像通常具有高解析度，可以輕鬆消耗數百MB的棧積以進行處理。 平行處理這些影像會在記憶體子系統和記憶體回收器上造成高負載。

工作流程引擎使用Apache Sling工作佇列來處理和排程工作專案處理。 預設已從Apache Sling工作佇列設定服務工廠建立下列工作佇列服務，以用於處理工作流程工作：

設定這些服務以限制同時執行的工作流程程式數上限。

存放庫中的設定 configuration-in-the-repo

如果您使用sling：OsgiConfig節點🔗設定服務，您必須找到現有服務的PID，例如： org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705。 您可以使用Web主控台探索PID。

設定名為queue.maxparallel的屬性。

Web主控台中的設定 configuration-in-the-web-console

若要使用Web主控台🔗設定這些服務，請在Apache Sling工作佇列設定服務工廠下找到現有的設定專案。

設定名為Maximum Parallel Jobs的屬性。

設定特定工作流程的佇列 configure-the-queue-for-a-specific-workflow

為特定工作流程模型建立工作佇列，以便您可以為該工作流程模型設定工作處理。 如此一來，您的設定會影響特定工作流程的處理，而預設Granite工作流程佇列的設定會控制其他工作流程的處理。

工作流程模型執行時，會針對特定主題建立Sling作業。 依預設，主題會符合為一般Granite工作流程佇列或Granite工作流程外部程式工作佇列設定的主題：

工作流程模型產生的實際工作主題包括模型特定的尾碼。 例如，DAM更新資產 ​工作流程模型會產生具有下列主題的工作：

com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model

因此，您可以為符合工作流程模型之工作主題的主題建立工作佇列。 設定佇列的效能相關屬性，只會影響產生符合佇列主題之作業的工作流程模型。

下列程式會使用​ DAM更新資產 ​工作流程作為範例，為工作流程建立工作佇列。

AEM DAM資產同步服務 cq-dam-asset-synchronization-service

AssetSynchronizationService可用來同步來自已掛接的存放庫(包括LiveLink、Documentum®等)的資產。 根據預設，此同步會每隔300秒（5分鐘）進行定期檢查，因此如果您不使用掛載的存放庫，則可以停用此服務。

停用服務已透過設定OSGi服務 CQ DAM Asset Synchronization Service ​來完成，以便將​ 同步處理期間 (scheduler.period)設定為一年（以秒為單位來定義）。

多個DAM例項 multiple-dam-instances

舉例來說，部署多個DAM例項有助於改善效能：

其他考量事項包括：

高品質Assurance的最佳作法 best-practices-for-quality-assurance

效能對您的發佈環境至關重要。 因此，在實作專案時，您必須仔細規劃及分析您為發佈環境進行的效能測試。

本節旨在提供標準化概觀，說明在您的​ 發佈 ​環境中定義測試概念時，所遇到的問題。 這些資訊主要是QA工程師、專案經理和系統管理員所感興趣的。

以下涵蓋​ 發佈 ​環境上AEM應用程式效能測試的標準化方法。 此效能測試包含下列五個階段：

控制是額外、全方位程式 — 必要但不限於測試。

知識驗證 verification-of-knowledge

第一步是記錄開始測試之前您必須知道的基礎資訊：

測試架構 test-architecture

記錄用於效能測試的測試環境架構。

您需要重製您的計畫生產發佈環境，以及Dispatcher和負載平衡器。

應用程式對應 application-map

取得清楚的概觀，您可從其中建立整個應用程式的對應（您可能已在作者環境的測試中取得此對應）。

以圖表呈現應用程式的內部元素，可概略說明測試需求；使用色彩編碼，也可作為報告的基礎。

範圍定義 scope-definition

應用程式通常有多種使用案例。 有些使用案例很重要，有些則不那麼重要。

為了著重於發佈之效能測試的範圍，Adobe建議您定義下列專案：

使用案例的數量取決於您，但應限制在易於管理的數量（例如，5到10之間）。

選取關鍵使用案例後，即可針對每個案例定義關鍵績效指標(KPI)和用於測量它們的工具。 常見KPI的範例包括：

測試方法 test-methodologies

此概念有四種用於定義和測試效能目標的情境：

根據下列原則。

元件中斷點 component-breakpoints

交易 transactions

定義效能目標 defining-the-performance-goals

定義範圍和相關的KPI後，就會設定特定的效能目標。 此過程包括設計測試場景以及目標值。

在平均和尖峰狀況下測試效能。 此外，您還需要進行上線案例測試，以確保您的網站在首次推出時能夠滿足不斷增長的興趣。

您可能從現有網站收集到的任何體驗或統計資料，也可用於決定未來的目標。 例如，來自已上線網站的熱門流量。

單一元件測試 single-component-tests

重要元件必須在平均和尖峰狀況下測試。

在這兩種情況下，當預先定義的使用者數量使用系統時，您都可以定義每秒的預期交易數量。

組合元件測試 combined-component-tests

組合測試元件可更密切地反映應用程式的行為。 必須再次測試平均值和尖峰狀況。

上線測試 going-live-tests

在您網站推出後的前幾天，興趣可能會增加。 此情境甚至大於您正在測試的峰值。 Adobe建議您測試「上線」情境，確保系統可因應這種情況。

錯誤案例測試 error-scenario-tests

測試錯誤案例以確保系統正確且正確地反應。 不僅在於如何處理錯誤本身，還在於錯誤可能對效能造成的影響。 例如：

設計這些測試時，請記得並非所有案例都會定期發生。 但是，它們對整個系統的影響很重要。

耐力測試 endurance-tests

只有在系統持續執行一段時間（小時或天）後，才會發生某些問題。 耐力測試是用來測試一段所需時間內的恆定平均負載。 然後可以分析任何效能降低。

最佳化 optimization

在實作的稍後階段，請最佳化應用程式以達成並最大化效能目標。

所做的任何最佳化都必須進行測試，以確保其具備：

您可利用一系列工具來協助您產生負載、監控效能及分析結果。 其中一些工具包括：

最佳化後，請再次測試以確認影響。

報告 reporting

持續報告可讓每個人隨時瞭解狀態。 如先前在色彩編碼中提及的，架構圖可用於此狀態。

完成所有測試後，報告下列專案：

使用Dispatcher時最佳化效能 optimizing-performance-when-using-the-dispatcher

Dispatcher是Adobe的快取及/或負載平衡工具。 使用Dispatcher時，請考慮將網站快取效能最佳化。

Dispatcher提供數個內建機制，方便您在網站運用時最佳化效能。 本節將說明如何設計網站，好讓快取的優點最大化。

計算Dispatcher快取比率 calculating-the-dispatcher-cache-ratio

快取比率公式會估計快取處理的要求佔進入系統的要求總數的百分比。 若要計算快取比率，您需要下列專案：

計算快取比率的公式為：

例如，如果要求總數為129491，而Publish執行個體提供的要求數58959為，則快取比率為： (129491 - 58959)/129491= 54.5%。

如果您沒有一對一的發佈者/Dispatcher配對，請將所有Dispatcher和發佈者的請求新增在一起，以獲得精確的測量。 另請參閱建議的部署。

使用一致的頁面編碼 using-consistent-page-encoding

使用Dispatcher 4.1.11版時，您可以快取回應標題。 如果您沒有在Dispatcher上快取回應標頭，如果您將頁面編碼資訊儲存在標頭中，可能會發生問題。 在此情況下，當 Dispatcher 從快取中提供頁面時，將會對此頁面使用網頁伺服器的預設編碼。 有兩種方式可避免此問題：

        <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

避免 URL 參數 avoid-url-parameters

可能的話，請避免針對您想要快取的頁面使用 URL 參數。 例如，如果您有圖片庫，則絕對不會快取以下 URL (除非 Dispatcher 已適當地設定)：

www.myCompany.com/pictures/gallery.html?event=christmas&page=1

不過，您可以將這些參數放到頁面 URL 中，如下所示：

www.myCompany.com/pictures/gallery.christmas.1.html

使用 URL 自訂 customize-by-url

如果您允許使用者變更字體大小 (或是其他任何版面自訂內容)，請確定不同自訂內容會反映在 URL 中。

例如，不會快取 Cookie，所以如果您將字體大小儲存在 Cookie (或類似機制) 中，將不會為快取頁面保留字體大小。因此，Dispatcher 會隨機傳回任何字體大小的文件。

在 URL 中包含字體大小當作選擇器可避免這個問題：

www.myCompany.com/news/main.large.html

讓用作標題的影像檔案失效 invalidating-image-files-used-as-titles

如果您將頁面標題或其他文字轉譯為圖片，建議您儲存檔案，以便在頁面內容更新時將其刪除：

例如，您可以將頁面myPage.html的標題儲存在file myPage.title.gif中。 頁面更新時會自動刪除此檔案，所以對頁面標題所做的任何變更都會自動反映到快取中。

讓用於導覽的影像檔案失效 invalidating-image-files-used-for-navigation

如果您將圖片用於導覽專案，此方法基本上與標題相同，但稍微複雜一點。 將所有導覽影像與目標頁面一起儲存。如果您將兩張圖片用於一般和活躍情境，可以使用以下指令碼：

請務必使用與頁面相同的命名控制代碼來建立這些圖片，以確保內容更新會刪除這些圖片和頁面。

對於未修改的頁面，圖片會留在快取中，但是頁面本身會自動失效。

個人化 personalization

建議您將個人化限制在必要的地方。 以下說明原因：

如果您將使用者名稱放在標題列中來個人化每個頁面（例如），則會影響效能。

關於在單一頁面上混合限制和公開內容，請考慮以下策略：在Dispatcher中使用伺服器端包含，或透過瀏覽器中的Ajax使用使用者端包含。

黏性連線 sticky-connections

黏性連線可確保同一個使用者的文件都會在相同伺服器上編寫。如果使用者離開此資料夾並於稍後返回，連線仍然保持不變。若要保留所有需要網站的粘性連線的檔案，請定義一個資料夾。 試著不要將其他文件放在該資料夾中。如果您使用個人化頁面和工作階段資料，此案例會影響負載平衡。

MIME 類型 mime-types

瀏覽器可使用兩種方式來判斷檔案的類型：

對於大多數檔案，MIME 類型會隱含在副檔名中。 也就是說，

如果檔案名稱沒有副檔名，則會顯示為純文字。

使用Dispatcher 4.1.11版時，您可以快取回應標題。 如果您沒有在Dispatcher上快取回應標頭，MIME型別就會是HTTP標頭的一部分。 因此，如果您的AEM應用程式傳回的檔案沒有可辨識的檔案結尾，而是依賴MIME型別，這些檔案可能無法正確顯示。

若要確保檔案可以正確地快取，請遵循以下準則：