AEM.x | Consejos de ajuste de rendimiento

Última actualización: 2024-02-05

Conozca estrategias y sugerencias eficaces para optimizar el rendimiento de Adobe Experience Manager AEM (), las pruebas de carga, los parámetros de JVM y el ajuste de la caché.

Descripción

Entorno 

  • Adobe Experience Manager 6.4
  • Adobe Experience Manager 6.5

Problema/Síntomas

El tiempo de respuesta es deficiente cuando los autores editan contenido o los sitios web responden lentamente a las solicitudes de los visitantes.

Estas sugerencias de ajuste de rendimiento pueden ayudar a acelerar las consultas y el rendimiento.

Causa

AEM Los siguientes factores influyen en los problemas de rendimiento en las:

  • Diseño incorrecto
  • Código de aplicación
  • Falta de almacenamiento en caché
  • Configuración de E/S de disco incorrecta
  • Tamaño de memoria
  • Ancho de banda y latencia de red
  • AEM se instala en algunas versiones de windows 2008 y 2012 en las que la administración de la memoria es un problema
  • AEM Modificar las configuraciones listas para usar como se describe a continuación puede ayudar a mejorar el rendimiento en los entornos de trabajo de los clientes de la.

Resolución

Prevención de problemas de rendimiento

A continuación se indican algunos pasos que puede seguir para asegurarse de que encuentra y corrige los problemas de rendimiento antes de que afecten a los usuarios:

  1. Implemente y ejecute 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. AEM AEM Este paso le ayuda a demostrar si la aplicación, la arquitectura y la instalación de la de trabajo de la aplicación funcionarán correctamente una vez que esté activa en un entorno de producción.
    Los resultados de este ejercicio ayudan a determinar si hay una configuración incorrecta, un problema de aplicación, un tamaño, un problema de hardware u otro problema que afecte al rendimiento del sistema. Consulte también la directrices de rendimiento y directrices de supervisión.

  2. Además de las pruebas de carga, las pruebas de esfuerzo ayudan a definir la carga máxima que puede manejar el sistema. 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. AEM Instale los paquetes de servicio recomendados de la, los paquetes fijos acumulativos y las revisiones: Actualizaciones de la versión de Adobe Experience Manager.

  4. Si utiliza el servidor de Windows, revise este artículo.

  5. AEM Si planea cargar grandes cantidades de recursos (imágenes, vídeos, etc.) en, asegúrese de aplicar la variable, que está seleccionada en la lista de recursos de la lista de distribución de recursos de la lista de distribución de recursos Prácticas recomendadas de Assets.

  6. Aprovisionar suficiente RAM y evitar la saturación de E/S
    Si tiene intención de ejecutar la producción a cualquier escala, el entorno Linux debe aprovisionarse con tanta RAM como los archivos tar de segmentos crezcan entre la compactación sin conexión (o los picos de compactación en línea). Además, lo siguiente evitará la saturación de E/S.

    • Separar SO, datos y discos de registro
    • Montar discos de datos con Noatime.
    • Establezca los búferes de lectura anticipada en 32 en el disco de datos.
    • Lo ideal es utilizar XFS sobre ext4 en los discos de datos.
    • Si RedHat se está ejecutando en una VM, asegúrese de que el grupo de entropía siempre esté activo > 1K bits (utilice rngtools si es necesario)
  7. Deshabilitar páginas enormes transparentes en Linux
    AEM realiza lecturas/escrituras de grano fino, mientras que las páginas enormes transparentes de Linux están optimizadas para operaciones grandes, por lo que se recomienda deshabilitar las páginas enormes transparentes cuando se utiliza el almacenamiento Mongo o Tar.

  8. Habilitar flujos de trabajo transitorios
    Los flujos de trabajo transitorios se pueden utilizar para cualquier flujo de trabajo que:

    • se ejecutan a menudo.
    • no necesita el historial del flujo de trabajo.

    Generarán un aumento del rendimiento en esas situaciones.
    Este caso de uso se suele cumplir cuando hay grandes volúmenes de ingesta de recursos.
    Siga el procedimiento documentado en Recursos de ajuste de rendimiento.

  9. Ajuste de colas de trabajos de Sling
    La carga masiva de recursos grandes suele ser un proceso que consume muchos recursos. De forma predeterminada, el número de subprocesos simultáneos 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 de Java.
    El Adobe recomienda no exceder el 50% de los núcleos de CPU. Para ajustar este valor, vaya a lo siguiente: https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration Set queue.maxparallel AEM a un valor que representa el 50 % de los núcleos de CPU del servidor que aloja la instancia de la instancia de la. Por ejemplo, para 8 núcleos de CPU, establezca el valor en 4.

  10. Ajuste del repositorio de Oak
    AEM En primer lugar, asegúrese de que tiene instalada la última versión de Oak para su instancia de. Consulte la página de revisiones recomendadas que se ha mencionado anteriormente.

    Optimizaciones del motor de consultas/índice de Oak

    • Cree índices de Oak personalizados para todas las consultas de búsqueda utilizadas frecuentemente.

      • Para obtener información sobre cómo analizar consultas lentas, consulte esto artículo.
      • Cree los índices personalizados en el nodo oak: index para todas las propiedades de búsqueda con las que desee buscar siguiendo este procedimiento artículo.
      • Para cada índice personalizado basado en Lucene, intente establecer la configuración includedPaths (String) para restringir el índice de modo que solo se aplique a ciertas rutas de contenido. A continuación, limite las búsquedas aplicables a las rutas incluidas en el índice.
    • Parámetros de JVM\

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

      • Doak.queryLimitInMemory=500000 (consulte también Documentación de Oak)
      • Doak.queryLimitReads=100000 (consulte también Documentación de Oak)
      • Dupdate.limit=250000 (solo para DocumentNodeStore; p. ej., MongoMK, RDBMK)

      La siguiente opción también puede mejorar el rendimiento, pero cambia el significado de la llamada de tamaño del 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 para la sesión actual se incluirán en el recuento devuelto. Como tal, el recuento devuelto puede ser mayor que el número real de resultados y el recuento preciso solo se puede determinar iterando los resultados:

      Precaución: habilitar fastQuerySize da como resultado respuestas de consulta más rápidas. AEM Sin embargo, devuelve recuentos de resultados inexactos para algunas consultas. Si confía en recuentos de resultados precisos en su aplicación, no utilice fastQuerySize.

    • Configuración del índice Lucene\

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

      • habilitar CopiarAlLeer AEM (habilitado de forma predeterminada desde la versión 6.2 de la aplicación de)
      • habilitar CopyOnWrite AEM (habilitado de forma predeterminada desde la versión 6.2 de la aplicación de)
      • habilitar Recuperar archivos de índice previamente AEM (habilitado de forma predeterminada desde la versión 6.2 de la aplicación de)

      Consulte https://jackrabbit.apache.org/oak/docs/query/lucene.html para obtener más información sobre los parámetros disponibles Dado que algunas rutas no necesitan indexarse, puede hacer lo siguiente: En CRXDE Lite, vaya a /oak:index/lucene, establezca una propiedad de cadena de varios valores (String)denominada excludedPaths con estos valores /var, /etc/workflow/instances, /etc/replication.

    • Almacén de datos\

      Si utiliza AEM Assets AEM o tiene una aplicación que utiliza archivos binarios de forma extensa, Adobe recomienda utilizar un almacén de datos externo. El uso de un almacén de datos externo ayuda a garantizar el máximo rendimiento. Consulte documentación para obtener instrucciones detalladas.
      Al utilizar un FileDataStore, ajuste cacheSizeInMB a un porcentaje del montón disponible. Un valor conservador es el 2 % del montón máximo. Por ejemplo, para un montón de 8 GB:

      • maxCachedBinarySize=1048576
      • cacheSizeInMB=164

      Tenga en cuenta que maxCachedBinarySize se establece en 1 MB (1048576). Como tal, solo almacena en caché archivos que tengan un máximo de 1 MB. También puede ser recomendable ajustar este valor a un valor más pequeño.
      Cuando se trata de un gran número de binarios, se desea maximizar el rendimiento. Por lo tanto, Adobe recomienda utilizar un almacén de datos externo en lugar de los almacenes de nodos predeterminados. Además, Adobe recomienda ajustar los siguientes parámetros:

      • maxCachedBinarySize=10485760
      • cacheSizeInMB=4096

      Nota: La cacheSizeInMB La configuración de puede hacer que el proceso de Java se quede sin memoria si está configurado demasiado alto. AEM Por ejemplo, si tiene el tamaño máximo de pila establecido en 8 GB (-Xmx8g) y espera que y su aplicación utilicen una pila combinada de 4 GB, tiene sentido establecer cacheSizeInMB en 82 en lugar de 164. En el rango del 2-10% del montón máximo es una configuración segura. Sin embargo, Adobe recomienda validar los cambios de configuración con pruebas de carga y supervisar también el uso de la memoria.

  11. Ajuste del almacenamiento de Mongo

    • Tamaño de caché de MongoBlobStore: El blobstore se usa para almacenar y leer objetos binarios grandes. Internamente, se implementa el almacén con caché que divide los binarios en bloques relativamente pequeños (datos o código hash o hash indirecto), de modo que cada bloque cabe 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 de blob (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 (predeterminado), no cuando se utiliza un almacén de blobs externo.

      • Puede configurar el tamaño de la caché (en MB) mediante la configuración de blobCacheSize en DocumentNodeStoreService.
        Por ejemplo: blobCacheSize=1024
      • AEM Por favor, revise también la información sobre la versión de MongoDB en lista de comprobación.
    • Tamaño de caché de documento: Para optimizar el rendimiento de la lectura de nodos de MongoDB, debe ajustar los tamaños de caché de DocumentNodeStore. El tamaño predeterminado de la caché se establece en 256 MB, que se distribuye entre varias memorias caché utilizadas en DocumentNodeStore. Consulte http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

      • Puede configurar el tamaño de la caché (MB) mediante la configuración de caché en DocumentNodeStoreService. Por ejemplo, cache=2048.
      • Establezca todas las siguientes configuraciones de caché en crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config y 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é de documentos:
        • cache=2048
        • nodeCachePercentage=35
        • childrenCachePercentage=20
        • diffCachePercentage=30
        • docChildrenCachePercentage=10
      • Con la configuración anterior, los porcentajes suman 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 documentCache grande puede provocar un aumento en el tiempo necesario para invalidar la caché.
    • AEM Configuración de caché en 6.2 con Oak 1.4.x:

      • AEM En la versión 6.2 se han realizado cambios en la forma en que funciona esta configuración de la caché. AEM En la versión 6.2 con Oak 1.4, hay una nueva caché: prevDocCache. Puede configurar esta caché con el ajuste prevDocCachePercentage. El valor predeterminado es 4.
      • documentCache utiliza el MB de caché restante (configuración de caché menos el tamaño de todas las demás cachés): documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache
    • Implemente la lista de comprobación de producción de MongoDB:\

      https://docs.mongodb.org/manual/administration/production-checklist/ - según la compatibilidad con Mongo DB, muchos de los elementos tienen un gran impacto en el rendimiento. Para cualquier pregunta, póngase en contacto directamente con el Soporte técnico de MongoDB.

    • Rendimiento de lectura: AEM Añada este parámetro de cadena de consulta a la URL de Mongo DB en cada nodo de: ?readPreference=secondaryPreferred
      Este parámetro indica al sistema que realice lecturas desde el secundario, lo que proporciona cierto rendimiento de lectura añadido.

    • Aumente el pool de hilos para la observación del roble: open /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory Establezca el nombre en oak-observed y establezca el tamaño mínimo y máximo del grupo en 20.

    • Aumentar longitud de cola de observación: Cree un archivo llamado com.adobe.granite.repository.impl.SlingRepositoryManager.cfg parámetro contenedor oak.observed.queue-length=50000. Colóquelo debajo de la etiqueta /crx—quickstart/install carpeta.

    • Evitar consultas de larga ejecución: establezca la propiedad del sistema en los parámetros de JVM: -Doak.mongo.maxQueryTimeMS=60000 para evitar que las consultas se ejecuten durante más de 1 minuto.

  12. Ajuste del almacenamiento Tar
    Los microkernels no llaman directamente a los archivos asignados en memoria. Sin embargo, JDK utiliza internamente archivos asignados en memoria para una lectura eficiente. En determinados sistemas operativos Windows de 64 bits podría no limpiar los archivos asignados en memoria y consumir toda la memoria del sistema operativo nativo. Asegúrese de instalar los parches o revisiones relacionados con el rendimiento desde microsoft (consulte KB 2731284) y Oracle.

    Una opción alternativa es deshabilitar el modo de asignación de memoria agregando tarmk.mode=32 in SegmentNodeStoreService.config hasta que se resuelva el problema del sistema operativo. La desventaja de deshabilitar hace que la E/S sea intensiva. Asegúrese de aumentar el límite de bloqueo de página de E/S.

  13. Revisión de TarMK limpia (compactación)
    AEM A partir de la versión 6.3, la compactación en línea (también conocida como limpieza de revisión en línea) está activada de forma predeterminada. Consulte esta página para obtener más información.

  14. Cloud Manager para clientes de Adobe Managed Services (AMS)
    Cloud Manager AEM (Solo para clientes de AMS) permite a los clientes garantizar una implementación correcta de la aplicación con pruebas de rendimiento guiadas y escalado automático.

En esta página