效能最佳化 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和作業系統級別調整通常不會導致效能大幅提升，因此應在最佳化週期的最後階段執行。

內容存放庫的結構方式也會影響效能。 為獲得最佳效能，內容儲存庫中連接到單個節點的子節點數不應超過1,000個（作為一般規則）。

在通常的效能最佳化練習中，您最好的朋友是：

載入和編輯數位資產時的效能 performance-when-loading-and-editing-digital-assets

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

以下兩件事會影響效能：

若要改善效能，您可以考慮下列事項：

效能監控 performance-monitoring

效能（或缺少效能）是使用者首先注意到的事項之一，因此，與任何具有使用者介面的應用程式一樣，效能至關重要。 若要最佳化AEM安裝的效能，您必須監控執行個體的各種屬性及其行為。

有關如何執行效能監視的資訊，請參見 監控效能.

導致效能問題的問題往往很難追蹤，即使它們的效果很容易看到。

基本起點是系統正常運行時對系統的充分了解。 除非您知道環境在正常執行時「外觀」和「行為」如何，否則在效能惡化時很難找到問題。 這意味著，在系統正常運行時，您應該花一些時間調查系統，並確保收集效能資訊是一項持續的任務。 如果效能受到影響，這將為您提供比較的基礎。

下圖說明AEM內容要求可採取的路徑，因此可影響效能的不同元素數目。

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

卷 系統處理和傳送的輸出量。

容量 系統傳送卷的能力。

這可以在整個Web鏈的不同位置中說明。

有幾個功能領域通常是影響效能的原因：

關於效能的基本規則 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 Job Queue Configuration Service Factory建立，用於處理工作流程作業：

配置這些服務以限制並行運行的工作流進程的最大數量。

注意： 配置這些作業隊列會影響所有工作流，除非您已為特定工作流模型建立作業隊列(請參閱 配置特定工作流模型的隊列 )。

儲存庫中的設定 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 Job Queue Configuration Service工廠下方找到現有的設定項目。

您需要配置名為「最大並行作業數」的屬性。

配置特定工作流的隊列 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 Asset Synchronization Service cq-dam-asset-synchronization-service

此 AssetSynchronizationService 用於從掛載的儲存庫（包括LiveLink、Documentum等）同步資產。 預設情況下，每300秒（5分鐘）會進行一次定期檢查，因此，如果您不使用已裝載的儲存庫，則可以禁用此服務。

這是由 設定OSGi服務 CQ DAM資產同步服務 設定 同步期間 ( scheduler.period)至（最少為）1年（以秒為單位定義）。

多個DAM例項 multiple-dam-instances

部署多個DAM例項可在下列情況下提供效能：

其他考量事項包括：

品質保證最佳實務 best-practices-for-quality-assurance

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

本節旨在針對您的 發佈 環境。 這主要是QA工程師、項目經理和系統管理員感興趣的。

以下內容涵蓋針對AEM應用程式在 發佈 環境。 這包括下列5個階段：

控制是一個附加的、包羅永珍的過程 — 必要但不限於測試。

知識驗證 verification-of-knowledge

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

測試架構 test-architecture

您應清楚記錄用於效能測試的測試環境的架構。

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

應用程式圖 application-map

若要取得清楚的概觀，您可以建立整個應用程式的地圖（您很可能會透過製作環境上的測試取得）。

應用程式內部元素的圖表表示，可提供測試需求的概述；使用顏色編碼，還可以作為報告的基礎。

範圍定義 scope-definition

應用程式通常會有一系列使用案例。 有些將非常重要，有些則不那麼重要。

若要將效能測試的範圍集中在發佈上，建議您定義：

使用案例的數量由您決定，但應限制在可輕鬆管理的數量（例如5到10個）。

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

測試方法 test-methodologies

此概念有4種用於定義和測試效能目標的方案：

根據以下原則。

元件斷點 component-breakpoints

交易 transactions

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

定義範圍和相關KPI後，即可設定特定的績效目標。 這包括設計測試案例和目標值。

您需要在平均和峰值條件下測試效能。 此外，您還需要「上線」案例測試，以確保您能在網站首次開放時，迎合對您網站的興趣。

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

單一元件測試 single-component-tests

關鍵元件需要在平均和峰值條件下進行測試。

在這兩種情況下，當預定義的用戶數使用系統時，您可以定義每秒的預期事務數。

組合元件測試 combined-component-tests

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

正在進行即時測試 going-live-tests

在網站推出後的頭幾天，您會預期興趣會增加。 這可能會比您測試的峰值還要大。 強烈建議測試「上線」案例，以確保系統可應付此情況。

錯誤方案測試 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儲存在檔案中 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類型，這些檔案可能會不正確顯示。

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

備份效能 backup-performance

本節介紹一系列基準，用於評估AEM備份的效能以及備份活動對應用程式效能的影響。 AEM備份在運行時會給系統帶來顯著負載，我們會測量這一點，以及嘗試調制這些效果的備份延遲設定的影響。 其目標是提供一些參考資料，說明在實際配置和生產資料數量中備份的預期效能，並就如何估計計畫系統的備份時間提供指導。

參考環境 reference-environment

物理系統 physical-system

本文檔中報告的結果來自在參考環境中運行的基準，其配置如下。 此配置的設計與資料中心中的典型生產環境類似：

此伺服器上的磁碟子系統速度相當快，它代表了可能用於生產伺服器的高效能RAID配置。 備份效能對磁碟效能很敏感，而此環境中的結果反映了在非常快的RAID配置上的效能。 VMWare映像配置為在RAID陣列上具有物理駐留在本地磁碟儲存中的單個大磁碟卷。

AEM設定會將存放庫和資料存放區放置在相同的邏輯卷上，並與所有作業系統和AEM軟體一起。 用於備份的目標目錄也駐留在此邏輯檔案系統上。

資料卷 data-volumes

下表說明了備份基準中使用的資料卷的大小。 首先安裝初始基線內容，然後添加額外的已知資料量以增加備份內容的大小。 備份將以特定增量建立，以代表內容的大量增加，以及一天內可能產生的內容。 內容（頁面、影像、標籤）的分配將大致以真實的生產資產構成為基礎。 頁面、影像和標籤最多將限制為800個子頁面。 每個頁面都包含標題、Flash、文字/影像、影片、投影片、表單、表格、雲端和轉盤元件。 映像將從400個不重複檔案的池中上載，大小從37千位到594千位。

每次重複時添加的附加內容集會重複備份基準。

基準方案 benchmark-scenarios

備份基準包括兩種主要情形：在系統處於嚴重應用程式負載下時進行備份，在系統空閒時進行備份。 雖然一般建議在AEM盡可能空閒時執行備份，但在某些情況下，系統負載不足時必須運行備份。

從AEM伺服器記錄檔取得備份時間和產生的備份大小。 通常建議在AEM空閒時（如半夜）將備份安排為非時間。 這種情況是建議方法的代表。

Load將包含頁面建立/刪除、周遊和查詢，其中大部分的載入來自頁面周遊和查詢。 新增和移除太多頁面會持續增加工作區大小，使備份無法完成。 指令碼將使用的載入分佈為75%的頁面周遊、24%的查詢和1%的頁面建立（沒有巢狀子頁面的單級）。 空閒系統上每秒的峰值平均事務數是通過4個併發線程實現的，這是在負載下測試備份時將使用的線程數。

負載對備份效能的影響可以通過使用和不使用此應用程式負載時的效能之間的差異來估計。 通過比較每小時事務中的方案吞吐量，以及當前和未進行並行備份，以及備份以不同的「備份延遲」設定運行，可以發現備份對應用程式吞吐量的影響。

結果摘要 summary-of-results

備份時間和吞吐量 backup-time-and-throughput

這些基準的主要結果是顯示備份時間隨備份類型和資料總量的變化情況。 下圖顯示了使用預設備份配置獲得的備份時間，其形式是總頁數的函式。

空閒實例上的備份時間相當一致，平均為0.608 MB/s，而不考慮完整備份或增量備份（請參見下圖）。 備份時間只是備份資料量的函式。 完成完整備份的時間會隨著頁面總數而明顯增加。 完成增量備份的時間也隨著頁面總數而增加，但速度要慢得多。 由於備份的資料量相對較少，完成增量備份所花的時間要短得多。

備份的大小是完成備份所花費時間的主要決定因素。 下圖顯示了最終備份大小所花費的時間。

此圖表說明，增量備份和完整備份都遵循簡單的大小與時間模式，我們可以將這些模式作為吞吐量進行衡量。 空閒實例上的備份時間相當一致，平均為0.61 MB/秒，而不考慮基準環境中的完整備份或增量備份。

備份延遲 backup-delay

提供備份延遲參數以限制備份可能干擾生產工作負載的程度。 參數指定了以毫秒為單位的等待時間，該時間會逐個插入到備份操作中。 整體效果部分取決於受影響的檔案大小。 以MB/秒衡量備份效能提供了比較延遲對備份的影響的合理方法。

要比較使用檔案系統備份（使用'tar'）備份同一儲存庫檔案時獲得的吞吐量。 tar的效能可比，但略高於將延遲設為零的備份。 即使設定一個小延遲，也會大大降低備份吞吐量，而10毫秒的預設延遲會導致吞吐量大大降低。 在備份可能在總體應用程式使用率很低或應用程式完全空閒時進行計畫的情況下，最好將延遲降低到預設值以下，以便允許備份更快地進行。

持續備份的應用程式吞吐量的實際影響取決於應用程式和基礎架構的詳細資訊。 延遲值的選擇應通過應用程式的經驗分析進行，但應盡可能小，以便備份能盡快完成。 由於延遲值的選擇與對應用程式吞吐量的影響之間只存在微弱的關聯，因此選擇延遲應有利於縮短總體備份時間，以最大限度地減少備份的整體影響。 備份需要8小時才能完成，但對吞吐量的影響是–20%，其總體影響可能比完成需要2小時但對吞吐量的影響是–30%的備份大。

引用 references