AEM.x | Consejos de ajuste de rendimiento

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 las directrices de rendimiento y las directrices de supervisión.

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. Encontrará más información sobre las pruebas de rendimiento aquí.

AEM Instale los paquetes de servicio recomendados, los paquetes de correcciones acumulativos y las revisiones: Actualizaciones de la versión de Adobe Experience Manager.

Si usa Windows Server, revise este artículo.

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

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 máquina virtual, asegúrese de que el grupo de entropía siempre tenga > bits de 1K (use rngtools si es necesario)

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 al usar el almacenamiento Mongo o Tar.

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 Ajuste del rendimiento de Assets.

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 la siguiente dirección: https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration
AEM Establezca queue.maxparallel en un valor que represente el 50% de los núcleos de CPU del servidor que aloja la instancia de la. Por ejemplo, para 8 núcleos de CPU, establezca el valor en 4.

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

Optimizaciones del índice/motor de consultas de Oak

• Cree índices Oak personalizados para todas las consultas de búsqueda usadas con frecuencia.

  • 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 desee buscar siguiendo este 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:

  • Doak.fastQuerySize=true (consulte también Tamaño de resultado en documentación de Oak)

  Precaución: si se habilita fastQuerySize, las respuestas a la consulta serán 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 use fastQuerySize.

• Configuración del índice Lucene
  Abra /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService y

  • AEM habilitar CopyOnRead (habilitado de forma predeterminada desde la versión 6.2 de la aplicación de manera predeterminada)
  • AEM habilitar CopyOnWrite (habilitado de forma predeterminada desde la versión 6.2 de la aplicación de manera predeterminada)
  • AEM habilitar Archivos de índice de recuperación previa (habilitado de forma predeterminada desde la versión 6.2 de la aplicación de forma predeterminada).

  Consulte https://jackrabbit.apache.org/oak/docs/query/lucene.html para obtener más información sobre los parámetros disponibles
  Como 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 la 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 está establecido 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 configuración cacheSizeInMB puede hacer que el proceso Java se quede sin memoria si se establece 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.

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 Revise también la lista de comprobación de MongoDBde la base de datos de.

• Tamaño de caché de documento: Para optimizar el rendimiento de 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. Ver 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 la caché en la versión 6.2 de 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

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

• AEM Rendimiento de lectura: Agregue este parámetro de cadena de consulta a la dirección 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.

• Aumentar el grupo de subprocesos para la observación de oak: abra /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 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.observed.queue-length=50000. Colóquelo en la carpeta /crx-quickstart/install.

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

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 las revisiones o revisiones relacionadas con el rendimiento desde microsoft (consulte KB 2731284) y el Oracle.

Otra opción es deshabilitar el modo de asignación de memoria agregando tarmk.mode=32 en 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.

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.

Cloud Manager para usuarios de Adobe Managed Services (AMS)
Cloud Manager AEM (solo usuarios de AMS) le permite garantizar una implementación exitosa de la aplicación con pruebas de rendimiento guiadas y escalado automático.