Nota:

Usted está leyendo la versión AEM 5.x de consejos de ajuste de rendimiento. Este artículo también está disponible para las versiones 6.x

Problema

El rendimiento de mi instancia CQ5 es pobre.

Causa

Los problemas de rendimiento en CQ5 pueden deberse a muchas cosas en combinación. La causa más común se debe al código de aplicación. Sin embargo, puede tomar algunas medidas dentro de la configuración de CQ5 para mejorar el rendimiento.

Resolución

Para mejorar el rendimiento general de la instancia de CQ, Adobe recomienda que haga lo siguiente (en las instancias de autor y publicación).

 

1. Instale las correcciones recomendadas

Esto se aplica a AEM 5.6.1. Lea atentamente https://helpx.adobe.com/es/experience-manager/kb/cq561-available-hotfixes.html e instale las correcciones recomendadas para sus módulos, especialmente el relacionado con el rendimiento.

 

2. Aumento de bundleCacheSize en CRX

Aumente el parámetro bundleCacheSize de TarPersistenceManager de CRX haciendo lo siguiente:

Edite cada uno de los elementos de PersistenceManager en su repository.xml y todos los archivos de su workspace.xml añadiendo el siguiente parámetro dentro del elemento <PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager" />:
Por ejemplo:

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="bundleCacheSize" value="256" /> </PersistenceManager>

De forma predeterminada, esta caché está configurada en 8 MB. Auméntela a por lo menos 256 MB, o incluso 512 MB, dependiendo de la cantidad de memoria que pueda asignar a la JVM. Si tiene una JVM con el parámetro Xmx ajustado en 10 GB, establezca bundleCacheSize en 1024 MB. Si está utilizando una JVM de 32 bits en Windows, su parámetro Xmx es probablemente menor de 1500 MB. Por lo tanto, un valor razonable para el bundleCacheSize es de 128 MB. Adobe recomienda que actualice a una JVM de 64 bits para asignar más memoria a la pila de JVM.

3. Utilice FineGrainedISMLocking (solo CRX 1.4.x)

Para configurarlo, añada la siguiente clase ISMLocking al workspace.xml y al repository.xml, directamente después del bloque SearchIndex:

<Workspace ...> ... </SearchIndex> <ISMLocking class="org.apache.jackrabbit.core.state.FineGrainedISMLocking"/> ... </Workspace>

4. Desactive AssetSynchronizationService de CQ5 (solo CQ5.3)

AssetSynchronizationService sincroniza activos de repositorios montados (por ejemplo, LiveLink, Documentum). Cuando está habilitado, se ha observado que este servicio asigna periódicamente muchos objetos que son recolectados como residuos. Por lo tanto, tiene un impacto en el rendimiento de la JVM. Si no utiliza repositorios montados, puede desactivar este servicio.

Por configuración, el período de sincronización puede ajustarse a un número mayor de segundos (de forma predeterminada, 300), lo que impide su ejecución.

El paquete adjunto establece el período de sincronización en un año, por lo que desactiva el servicio.

5. Establezca el parámetro resultFetchSize del índice de búsqueda de CRX

Si el conjunto de resultados de una consulta jcr es grande, entonces la carga del conjunto completo y la comprobación de ACL en ellos es costosa. Para remediarlo, limite el tamaño de recuperación a 50 en el elemento SearchIndex en workspace.xml:

<param name="resultFetchSize" value="50"/> Por ejemplo:






<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="resultFetchSize" value="50"/> </SearchIndex>

6. Establezca el parámetro de búsqueda cacheSize de CRX

La búsqueda cacheSize también se puede establecer en el elemento SearchIndex en workspace.xml. Ajuste este parámetro a 100000:

<param name="cacheSize" value="100000" />

Por ejemplo:

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="resultFetchSize" value="50"/> <param name="cacheSize" value="100000" /> </SearchIndex>

 

Este parámetro se documenta aquí.

7. Desactive el agrupamiento de CRX (CRX 1.4, 2.0, 2.1)

Cuando se ejecuta un sistema con una alta carga de escritura (por ejemplo, con importaciones masivas de activos DAM), a veces, incluso las ganancias de rendimiento de escritura relativamente pequeñas pueden ayudar a alcanzar el punto de referencia de rendimiento requerido. En tal caso, considere desactivar el diario de agrupamiento en su implementación.

De forma predeterminada, CRX está configurado para funcionar en modo de clúster. Pero si solo hay una instancia en el clúster, entonces añade algo de sobrecarga de E/S. Para obtener rendimiento de escritura, desactive la agrupación en clúster.

En repository.xml, comente la sección <Cluster ...>...</Cluster>.
A continuación, utilice el script de ejemplo para mover los archivos del repositorio del modo de conjunto al modo individual.

Antes de realizar este procedimiento, comuníquese con DayCare o con su Gestor de cuenta para discutir esta opción. La mayoría de las implementaciones de los clientes se ejecutan con las configuraciones predeterminadas y registradas en un diario. Es mejor probar este script en una instancia de prueba haciéndolo en un sistema de producción.

8. Desactive la actualización del buscador de contenido y la carga automática (solo en la instancia de autor)

Consulte este artículo [2]

9. Desactive la subgeneración de activos de DAM

Consulte este artículo [3]

10. Limite el tamaño máximo del diario en CRX

Si los archivos de diario de CRX en compartir/diario crecen demasiado, su aplicación puede sufrir alguna desaceleración. Consulte este artículo [4] para saber cómo limitar el tamaño del diario y el número máximo de archivos.

11. Desactive los flujos de trabajo DAM en publicar (Instancia de Publish CQ5.3 solamente)

Consulte este artículo [5]

12. Desactive el verificador de vínculos

Se puede obtener una mejora en el rendimiento desactivando el verificador de vínculos (especialmente con AEM 5.6.1). Solo hágalo si decide que no lo necesita en su entorno.

El verificador de vínculos valida que las URL de los recursos en la dirección de sus páginas sean accesibles. Para ello, realiza una solicitud HTTP HEAD.

Si un vínculo se marca como inválido en su autoría, el inspector de vínculos muestra un icono de cadena rota a su alrededor. Si un vínculo está marcado como no válido en la publicación, se elimina la etiqueta <a href="..."> que lo rodea.

Algunos clientes lo desactivan en sus instancias de publicación para obtener un mayor rendimiento. Aunque esto aumenta el rendimiento, los vínculos rotos afectan al SEO de su sitio. Considere los efectos cuidadosamente antes de decidir desactivarlo.

Para obtener instrucciones sobre cómo deshabilitar esta función, consulte este artículo [6].

13. Almacenamiento en caché del índice Tar PM

Hasta CRX 2.1

El uso de un trabajo cron para leer el archivo index*.tar de vez en cuando puede ayudar a mejorar el rendimiento, ya que el índice tar se almacena en la caché de E/S del hardware. En UNIX, puede cargar el index*.tar utilizando el comando “cat index*.tar > /dev/null”. Hacer esto cada hora debería ayudar a mejorar el rendimiento del Tar Persistence Manager mientras se ejecuta el método TarFile.readFully().

Desde CRX 2.2 + paquete de correcciones 2.2.0.26 y posteriores

Compruebe el tamaño global de los archivos index_*.tar en el espacio de trabajo crx.default, aumente el tamaño máximo de pila en dicho tamaño y configure el parámetro indexInMemory como verdadero para la sección TarPersistenceManager del espacio de workspace.xml:

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
    <param name="indexInMemory" value="true" />
</PersistenceManager>

El espacio de memoria requerido para un nodo JCR es de 128 bytes. Si el archivo index*.tar más grande de un espacio de trabajo es de 1 GB, significa que hay unos 16 millones de nodos en este espacio de trabajo, ya que cada nodo necesita 64 bytes de espacio en disco. El uso de la opción de índice en memoria requiere unos 2 GB de espacio de memoria (el doble del tamaño del archivo para calcular el espacio de memoria necesario, ya que puede haber dos versiones por archivo de índice durante la fusión de índices).

14. Expiración de la caché LDAP

Para mejorar el rendimiento y reducir la latencia durante el proceso de autenticación, es bueno aumentar la expiración de la caché LDAP y puede establecer cache.expiration en 86400 (un día) en su configuración LDAP.

15. Optimice el índice de lucene para ganar espacio en disco y eficiencia

Consulte este artículo [7]

Referencias

[1] http://wiki.apache.org/jackrabbit/Search
[2] Cambiar el intervalo de actualización de ContentFinder
[3] Eliminar la generación de subactivos del flujo de trabajo de DAM
[4] El diario consume demasiado espacio en disco
[5] Desactivar los flujos de trabajo de DAM al publicar
[6] Desactive Linkchecker
[7] Optimice el índice de lucene para ganar espacio en disco y eficiencia

 

Se aplica a

CQ 5.x, CRX 2.X

Descargar

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