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

Descrizione

Ambiente 

• Adobe Experience Manager 6.4
• Adobe Experience Manager 6.5

Problema/Sintomi

Il tempo di risposta è scarso quando gli autori modificano il contenuto o i siti web rispondono lentamente alle richieste dei visitatori.

Questi suggerimenti per l'ottimizzazione delle prestazioni consentono di accelerare query e prestazioni.

Causa

I seguenti fattori influenzano i problemi di performance dell’AEM:

• Progettazione non corretta
• Codice applicazione
• Mancanza di memorizzazione nella cache
• Configurazione I/O disco non valida
• Dimensioni della memoria
• Larghezza di banda e latenza di rete
• AEM installato in alcune versioni selezionate di windows 2008 e 2012 in cui la gestione della memoria è un problema
• La modifica delle configurazioni pronte all’uso, come descritto di seguito, può contribuire a migliorare le prestazioni nell’AEM.

Risoluzione

Prevenzione dei problemi di prestazioni

Di seguito sono riportati alcuni passaggi che è possibile eseguire per assicurarsi di individuare e risolvere i problemi di prestazioni prima che abbiano un impatto sugli utenti:

1. 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 linee guida sulle prestazioni e linee guida per il monitoraggio.

2. 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.

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

4. Se utilizzi il server Windows, controlla questo articolo.

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

6. 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 VM, assicurarsi che il pool di entropia sia sempre > 1.000 bit (utilizzare rngtools se necessario)

7. 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 disattiva pagine di grandi dimensioni trasparenti quando si utilizza la conservazione Mongo o Tar.

8. 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 delle risorse.

9. 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 alla seguente pagina: https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration Imposta queue.maxparallel a 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.

10. Ottimizzazione dell’archivio Oak
    Assicurati innanzitutto di aver installato la versione Oak più recente per l’istanza AEM 6. Controlla la pagina degli hotfix consigliati sopra.

    Ottimizzazioni 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 articolo.
      • Creare gli indici personalizzati sotto il nodo oak:index per tutte le proprietà di ricerca che si desidera cercare seguendo questa procedura 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 (vedere anche Documentazione Oak)
      • Doak.queryLimitReads=100000 (vedere anche Documentazione 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 risultato in Documentazione Oak)

      Attenzione: Abilitazione fastQuerySize consente di ottenere risposte alle 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 dell’indice Lucene\

      Apri /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService e

      • abilita CopyOnRead (attivata per impostazione predefinita a partire dalla versione 6.2 dell’AEM)
      • abilita CopyOnWrite (attivata per impostazione predefinita a partire dalla versione 6.2 dell’AEM)
      • abilita Preacquisire i file di indice (attivata per impostazione predefinita a partire dalla versione 6.2 dell’AEM)

      Consulta https://jackrabbit.apache.org/oak/docs/query/lucene.html per ulteriori informazioni sui parametri disponibili Poiché alcuni percorsi non devono essere indicizzati, è possibile effettuare le seguenti operazioni: In CRXDE Lite, passare a /oak:index/lucene, impostare 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. Consulta documentazione per istruzioni dettagliate.
      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

      Tieni presente che 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: il cacheSizeInMB Se impostata su un valore troppo alto, la memoria del processo Java potrebbe esaurirsi. 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.

11. Ottimizzazione dello storage Mongo

    • Dimensione cache MongoBlobStore: Il blobstore viene utilizzato per memorizzare 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 su DocumentNodeStoreService.
        Ad esempio: blobCacheSize=1024
      • Si prega di rivedere anche AEM-MongoDB elenco di controllo.

    • Dimensione cache documenti: Per ottimizzare le prestazioni di lettura dei nodi da MongoDB è necessario regolare 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. Consulta 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 con 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

    • Implementa l’elenco di controllo per la produzione di MongoDB:\

      https://docs.mongodb.org/manual/administration/production-checklist/ - secondo il 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 su ogni nodo AEM: ?readPreference=secondaryPreferred
      Questo parametro indica al sistema di eseguire letture dal secondario, il che offre alcune prestazioni di lettura aggiuntive.

    • Aumenta il pool di thread per l’osservazione di oak: apri /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 parametro contenitore oak.observation.queue-length=50000. Posizionalo sotto al /crx: avvio rapido/installazione cartella.

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

12. 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 gli hotfix/patch relativi alle prestazioni da Microsoft (vedere 2731284 KB) e Oracle.

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

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

14. Clienti di Cloud Manager per Adobe Managed Services (AMS)
    Cloud Manager (Solo per clienti AMS) consente ai clienti di garantire una distribuzione AEM di successo con test guidati delle prestazioni e scalabilità automatica.

Risorse Business.Adobe.com