Nota:
Está leyendo la versión 6.x de Adobe Experience Manager sobre consejos de ajuste del rendimiento. Este artículo también está disponible para la versión 5.x.
El tiempo de respuesta es escaso cuando los autores editan el contenido o los sitios web responden lentamente a las peticiones de los visitantes.
Los siguientes factores influyen en los problemas de rendimiento en AEM:
- Diseño inapropiado
- Código de aplicación
- Falta de almacenamiento en caché
- Configuración de entrada/salida de disco defectuoso
- Tamaño de la memoria
- Ancho de banda y latencia de la red
- AEM instalado en algunas versiones selectas de Windows 2008 y 2012 donde la gestión de la memoria es un problema
- Modificar las configuraciones predeterminadas como se describe a continuación puede ayudar a mejorar el rendimiento en AEM.
A continuación, se indican algunos pasos que puede seguir para asegurarse de encontrar y solucionar los problemas de rendimiento antes de que afecten a sus usuarios:
-
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.
-
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).
-
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.
Los flujos de trabajo transitorios se pueden utilizar para cualquier flujo de trabajo que:
- se ejecutan a menudo,
- no necesitan el historial del flujo de trabajo.
Generan un aumento del rendimiento en esas situaciones.
Este caso de uso se cumple típicamente cuando hay altos volúmenes de consumo de recursos.
Siga el procedimiento documentado en https://helpx.adobe.com/es/experience-manager/6-4/assets/using/performance-tuning-guidelines.html#Workflows
La carga masiva de grandes recursos suele ser un proceso muy intensivo en recursos. De forma predeterminada, el número de subprocesos concurrentes por cola de trabajos es igual al número de núcleos de CPU. Como tal, esta configuración de valor puede causar un impacto general en el rendimiento y un alto consumo de pila en Java.
Adobe recomienda que no supere el 50 % de los núcleos de la CPU. Para ajustar este valor, vaya a lo siguiente:
http://<host>:<port>/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration
Establezca queue.maxparallel en un valor que represente el 50 % de los núcleos de CPU del servidor que aloja su instancia de AEM. Por ejemplo, para 8 núcleos de CPU, ajuste el valor a 4.
Primero asegúrese de que tiene la última versión de Oak instalada para su instancia de AEM 6. Consulte la página de correcciones rápidas recomendada mencionada anteriormente.
-
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 nodo
oak: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)
- -Doak.queryLimitInMemory=500000 (vea también 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.
- Habilite CopyOnRead (habilitado por defecto desde AEM 6.2)
-
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 un
almacén de datos externo. . El uso de un almacén de datos externo ayuda a garantizar el máximo rendimiento. Véasedocumentación para 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=164Tenga 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 externo
almacé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
Nota:
La configuración cacheSizeInMB puede causar que el proceso Java se quede sin memoria si está configurado a un valor demasiado alto. Por ejemplo, si tiene el tamaño máximo de pila establecido en 8 GB (-Xmx8g) y espera que AEM y su aplicación utilicen una pila combinada de 4 GB, entonces tiene sentido establecer cacheSizeInMB en 82 en lugar de 164. El rango de 2-10 % de la pila máxima es una configuración segura. Sin embargo, Adobe recomienda que valide los cambios de configuración con pruebas de carga y que supervise la utilización de la memoria.
-
Tamaño de la caché de MongoBlobStore:
blobstore se utiliza para almacenar y leer objetos binarios de gran tamaño. Internamente, se implementa el almacén con la caché que dividebinarios en bloques 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.
- Puede configurar el tamaño de caché (en MB) mediante la configuración de blobCacheSize en DocumentNodeStoreService.
-
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é en
crx -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ño 4. - La
documentCache 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
- 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.
-
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ítienen un gran impacto en el rendimiento. Para cualquier pregunta, póngase en contacto directamente con el servicio de soporte técnico de MongoDB.
Los microkernels no llaman directamente a los archivos asignados en la memoria. Sin embargo, JDK utiliza internamente archivos asignados en la memoria para una lectura eficiente. Es posible que en algunos sistemas operativos de Windows de 64 bits no se limpien los archivos asignados a la memoria y que se consuma toda la memoria nativa del sistema operativo. Asegúrese de instalar los parches o las correcciones relacionadas con el rendimiento de
- Una opción alternativa es deshabilitar el modo de asignación de memoria añadiendo
tarmk .mode=32 en SegmentNodeStoreService.config hasta que se resuelva el problema del sistema operativo. El inconveniente de la desactivación hace que I/O sea intenso. Asegúrese de aumentar el límite de bloqueo de página de I/O.
Para AEM 6.2, Adobe recomienda utilizar la compactación sin conexión, por medio de la herramienta Oak-run. Consulte también la Guía de mantenimiento de AEM 6.x.
Al iniciar AEM 6.3, la compactación en línea (también conocida como limpieza de revisión en línea) está activada de forma predeterminada. Si desea obtener más información, consulte este artículo. Visite también las preguntas frecuentes de limpieza de revisiones en línea.
Cloud Manager (solo clientes de AMS) permite a los clientes garantizar el éxito de la implementación de AEM con una prueba de rendimiento guiada y un escalado automático.
-
- 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
- Recopile los siguientes datos:
- Contacte con el servicio de atención al cliente de AEM.
- Recopile los siguientes datos: