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儲存體時停用Transparent Great Pages。

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

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

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

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

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

Oak查詢引擎/索引最佳化

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

  • 如需有關如何分析緩慢查詢的資訊，請參閱此文章。
  • 依照此article，在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起預設為啟用)
  • 啟用 CopyOnWrite (自AEM 6.2起預設為啟用)
  • 啟用 預先擷取索引檔案 (自AEM 6.2起預設為啟用)

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

• 資料存放區
  如果您使用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時。

  • 您可以透過DocumentNodeStoreService上的blobCacheSize設定來設定快取大小(MB)。
    例如：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-observation的執行緒集區： 開啟​ /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—quickstart/install ​資料夾下。

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

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

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

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

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