AEM 6.x | Consejos de ajuste del rendimiento

Implemente y ejecute las pruebas de carga que simulen escenarios realistas tanto en instancias de autor como de publicación. Investigar y definir la carga esperada es un paso crucial en este proceso. Este paso le ayuda a demostrar si la aplicación AEM, la arquitectura y la instalación de AEM funcionan bien una vez que estén en funcionamiento en un entorno de producción.

Los resultados de este ejercicio ayudan a determinar si existe un error de configuración, un problema de aplicación, de tamaño, de hardware o de otro tipo que afecte al rendimiento del sistema. Consulte también las directrices de rendimiento y las directrices de seguimiento.

Además de las pruebas de carga, las pruebas de estrés ayudan a definir la carga máxima que el sistema puede soportar. Esta prueba puede ayudarle a prepararse para los picos de tráfico. Puede encontrar más información sobre las pruebas de rendimiento aquí.

Instale los service packs AEM recomendados, cumulative fix packs y las correcciones rápidas:

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

Si está usando un servidor Windows, entonces revise este artículo.

Si está planeando cargar grandes cantidades de recursos (imágenes, vídeos, etc.) en AEM, asegúrese de aplicar las prácticas recomendadas de recursos.

Provea la memoria RAM suficiente y evite la saturación de IO.

Si tiene la intención de ejecutar la producción a cualquier escala, el entorno Linux debería disponer de la misma cantidad de memoria RAM que los archivos tar del segmento entre la compactación sin conexión (o los picos de compactación en línea).  Además, lo siguiente evita la saturación de IO.

• Discos de sistema operativo/datos/registro separados.

• Montardo de discos de datos con noatime.

• Ajustar los búfer de readahead a < 32 en el disco de datos.

• Lo ideal es usar xfs sobre ext4 en los discos de datos.

• Si RedHat se ejecuta en una VM, asegúrese de que el grupo de entropía sea siempre > 1K bits (use rngtools si es necesario).

Desactive Transparent Huge Pages en Linux

AEM realiza lecturas/escrituras más detalladas, mientras que Linux Transparent Huge Pages está optimizado para operaciones grandes, por lo que se recomienda desactivar Transparent Huge Pages cuando se utiliza el almacenamiento Mongo o Tar.

Cree índices de Oak personalizados para todas las consultas de búsqueda más frecuentes.

• Para obtener información sobre cómo analizar consultas lentas, consulte este artículo.
• Cree los índices personalizados bajo el nodooak:index para todas las propiedades de búsqueda con las que desea buscar al consultar este artículo.
  
• Para cada índice personalizado basado en Lucene, intente establecer el entorno includedPaths (String[]) para restringir que el índice solo se aplique a determinadas rutas de contenido. A continuación, restrinja las búsquedas aplicables a las rutas que incluye el índice.

Parámetros de JVM

Añada estos parámetros de JVM en el script de inicio AEM para evitar que las consultas expansivas sobrecarguen los sistemas. Tenga en cuenta que estos son los valores predeterminados a partir de AEM 6.3.

• -Doak.queryLimitInMemory=500000 (vea también la documentación de Oak)
  
• -Doak.queryLimitReads=100000 (ver también la documentación de Oak)
  
• -Dupdate.limit=250000 (solo para DocumentNodeStore, p. ej. MongoMK,RDBMK)

La siguiente opción también podría mejorar el rendimiento, pero cambia el significado de la llamada de tamaño de resultado. En especial, solo se tienen en cuenta las restricciones de consulta que forman parte del índice utilizado al calcular el tamaño.

Además, las ACL no se aplican a los resultados, por lo que los nodos que no son visibles en la sesión actual se incluyen en el recuento devuelto. Como tal, el conteo devuelto puede ser mayor que el número real de resultados y el conteo preciso solo puede determinarse mediante la iteración a través de los resultados:

• -Doak.fastQuerySize=true (vea también el tamaño del resultado en la documentación de Oak)

Configuración del índice de Lucene

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

• Habilite CopyOnRead (habilitado por defecto desde AEM 6.2)
  
• Habilite CopyOnWrite (habilitado de forma predeterminada desde AEM 6.2)
  
• Habilite los archivos de índice Prefetch (habilitados por defecto desde AEM 6.2)

Consulte http://jackrabbit.apache.org/oak/docs/query/lucene.html para obtener más información sobre los parámetros disponibles.

Debido a que algunas rutas no necesitan ser indexadas, puede hacer lo siguiente:

En CRXDE Lite, vaya a /oak:index/lucene, establezca una propiedad de cadena de valores múltiples (String[])named excludedPaths with these values /var, /etc/workflow/instances, /etc/replication.

Almacenamiento de datos

Si utiliza AEM Assets o tiene una aplicación de AEM que utiliza archivos binarios de forma extensiva, Adobe recomienda que utilice unalmacén de datos externo.. El uso de un almacén de datos externo ayuda a garantizar el máximo rendimiento.  Véase documentaciónpara instrucciones detalladas.

Cuando utilice un FileDataStore, ajuste cacheSizeInMB a un porcentaje de su pila disponible. Un valor conservador es el 2 % de la pila máxima.  Por ejemplo, para una pila de 8 GB:

maxCachedBinarySize=1048576
cacheSizeInMB=164

Tenga en cuenta que maxCachedBinarySize está establecido en 1 MB (1048576). Como tal, solo almacena en caché archivos que tienen un máximo de 1 MB.  Ajustar este ajuste a un valor más pequeño también puede tener sentido.

Cuando se trata de un gran número de binarios, se desea maximizar el rendimiento. Por lo tanto, Adobe recomienda que se utilice un almacén de datos externoalmacén de datos externo.en lugar de las tiendas de nodos por defecto. Además, Adobe recomienda que ajuste los siguientes parámetros:

• maxCachedBinarySize=10485760
• cacheSizeInMB=4096

Tamaño de la caché de MongoBlobStore:blobstorese utiliza para almacenar y leer objetos binarios de gran tamaño. Internamente, se implementa el almacén con la caché que dividebinarios enbloques relativamente pequeños (datos o código hash o hash indirecto), para que cada bloque quepa en la memoria. 

En una configuración predeterminada, MongoBlobStore utiliza un tamaño de caché fijo de 16 MB.  Para implementaciones en las que hay más RAM disponible y se accede con frecuencia al almacenamiento en masa (por ejemplo, cuando el índice de Lucene es grande), aumente el tamaño de la caché. Este tamaño de caché solo se aplica cuando se utiliza MongoBlobStore (de forma predeterminada), no cuando se utiliza un blobstore externo.blobstore.

• Puede configurar el tamaño de caché (en MB) mediante la configuración de blobCacheSize en DocumentNodeStoreService.
  Por ejemplo: blobCacheSize=1024
• Revise también la lista de control de AEM-MongoDB.

Tamaño de la caché del documento: para optimizar el rendimiento de los nodos de lectura de MongoDB es necesario ajustar el tamaño de las cachés de DocumentNodeStore.  El tamaño predeterminado de la caché es de 256 MB, que se distribuye entre varias cachés utilizadas en DocumentNodeStore. Vea http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

• Puede configurar el tamaño de caché (MB) mediante la configuración de caché en DocumentNodeStoreService. Por ejemplo, cache=2048.
• Configure todas las siguientes configuraciones de caché encrx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.configand, luego cargue la prueba con varios valores para ver cuál es la configuración óptima para su entorno. Tenga en cuenta que el porcentaje de caché restante se asigna a la caché del documento:
  
  • caché=2048
  • nodeCachePercentage=35
  • childrenCachePercentage=20
  • diffCachePercentage=30
  • docChildrenCachePercentage=10
• Con la configuración anterior, el total de los porcentajes es el 95 %.  El 5 % restante de la caché se asigna a documentCache.
  documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache
  
• Al distribuir los porcentajes de caché, asegúrese de que la caché que queda para documentCache no sea muy grande. Es decir, manténgalo en un máximo de ~500 MB o menos. Un gran documentCache puede aumentar el tiempo necesario para realizar la invalidación de la caché.

Configuración de caché en AEM 6.2 con Oak 1.4.x:

• En AEM 6.2, se hicieron cambios en la forma en que funcionan estas configuraciones de caché. En AEM 6.2 con Oak 1.4, hay una nueva caché: prevDocCache.  Puede configurar esta caché utilizando la configuración prevDocCachePercentage.Tamaño4.
• LadocumentCache utiliza los MB de caché restantes (configuración de caché menos el tamaño de todas las demás cachés):
    documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache - prevDocCache

Implementación la lista de control de producción de MongoDB
http://docs.mongodb.org/manual/administration/production-checklist/: de acuerdo con el soporte técnico de Mongo DB, muchos de los elementos de ahítienenun gran impacto en el rendimiento. Para cualquier pregunta, póngase en contacto directamente con el servicio de soporte técnico de MongoDB.

Rendimiento de lectura: añada este parámetro de cadena de consulta a la URL de su base de datos Mongo en todos los nodos de AEM: ?readPreference=secondaryPreferred
Este parámetro le indica al sistema que haga lecturas del secundario, lo que le da un mayor rendimiento de lectura.

Aumento del grupo de subprocesos para oak-observation: abra /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory
Configure el nombre a oak-observation, y establezca el tamaño mínimo y máximo del grupo en 20.

Aumento de la longitud de la cola de observación: cree un archivo llamado com.adobe.granite.repository.impl.SlingRepositoryManager.cfg que contenga el parámetro oak.observation.queue‐length=50000. Colóquelo en la carpeta /crx-­‐quickstart/install.

Evación de consultas de larga duración: establezca la propiedad del sistema en los parámetros de JVM: -Doak.mongo.maxQueryTimeMS=60000 para evitar que las consultas duren más de 1 minuto.

• Lea este artículo para obtener una visión más detallada sobre cómo optimizar el rendimiento general del sitio.
• Supervise su entorno de AEM para identificar los posibles atascos.
• Revise los problemas críticos comunes de AEM y las recomendaciones relacionadas.
• Aproveche las prácticas recomendadas para solucionar problemas de rendimiento

Únase al debate en los foros de Adobe para cualquier pregunta o comentario.

Obtenga soporte oficial

1. Recopile los siguientes datos:
   
   1. Resultados del generador de perfiles
   2. Volcados de subprocesos
   3. Todos los archivos de registro
2. Contacte con el servicio de atención al cliente de AEM.