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 lento para la edición y las solicitudes de los visitantes

El tiempo de respuesta es escaso cuando los autores editan el contenido o los sitios web responden lentamente a las peticiones de los visitantes.

Causa

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.

Prevención de problemas de rendimiento

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:

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

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

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

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

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

  6. 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).
  7. 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.

Habilitación de los flujos de trabajo transitorios

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

Ajuste de las colas de trabajos de Sling

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.

Ajuste del repositorio Oak

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.

Optimizaciones de Oak Query Engine/Index

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

    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:

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

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

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.

Ajuste de almacenamiento de Mongo

  1. 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.
  2. 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é.
  3. 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
  4. 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.

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

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

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

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

Ajuste del almacenamiento de tar

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 demicrosoft(vea KB 2731284) y Oracle.

Limpieza de revisión de TarMK (compactación)

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 para clientes de Adobe Managed Services (AMS)

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.

¿Qué hacer a continuación?

Para obtener más ayuda sobre los problemas de rendimiento de AEM:

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

Esta obra está autorizada con arreglo a la licencia de Reconocimiento-NoComercial-CompartirIgual 3.0 Unported de Creative Commons.  Los términos de Creative Commons no cubren las publicaciones en Twitter™ y Facebook.

Avisos legales   |   Política de privacidad en línea