AEM 6.x | Suggerimenti per l'ottimizzazione delle prestazioni

Implementa ed esegui test di carico che simulano scenari realistici sia nelle istanze di authoring che di pubblicazione. La ricerca e la definizione del carico previsto costituiscono un passaggio fondamentale di questo processo. Questo passaggio consente di dimostrare se l'applicazione AEM, l'architettura e l'installazione AEM funzioneranno correttamente una volta in un ambiente di produzione.
I risultati di questo esercizio consentono di determinare se si è verificato un errore di configurazione, un problema di applicazione, di dimensioni, un problema hardware o un altro problema che influisce sulle prestazioni del sistema. Consulta anche le linee guida sulle prestazioni e linee guida sul monitoraggio.

Oltre al test di carico, lo stress test aiuta a definire il carico massimo che il sistema può gestire. Questo test può aiutarti a prepararti per i picchi di traffico. Ulteriori informazioni sui test delle prestazioni sono disponibili qui.

Installa i Service Pack, i Cumulative Fix Pack e gli Hotfix consigliati per AEM: Aggiornamenti della versione di Adobe Experience Manager.

Se utilizzi il server Windows, rivedi questo articolo.

Se prevedi di caricare grandi quantità di risorse (immagini, video e così via) in AEM, assicurati di applicare le best practice per Assets.

Provisioning sufficiente di RAM ed evitare la saturazione di I/O
Se intendi eseguire la produzione su qualsiasi scala, l’ambiente Linux deve disporre di tutta la RAM necessaria per l’espansione dei file tar dei segmenti tra la compattazione offline (o i picchi di compattazione online). Inoltre, quanto segue evita la saturazione I/O.

• Dischi distinti per sistemi operativi, dati e registrazione
• Montare dischi dati con Noatime.
• Impostare i buffer read-ahead su 32 sul disco dati.
• È consigliabile utilizzare XFS su ext4 sui dischi dati.
• Se RedHat è in esecuzione in una macchina virtuale, verificare che il pool di entropia sia sempre di > bit (se necessario, utilizzare rngtools)

Disabilita pagine grandi trasparenti su Linux
L'AEM esegue operazioni di lettura/scrittura dettagliate, mentre le pagine Linux Transparent Huge sono ottimizzate per operazioni di grandi dimensioni, pertanto si consiglia di disabilitare le pagine Transparent Huge quando si utilizza lo storage Mongo o Tar.

Abilitazione dei flussi di lavoro transitori
I flussi di lavoro transitori possono essere utilizzati per qualsiasi flusso di lavoro che:

• vengono eseguiti spesso.
• non è necessaria la cronologia del flusso di lavoro.

In queste situazioni genereranno un aumento delle prestazioni.
Questo caso d’uso viene generalmente soddisfatto in presenza di volumi elevati di risorse acquisite.
Segui la procedura documentata in Ottimizzazione delle prestazioni di Assets.

Tuning delle code dei processi Sling
Il caricamento in blocco di risorse di grandi dimensioni è in genere un processo che richiede un uso intensivo delle risorse. Per impostazione predefinita, il numero di thread simultanei per coda processi è uguale al numero di core CPU. Di conseguenza, questa impostazione di valore può causare un impatto complessivo sulle prestazioni e un elevato consumo di heap Java.
L'Adobe consiglia di non superare il 50% dei core della CPU. Per regolare questo valore, passare al seguente indirizzo: https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration
Impostare queue.maxparallel su un valore che rappresenta il 50% dei core CPU del server che ospita l'istanza AEM. Ad esempio, per 8 core CPU, imposta il valore su 4.

Ottimizzazione dell’archivio Oak
Verifica innanzitutto che sia installata la versione più recente di Oak per l’istanza AEM 6. Controlla la pagina degli hotfix consigliati sopra.

Ottimizzazioni di Oak Query Engine/Index

• Crea indici OAK personalizzati per tutte le query di ricerca utilizzate di frequente.

  • Per informazioni su come analizzare le query lente, consulta questo articolo.
  • Creare gli indici personalizzati nel nodo oak:index per tutte le proprietà di ricerca che si desidera cercare seguendo questo articolo.
  • Per ogni indice personalizzato basato su Lucene, prova a impostare l’impostazione includePaths (stringa) per limitare l’indice in modo che venga applicato solo a determinati percorsi di contenuto. Quindi limita le ricerche applicabili ai percorsi inclusi dall’indice.

• Parametri JVM
  Aggiungi questi parametri JVM nello script iniziale dell’AEM per evitare che query di grandi dimensioni sovraccarichi i sistemi. Si tratta dei valori predefiniti a partire da AEM 6.3.

  • Doak.queryLimitInMemory=500000 (vedi anche documentazione di Oak)
  • Doak.queryLimitReads=100000 (vedi anche documentazione di Oak)
  • Dupdate.limit=250000 (solo per DocumentNodeStore, ad esempio MongoMK, RDBMK)

  Anche la seguente opzione potrebbe migliorare le prestazioni, ma cambia il significato della chiamata dimensione risultato. In particolare, nel calcolo della dimensione vengono considerate solo le restrizioni delle query che fanno parte dell’indice utilizzato.
  Inoltre, gli ACL non vengono applicati ai risultati, pertanto i nodi non visibili alla sessione corrente verranno comunque inclusi nel conteggio restituito. Di conseguenza, il conteggio restituito può essere superiore al numero effettivo di risultati e il conteggio accurato può essere determinato solo iterando tra i risultati:

  • Doak.fastQuerySize=true (vedere anche Dimensione risultati nella documentazione di Oak)

  Attenzione: l'attivazione di fastQuerySize comporta risposte di query più rapide. Tuttavia, l’AEM restituisce conteggi di risultati non accurati per alcune query. Se si utilizza un conteggio preciso dei risultati nell'applicazione, non utilizzare fastQuerySize.

• Configurazione indice Lucene
  Apri /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService e

  • abilita CopyOnRead (abilitato per impostazione predefinita a partire da AEM 6.2)
  • abilita CopyOnWrite (abilitato per impostazione predefinita da AEM 6.2)
  • abilita Preacquisire i file di indice (abilitato per impostazione predefinita a partire da AEM 6.2)

  Per ulteriori informazioni sui parametri disponibili, vedere https://jackrabbit.apache.org/oak/docs/query/lucene.html
  Poiché alcuni percorsi non devono essere indicizzati, puoi effettuare le seguenti operazioni:
  In CRXDE Lite, vai a /oak:index/lucene, imposta una proprietà stringa multivalore (String)denominata excludedPaths con questi valori /var, /etc/workflow/instances, /etc/replication.

• Archivio dati
  Se utilizzi AEM Assets o disponi di un’applicazione AEM che utilizza ampiamente i file binari, Adobe consiglia di utilizzare un archivio dati esterno. L’utilizzo di un archivio dati esterno consente di garantire le massime prestazioni. Per istruzioni dettagliate, consulta la documentazione.
  Quando si utilizza un FileDataStore, regolare cacheSizeInMB a una percentuale dell’heap disponibile. Un valore conservativo è il 2% dell’heap massimo. Ad esempio, per un heap da 8 GB:

  • maxCachedBinarySize=1048576
  • cacheSizeInMB=164

  maxCachedBinarySize è impostato su 1 MB (1048576). Di conseguenza, memorizza in cache solo i file che hanno una dimensione massima di 1 MB. Potrebbe essere utile regolare questa impostazione su un valore inferiore.
  Quando si ha a che fare con un numero elevato di file binari, si desidera massimizzare le prestazioni. Pertanto, Adobe consiglia di utilizzare un archivio dati esterno invece degli archivi nodi predefiniti. Inoltre, Adobe consiglia di regolare i seguenti parametri:

  • maxCachedBinarySize=10485760
  • cacheSizeInMB=4096

  Nota: l'impostazione cacheSizeInMB può causare l'esaurimento della memoria del processo Java se impostato su un valore troppo alto. Ad esempio, se la dimensione heap massima è impostata su 8 GB (-Xmx8g) e si prevede che l’AEM e l’applicazione utilizzino un heap combinato di 4 GB, ha senso impostare cacheSizeInMB su 82 invece di 164. Una configurazione sicura è compresa tra il 2% e il 10% dell’heap massimo. Tuttavia, Adobe consiglia di convalidare le modifiche alle impostazioni con il test di carico, monitorando al contempo l’utilizzo della memoria.

Ottimizzazione dello storage Mongo

• Dimensione cache di MongoBlobStore: Il blobstore viene utilizzato per archiviare e leggere oggetti binari di grandi dimensioni. Internamente, l’archivio con cache viene implementato che divide i binari in blocchi relativamente piccoli (dati o codice hash o hash indiretto), in modo che ogni blocco rientri nella memoria. In una configurazione predefinita, MongoBlobStore utilizza una dimensione cache fissa di 16 MB. Per le distribuzioni in cui è disponibile più RAM e si accede spesso all’archiviazione BLOB (ad esempio, quando l’indice Lucene è grande), aumenta la dimensione della cache. Questa dimensione della cache si applica solo quando utilizzi MongoBlobStore (impostazione predefinita) e non quando utilizzi un archivio globale esterno.

  • È possibile configurare la dimensione della cache (in MB) tramite l'impostazione blobCacheSize in DocumentNodeStoreService.
    Ad esempio: blobCacheSize=1024
  • Rivedi anche la lista di controllo di AEM-MongoDB.

• Dimensione cache documenti: Per ottimizzare le prestazioni di lettura dei nodi da MongoDB, è necessario ottimizzare le dimensioni delle cache di DocumentNodeStore. La dimensione predefinita della cache è impostata su 256 MB, che viene distribuita tra le varie cache utilizzate in DocumentNodeStore. Vedi http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

  • È possibile configurare la dimensione della cache (MB) tramite l'impostazione della cache in DocumentNodeStoreService. Ad esempio, cache=2048.

  • Imposta tutte le seguenti configurazioni di cache in crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.confige quindi carica il test con vari valori per vedere quale è la configurazione ottimale per il tuo ambiente. La percentuale rimanente della cache viene assegnata alla cache dei documenti:

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

  • Con la configurazione precedente, le percentuali totali sono del 95%. Il restante 5% della cache viene assegnato a documentCache. documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

  • Durante la distribuzione delle percentuali della cache, assicurarsi che la cache rimanente per documentCache non sia molto grande. In altre parole, mantenetela a un massimo di 500 MB o meno; un documentCache di grandi dimensioni può comportare un aumento del tempo necessario per eseguire l’annullamento della validità della cache.

• Cache settings in AEM 6.2 with Oak 1.4.x:

  • In AEM 6.2 sono state apportate modifiche al funzionamento di queste impostazioni della cache. In AEM 6.2 con Oak 1.4, è disponibile una nuova cache: prevDocCache. È possibile configurare questa cache utilizzando l'impostazione prevDocCachePercentage. Il valore predefinito è 4.
  • DocumentCache utilizza la cache MB rimanente (impostazione della cache meno le dimensioni di tutte le altre cache): documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache

• Implementare l'elenco di controllo produzione MongoDB:
  https://docs.mongodb.org/manual/administration/production-checklist/ - in base al supporto di Mongo DB, molti elementi hanno un forte impatto sulle prestazioni. Per qualsiasi domanda, contatta direttamente il supporto MongoDB.

• Prestazioni di lettura: Aggiungi questo parametro della stringa di query all'URL di Mongo DB in ogni nodo AEM: ?readPreference=secondaryPreferred
  Questo parametro indica al sistema di eseguire letture dal secondario, il che offre alcune prestazioni di lettura aggiuntive.

• Aumentare il pool di thread per l'osservazione oak: aprire /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory Imposta il nome su oak-observation (osservazione quercia) e imposta la dimensione minima e massima del pool su 20.

• Aumenta lunghezza coda di osservazione: Crea un file denominato com.adobe.granite.repository.impl.SlingRepositoryManager.cfg contenente il parametro oak.observation.queue-length=50000. Inseriscilo nella cartella /crx—quickstart/install.

• Evitare query con tempi di esecuzione lunghi: impostare la proprietà di sistema nei parametri JVM: -Doak.mongo.maxQueryTimeMS=60000 per evitare che le query vengano eseguite per più di 1 minuto.

Ottimizzazione dello storage TAR
I microkernel non chiamano direttamente i file mappati sulla memoria. Tuttavia, JDK utilizza internamente i file mappati sulla memoria per una lettura efficiente. Su alcuni sistemi operativi Windows a 64 bit potrebbe non riuscire a pulire i file mappati in memoria e utilizzare tutta la memoria nativa del sistema operativo. Assicurarsi di installare le patch e gli hotfix relativi alle prestazioni da Microsoft (vedere KB 2731284) e l'Oracle.

In alternativa, è possibile disabilitare la modalità mappa di memoria aggiungendo tarmk.mode=32 in SegmentNodeStoreService.config fino a quando il problema del sistema operativo non viene risolto. Il lato negativo della disattivazione rende l'I/O intensivo. Accertarsi di aumentare il limite I/O di blocco pagina.

Revisione TarMK pulita (compattazione)
A partire da AEM 6.3, la compattazione online (nota anche come pulizia delle revisioni online) è abilitata per impostazione predefinita. Per ulteriori informazioni, vedere questa pagina.

Cloud Manager per utenti di Managed Services (AMS) di Adobe
Cloud Manager (solo per utenti AMS) consente di garantire la corretta distribuzione dell'AEM con test guidati delle prestazioni e scalabilità automatica.