AEM 6.x | 效能調整秘訣

實作並執行模擬製作和發佈執行個體中真實情境的負載測試。 研究和定義預期負載是這個過程中的關鍵步驟。 此步驟可協助您示範AEM應用程式、架構和AEM安裝一旦在生產環境中上線，是否會有良好的效能。
本練習的結果可協助判斷是否有設定錯誤、應用程式問題、大小調整、硬體問題，或其他影響系統效能的問題。 另請參閱 效能准則 和 監視准則.

除了負載測試，壓力測試有助於定義系統可處理的最大負載。 此測試可協助您為流量尖峰做好準備。 有關效能測試的更多資訊可以找到 此處.

安裝建議的AEM Service Pack、Cumulative Fix Pack和Hotfix： Adobe Experience Manager版本更新.

如果您使用的是Windows伺服器，請檢閱 本文.

如果您計畫將大量資產（影像、影片等）載入到AEM中，請務必套用 Assets最佳實務.

提供足夠的RAM並避免IO飽和
如果您打算以任何規模執行生產，則應該為Linux環境布建足夠的RAM，因為區段tar檔案會在離線壓縮（或線上壓縮尖峰）之間成長。 此外，下列專案可避免IO飽和度。

• 分隔作業系統、資料及記錄磁碟
• 使用Noatime掛載資料磁碟。
• 將資料磁碟上的預先讀取緩衝區設為32。
• 理想情況下，在資料磁碟上使用XFS over ext4。
• 如果RedHat是在VM中執行，請確定平均資訊量集區永遠是 > 1K位元（必要時使用rngtools）

在Linux上停用透明大型頁面
AEM會執行微調的讀取/寫入，而Linux Transparent Great Pages則是針對大型作業進行最佳化，因此建議您 停用透明大型頁面 使用Mongo或Tar儲存時。

啟用暫時性工作流程
暫時性工作流程可用於滿足以下條件的任何工作流程：

• 經常執行。
• 不需要工作流程歷史記錄。

在這些情況下，它們可以大幅提升效能。
當有大量的資產擷取時，通常符合此使用案例。
請遵循紀錄在上的程式 效能調整資產.

調整Sling工作佇列
大量上傳大型資產通常需要耗費大量資源。 依預設，每個工作佇列的並行執行緒數目等於CPU核心數目。 因此，此值設定可能會對整體效能造成影響，並造成高Java棧積消耗。
Adobe建議您不要超過50%的CPU核心。 若要調整此值，請前往下列位置： https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration Set queue.maxparallel 至代表AEM執行個體所在伺服器CPU核心50%的值。 例如，對於8個CPU核心，將值設定為4。

調整您的Oak存放庫
首先，請確定您已為AEM 6執行個體安裝最新的Oak版本。 請檢視上述建議Hotfix頁面。

Oak查詢引擎/索引最佳化

• 為所有常用的搜尋查詢建立自訂Oak索引。

  • 如需有關如何分析緩慢查詢的資訊，請參閱此 文章.
  • 在oak：index節點底下建立自訂索引，用於您要搜尋的所有搜尋屬性，方法如下 文章.
  • 對於每個自訂Lucene型索引，請嘗試設定includedPaths （字串）設定，以限制索引僅套用至某些內容路徑。 然後將適用的搜尋限制在索引所包含的那些路徑。

• JVM引數
  在AEM啟動指令碼中新增這些JVM引數，以防止擴充查詢讓系統過載。 請注意，這些是從AEM 6.3開始的預設值。

  • Doak.queryLimitInMemory=500000 (另請參閱 Oak檔案)
  • Doak.queryLimitReads=100000 (另請參閱 Oak檔案)
  • Dupdate.limit=250000 (僅適用於DocumentNodeStore，例如 MongoMK， RDBMK)

  下列選項可能也會改善效能，但會變更結果大小呼叫的意義。 特別是，在計算大小時，只會考慮已使用索引中的查詢限制。
  此外，ACL不會套用至結果，因此目前工作階段看不見的節點仍會包含在傳回的計數中。 因此，傳回的計數可能會高於實際結果數，而正確計數只能透過逐一檢視結果來決定：

  • Doak.fastQuerySize=true （另請參閱中的結果大小） Oak檔案)

  警告：啟用 fastQuerySize 可加快查詢回應速度。 但是，AEM傳回某些查詢的結果計數不正確。 如果您在應用程式中依賴精確的結果計數，請勿使用 fastQuerySize.

• Lucene索引設定
  開啟/system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService並

  • 啟用 CopyonRead (自AEM 6.2起預設為啟用)
  • 啟用 寫入時複製 (自AEM 6.2起預設為啟用)
  • 啟用 預先擷取索引檔案 (自AEM 6.2起預設為啟用)

  另請參閱 https://jackrabbit.apache.org/oak/docs/query/lucene.html 如需有關可用引數的詳細資訊由於有些路徑不需要編制索引，您可以執行下列動作：在CRXDE Lite中，前往/oak：index/lucene，使用下列值設定名為excludedPaths的多值字串屬性（字串） /var、/etc/workflow/instances、/etc/replication。

• 資料存放區
  如果您使用AEM Assets或擁有大量使用二進位檔案的AEM應用程式，Adobe建議您使用外部資料存放區。 使用外部資料存放區有助於確保最高效能。 另請參閱 檔案以取得詳細說明.
  使用FileDataStore時，請將cacheSizeInMB調整為您可用棧積的百分比。 保守值為最大棧積的2%。 例如，對於8 GB棧積：

  • maxCachedBinarySize=1048576
  • cacheSizeInMB=164

  請注意 maxCachedBinarySize 設為1 MB (1048576)。 因此，它只會快取最大1 MB的檔案。 將此設定調整為較小的值也是合理的。
  處理大量二進位檔時，您想要將效能最大化。 因此，Adobe建議使用外部資料存放區，而非預設節點存放區。 此外，Adobe建議您調整下列引數：

  • maxCachedBinarySize=10485760
  • cacheSizeInMB=4096

  注意： cacheSizeInMB 若設定得太高，可能會導致Java處理序的記憶體不足。 例如，如果您將棧積大小上限設為8 GB (-Xmx8g)，並且您預期AEM和您的應用程式會利用4 GB的組合棧積，則將cacheSizeInMB設定為82 （而不是164）是可行的做法。 在2-10%的範圍內最大棧積是安全的設定。 不過，Adobe建議您使用負載測試來驗證設定變更，同時監控記憶體使用情況。

Mongo儲存調整

• MongoBlobStore快取大小： blobstore是用來儲存和讀取大型二進位物件。 在內部，具有快取的存放區會實作，將二進位檔分割為相對較小的區塊（資料或雜湊程式碼或間接雜湊），以便每個區塊都適合記憶體。 在預設設定中，MongoBlobStore會使用16MB的固定快取大小。 對於有更多RAM可用且經常存取Blob儲存的部署（例如，當Lucene索引較大時），請增加快取大小。 此快取大小僅適用於使用MongoBlobStore （預設）時，而不適用於使用外部blobstore時。

  • 您可以透過上的blobCacheSize設定來設定快取大小(MB) DocumentNodeStoreService.
    例如：blobCacheSize=1024
  • 也請檢閱AEM-MongoDB 檢查清單.

• 檔案快取大小： 若要最佳化從MongoDB讀取節點的效能，您需要調整DocumentNodeStore的快取大小。 快取的預設大小設定為256 MB，這會分散在DocumentNodeStore中使用的各種快取中。 另請參閱 http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

  • 您可以透過DocumentNodeStoreService上的快取設定來設定快取大小(MB)。 例如，cache=2048。

  • 在crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.configure中設定下列所有快取設定，然後使用各種值執行載入測試，以檢視您環境的最佳設定為何。 請注意，剩餘的快取百分比會指定給檔案快取：

    • cache=2048
    • nodeCachePercentage=35
    • childrenCachePercentage=20
    • diffCachePercentage=30
    • docChildrenCachePercentage=10

  • 使用上述設定，百分比總計為95%。 剩餘5%的快取會提供給documentCache。 documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

  • 散發快取百分比時，請確定documentCache的剩餘快取不是太大。 也就是說，將其限制在最大500 MB以內；大型的documentCache可能會導致執行快取失效所需的時間增加。

• 使用Oak 1.4.x的AEM 6.2中的快取設定：

  • 在AEM 6.2中，已變更這些快取設定的運作方式。 在具有Oak 1.4的AEM 6.2中，有新的快取：prevDocCache。 您可以使用設定prevDocCachePercentage來設定此快取。 預設值為4。
  • documentCache使用剩餘的快取MB （快取設定減去所有其他快取的大小）： documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache

• 實施MongoDB生產檢查清單：
  https://docs.mongodb.org/manual/administration/production-checklist/ — 根據Mongo DB支援，許多專案對效能有重大影響。 如有任何問題，請直接聯絡MongoDB支援。

• 讀取效能： 將此查詢字串引數新增至每個AEM節點上的Mongo DB URL： ？readPreference=secondaryPreferred
  此引數會告訴系統從次要裝置進行讀取，這會提供部分額外的讀取效能。

• 增加Oak觀察的執行緒集區： open /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory 將名稱設為oak-observation，並將最小和最大集區大小設為20。

• 增加觀察佇列長度： 建立名為的檔案 com.adobe.granite.repository.impl.SlingRepositoryManager.cfg 包含引數 oak.observation.queue-length=50000. 將其放在 /crx — 快速入門/安裝 資料夾。

• 避免長時間執行查詢：在JVM引數中設定系統屬性： -Doak.mongo.maxQueryTimeMS=60000 以避免執行時間超過1分鐘的查詢。

Tar儲存調整
微核心不會直接呼叫記憶體對應檔案。 不過，JDK內部會使用記憶體對應檔案來進行有效讀取。 在某些Windows 64位元作業系統上，無法清除記憶體對應的檔案，並消耗所有原生作業系統記憶體。 請務必安裝microsoft提供的效能相關修補程式/Hotfix (請參閱 KB 2731284)和Oracle。

另一個選項是透過新增來停用記憶體對應模式 tarmk.mode=32 在 SegmentNodeStoreService.config 直到作業系統問題解決為止。 停用的缺點會導致I/O密集化。 請務必提高I/O分頁鎖定限制。

TarMK修訂清除（壓縮）
從AEM 6.3開始，線上壓縮（也稱為線上修訂清除）預設為啟用。 另請參閱 此頁面 以取得詳細資訊。

適用於AdobeManaged Services (AMS)客戶的Cloud Manager
Cloud Manager （僅限AMS客戶）可讓客戶透過引導式效能測試和自動調整規模，確保成功部署AEM。