Nota:

Stai leggendo la versione di Adobe Experience Manager 6.x dei suggerimenti per la regolazione delle prestazioni. Questo articolo è disponibile anche per la versione 5.x.

Il tempo di risposta è lento per la modifica e le richieste dei visitatori

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

Causa

I seguenti fattori influenzano i problemi di prestazioni in AEM:

  • Progettazione inappropriata
  • Codice applicazione
  • Mancanza di memorizzazione in cache
  • Configurazione I/O del disco scorretta
  • Dimensionamento della memoria
  • Larghezza di banda e latenza di rete
  • AEM installato su alcune versioni selezionate di Windows 2008 e 2012 in cui la gestione della memoria è un problema
  • Modificare le configurazioni preconfigurate come descritto di seguito può aiutare a migliorare le prestazioni di AEM.

Prevenire i problemi di prestazioni

Questi sono alcuni passaggi che puoi eseguire per assicurarti di trovare e risolvere i problemi di prestazioni prima che abbiano un impatto sui tuoi utenti:

  1. Implementa ed esegui i test di carico che simulano scenari realistici sia nelle istanze di pubblicazione che dell'autore. La ricerca e la definizione del carico previsto è una fase cruciale di questo processo. Questa fase aiuta a dimostrare se l'applicazione AEM, l'architettura e l'installazione di AEM funzioneranno bene una volta che è in funzione in un ambiente di produzione.

    I risultati di questo esercizio aiutano a determinare se c'è un errore di configurazione, un problema di applicazione, di dimensionamento, di hardware o altri problemi che influenzano le prestazioni del sistema. Vedi anche le linee guida per le prestazioni e le linee guida per il monitoraggio

  2. Oltre alle prove di carico, le prove di stress aiutano a definire il carico massimo che il sistema può gestire. Questo test può essere utile per prepararti ad affrontare i picchi di traffico. Ulteriori informazioni sui test delle prestazioni si possono trovare qui.

  3. Installazione dei service pack AEM consigliati, dei pacchetti di correzione cumulativi e degli hotfix:

    https://helpx.adobe.com/it/experience-manager/aem-releases-updates.html

  4. Se utilizzi un server Windows, leggi questo articolo.

  5. Se stai progettando di caricare grandi quantità di risorse (immagini, video e così via) su AEM, assicurati di applicare le migliori pratiche delle risorse.

  6. Rifornisci abbastanza la RAM ed evita la saturazione di IO

    Se intendi eseguire la produzione su qualsiasi scala, l'ambiente Linux dovrebbe essere dotato della stessa RAM dei file segment tar che cresceranno tra la compattazione offline (o picchi di compattazione online).  Inoltre, i seguenti elementi eviteranno la saturazione dell'IO.

    • Dischi separati per OS/Dati/Logging disk
    • Montare i dischi dati con noatime
    • impostare i buffer readahead su < 32 sul disco dati.
    • Utilizzare idealmente xfs su ext4 sui dischi dati.
    • Se su RedHat in esecuzione in una VM, assicurati che il pool di entropia sia sempre > 1K bit (usa rngtools se necessario)
  7. Disattiva Transparent Huge Pages su Linux

    AEM esegue letture/scritture a grana fine, mentre Transparent Huge Pages di Linux è ottimizzata per operazioni di grandi dimensioni, per cui si raccomanda di disabilitare Transparent Huge Pages quando si utilizza lo spazio di archiviazione Mongo o Tar.

Abilitazione dei workflow transitori

I workflow transitori possono essere utilizzati per qualsiasi workflow:

  • vengono eseguiti spesso.
  • non occorre la cronologia del workflow.

In queste situazioni, genereranno un aumento delle prestazioni.

Questo caso d'uso è tipicamente soddisfatto quando vi sono elevati volumi di ingestione di risorse.

Seguire la procedura documentata sul sito https://helpx.adobe.com/it/experience-manager/6-4/assets/using/performance-tuning-guidelines.html#Workflows

Regolazione delle code di lavoro di Sling

Il caricamento in massa di risorse di grandi dimensioni è in genere un processo ad alta intensità di risorse. Per impostazione predefinita, il numero di thread simultanei per coda di lavoro è uguale al numero di core della CPU. Come tale, questa impostazione del valore può influire sulle prestazioni complessive e un elevato consumo di Java heap.

Adobe consiglia di non superare il 50% dei core della CPU. Per regolare questo valore, vai qui:

http://<host>:<port>/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration

Imposta queue.maxparallel ad un valore che rappresenta il 50% dei core della CPU del server che ospita l'istanza AEM. Ad esempio, per 8 core della CPU, imposta il valore a 4.

Sintonizza il tuo Archivio Oak

Per prima cosa assicurati di avere l'ultima versione di Oak installata per l'istanza di AEM 6. Controlla la pagina degli hotfix consigliati menzionata in precedenza.

Ottimizzazioni del motore/indice di query Oak

  1. Crea indici Oak personalizzati per tutte le query di ricerca utilizzate di frequente.

    • Per informazioni su come analizzare le query lente vedi questo articolo.
    • Crea gli indici personalizzati sotto l'opzioneoak:index nodo per tutte le proprietà di ricerca con cui si desidera effettuare la ricerca seguendo questo articolo.
    • Per ogni indice personalizzato basato su Lucene, prova a impostare l'impostazione includedPaths (String[]) per limitare l'indice in modo che si applichi solo a determinati percorsi di contenuto. Quindi limita le ricerche applicabili ai percorsi inclusi nell'indice.
  2. Parametri JVM

    Aggiungi questi parametri JVM nello script di avvio di AEM per evitare che le query espansive sovraccarichino i sistemi. Nota che questi sono valori predefiniti a partire da AEM 6.3.

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

    L'opzione seguente potrebbe anche migliorare le prestazioni, ma cambia il significato del result size call. In particolare, nel calcolo delle dimensioni, vengono considerate solo le restrizioni delle query che fanno parte dell'indice utilizzato.

    Inoltre, le ACL non vengono applicate ai risultati, quindi i nodi che non sono visibili alla sessione corrente saranno comunque inclusi nel conteggio restituito. Come tale, il conteggio restituito può essere superiore al numero effettivo di risultati e il conteggio accurato può essere determinato solo attraverso l'iterazione dei risultati:

  3. Configurazione dell'indice Lucene

    Open/system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderServiceand

    • abilita CopyOnRead (abilitato di default da AEM 6.2)
    • abilita CopyOnWrite (abilitato di default da AEM 6.2)
    • abilita i file di indice prefetch (abilitati di default da AEM 6.2)

    Per ulteriori informazioni sui parametri disponibili, consulta il sito http://jackrabbit.apache.org/oak/docs/query/lucene.html

    Poiché non occorre indicizzare alcuni percorsi, puoi procedere come segue:

    In CRXDE Lite, vai a /oak:index/lucene, imposta una proprietà stringa multivalore (String[])chiamata excludedPaths con questi valori /var, /etc/workflow/instances, /etc/replication.

  4. Archiviazione dati

    Se utilizzi AEM Assets o disponi di un'applicazione AEM che utilizza ampiamente i file binari, Adobe consiglia di utilizzare un esternodatastore. L'utilizzo di un datastore esterno aiuta a garantire le massime prestazioni.  Vedi documentazioneper istruzioni dettagliate.

    Quando si utilizza un FileDataStore, regola cacheSizeInMB su una percentuale dell'heap disponibile. Un valore conservativo è pari al 2% di heap massima.  Per esempio, per 8 GB di heap:

    maxCachedBinarySize=1048576
    cacheSizeInMB=164

    Nota che maxCachedBinarySize è impostato su 1 MB (1048576). Come tale, memorizza in cache solo file che hanno un massimo di 1 MB.  Regolare l'impostazione a un valore minore può avere senso.

    Con un numero elevato di binari, è preferibile massimizzare le prestazioni. Pertanto, Adobe raccomanda che un'applicazione esternadatastorevenga usata al posto degli archivi di 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 è impostata a un livello troppo alto. Per esempio, se hai impostato la dimensione massima dell'heap a 8 GB (-Xmx8g) e ti aspetti che AEM e la tua applicazione utilizzino un heap combinato di 4 GB, allora ha senso impostare cacheSizeInMB a 82 invece di 164. Nell'intervallo del 2-10% dell'heap massima è una configurazione sicura. Tuttavia, Adobe consiglia di convalidare le modifiche alle impostazioni con il test di carico, monitorando anche l'utilizzo della memoria.

Regolazione dello spazio di archiviazione Mongo

  1. Dimensione della cache MongoBlobStore: Ilblobstoreè usato per archiviare e leggere grandi oggetti binari. Internamente, è implementato l'archivio con cache che divide ibinari inblocchi relativamente piccoli (dati o codice hash o hash indiretto), in modo che ogni blocco sia memorizzato. 

    In un'impostazione predefinita, il MongoBlobStore utilizza una dimensione di cache fissa di 16MB.  Per le implementazioni in cui è disponibile più RAM e si accede frequentemente allo spazio di archiviazione blob (ad esempio, quando l'indice Lucene è grande), aumenta la dimensione della cache. Questa dimensione della cache si applica solo quando si usa MongoBlobStore (predefinito), non quando si usa un'opzione esternablobstore.

    • È possibile configurare la dimensione della cache (in MB) tramite l'impostazione blobCacheSize su DocumentNodeStoreService.
      Per esempio: blobCacheSize=1024
    • Controlla anche la lista di controllo di AEM-MongoDB.
  2. Dimensione della cache dei documenti: per ottimizzare le prestazioni dei nodi di lettura da MongoDB è necessario regolare le dimensioni della cache di DocumentNodeStore.  La dimensione predefinita della cache è impostata a 256 MB ed è distribuita tra le varie cache utilizzate in DocumentNodeStore. Vedi http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

    • Puoi configurare la dimensione della cache (MB) tramite l'impostazione della cache su DocumentNodeStoreService. Per esempio, cache=2048.
    • Imposta tutte le seguenti configurazioni di cache incrx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config e quindi carica il test con vari valori per vedere quale sia la configurazione ottimale per il tuo ambiente. Nota che la percentuale di cache rimanente è data alla cache del documento:
      • cache=2048
      • nodeCachePercentage=35
      • childrenCachePercentage=20
      • diffCachePercentage=30
      • docChildrenCachePercentage=10
    • Con la configurazione di cui sopra, le percentuali totali sono pari al 95%.  Il restante 5% della cache è dato a documentCache.
      documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache
    • Mentre distribuisci le percentuali di cache, assicurati che la cache lasciata per documentCache non sia molto grande. Cioè, mantienila al massimo a ~500 MB o meno; un documentCache di grandi dimensioni può portare ad un aumento del tempo necessario per eseguire l'invalidazione della cache.
  3. Impostazioni della cache in AEM 6.2 con Oak 1.4.x:

    • In AEM 6.2, sono state apportate modifiche al funzionamento di queste impostazioni di cache. In AEM 6.2 con Oak 1.4, c'è una nuova cache: prevDocCache.  È possibile configurare questa cache utilizzando l'impostazione prevDocCachePercentage.Predefinitoè 4.
    • LadocumentCache usa i restanti MB di cache (impostazione cache meno le dimensioni di tutte le altre cache):
       documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache - prevDocCache
  4. Implementa la checklist di produzione MongoDB
    http://docs.mongodb.org/manual/administration/production-checklist/ - secondo il supporto di Mongo DB, molti degli elementi lì presentihannoun grande impatto sulle prestazioni. Per qualsiasi domanda, contatta direttamente il supporto MongoDB.

  5. Prestazioni di lettura: Aggiungi questo parametro della stringa di query all'URL del Mongo DB URL su ogni nodo AEM: ?readPreference=secondaryPreferred
    Questo parametro comunica al sistema di eseguire letture dal secondario che fornisce alcune prestazioni di lettura aggiuntive.

  6. Aumenta il pool di thread per oak-observation: apri /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory
    Imposta il nome su oak-observation e imposta la dimensione minima e massima del pool su 20.

  7. Aumenta la lunghezza della coda di osservazione: crea un file chiamato com.adobe.granite.repository.impl.SlingRepositoryManager.cfg contenente il parametro oak.observation.queue‐length=50000 . Posizionalo sotto la cartella /crx-­‐quickstart/install.

  8. Evita le query con esecuzione lunga: Imposta la proprietà del sistema nei parametri JVM : -Doak.mongo.maxQueryTimeMS=60000 per evitare che le query durino più di 1 minuto.

Regolazione spazio di archiviazione Tar

I micro kernel non chiamano direttamente i file mappati in memoria. Tuttavia, JDK utilizza internamente file con mappatura in memoria per una lettura efficiente. Su alcuni sistemi operativi Windows a 64 bit potrebbe non riuscire a ripulire i file mappati in memoria e consumare tutta la memoria del sistema operativo nativo. Assicurati di installare le patch/hotfix relative alle prestazioni daMicrosoft(vedi KB 2731284) e Oracle.

Revisione TarMK pulita (compattazione)

Per AEM 6.2, Adobe consiglia di utilizzare la compattazione offline, tramite lo strumento oak-run. Controlla anche la Guida alla manutenzione di AEM 6.x.

All'avvio di AEM 6.3, la compattazione online (nota anche come pulizia della revisione online) è abilitata automaticamente. Vedi questa pagina per ulteriori informazioni. Visita anche le Domande frequenti sulla pulizia della revisione online.

Cloud Manager per i clienti di Adobe Managed Services (AMS)

Cloud Manager (solo per i clienti AMS) consente ai clienti di garantire un'implementazione di AEM di successo con un test guidato delle prestazioni e l'autoridimensionamento.

Come procedere?

Per ulteriori informazioni sui problemi di prestazioni di AEM:

  1. Partecipa alla discussione nei forum di Adobe per qualsiasi domanda o feedback.

  2. Ottieni il supporto ufficiale

    1. Raccogli i seguenti dati:
      1. Output del profiler
      2. Dump dei thread
      3. Tutti i file di log
    2. Contatta il Servizio Clienti di AEM

Questo prodotto è concesso in licenza in base alla licenza di Attribuzione-Non commerciale-Condividi allo stesso modo 3.0 Unported di Creative Commons.  I post su Twitter™ e Facebook non sono coperti dai termini di Creative Commons.

Note legali   |   Informativa sulla privacy online