Show Menu
TEMAS×

Directrices de rendimiento

En esta página se proporcionan directrices generales sobre cómo optimizar el rendimiento de la implementación de AEM. Si es nuevo en AEM, vaya a las páginas siguientes antes de empezar a leer las directrices de rendimiento:
A continuación se muestran las opciones de implementación disponibles para AEM (desplácese hasta ver todas las opciones):
AEM
Producto
Topología
Sistema operativo
Servidor de aplicaciones
JRE
Seguridad
Micro Kernel
Almacén de datos
Indexación
Servidor web
Explorador
Marketing Cloud
Sitios
No es de alta disponibilidad
Windows
CQSE
Oracle
LDAP
Tar
Segmento
Propiedad
Apache
Edge
Destino
Recursos
Publish-HA
Solaris
WebLogic
IBM
SAML
MongoDB
Archivo
Lucene
IIS
IE
Análisis
Communities
Author-CS
Red Hat
WebSphere
HP
Oauth
RDB/Oracle
S3/Azure
Solr
iPlanet
FireFox
Campaign
Forms
Descarga de autor
HP-UX
Tomcat
RDB/DB2
MongoDB
Chrome
Social
Móvil
Author-Cluster
IBM AIX
JBoss
RDB/MySQL
RDBMS
Safari
Audience
Varios sitios
ASRP
SUSE
RDB/SQLServer
Recursos
Comercio
MSRP
Apple OS
Activación
Dynamic Media
JSRP
Móvil
Brand Portal
J2E
AoD
LiveFile
Pantallas
Seguridad del documento
Process Mgt
aplicación de escritorio
Las directrices de rendimiento se aplican principalmente a los sitios AEM.

Cuándo utilizar las directrices de rendimiento

Debe utilizar las directrices de rendimiento en las siguientes situaciones:
  • Primera implementación : Al planificar la implementación de Sitios o recursos AEM por primera vez, es importante comprender las opciones disponibles al configurar el micronúcleo, el almacén de nodos y el almacén de datos (en comparación con la configuración predeterminada). Por ejemplo, cambiar la configuración predeterminada del almacén de datos para TarMK al almacén de datos de archivos.
  • Actualización a una nueva versión : Al actualizar a una nueva versión, es importante comprender las diferencias de rendimiento en comparación con el entorno de ejecución. Por ejemplo, la actualización de AEM 6.1 a 6.2 o de AEM 6.0 CRX2 a 6.2 OAK.
  • El tiempo de respuesta es lento : Cuando la arquitectura seleccionada de Nodestore no cumple con sus requisitos, es importante comprender las diferencias de rendimiento en comparación con otras opciones de topología. Por ejemplo, implementar TarMK en lugar de MongoMK, o usar un almacén de datos de archivos en lugar de un almacén de datos de Amazon S3 o Microsoft Azure.
  • Agregando más autores : Cuando la topología TarMK recomendada no cumple los requisitos de rendimiento y el cambio de tamaño del nodo Autor ha alcanzado la capacidad máxima disponible, es importante comprender las diferencias de rendimiento en comparación con el uso de MongoMK con tres o más nodos Autor. Por ejemplo, implementar MongoMK en lugar de TarMK.
  • Adición de más contenido : Cuando la arquitectura del almacén de datos recomendada no cumple sus requisitos, es importante comprender las diferencias de rendimiento en comparación con otras opciones del almacén de datos. Ejemplo: uso del almacén de datos de Amazon S3 o Microsoft Azure en lugar de un almacén de datos de archivos.

Introducción

Este capítulo ofrece una descripción general de la arquitectura de AEM y sus componentes más importantes. También proporciona directrices de desarrollo y describe los escenarios de prueba utilizados en las pruebas de referencia TarMK y MongoMK.

La plataforma de AEM

La plataforma AEM consta de los siguientes componentes:
Para obtener más información sobre la plataforma AEM, consulte Qué es AEM .

Arquitectura de AEM

Hay tres componentes importantes para una implementación de AEM. Instancia de autor que utilizan los autores, editores y aprobadores de contenido para crear y revisar contenido. Cuando se aprueba el contenido, se publica en un segundo tipo de instancia denominado Instancia de publicación desde el que los usuarios finales acceden a él. El tercer bloque de creación es el despachante , que es un módulo que gestiona el almacenamiento en caché y el filtrado de URL y que está instalado en el servidor web. Para obtener información adicional sobre la arquitectura de AEM, consulte Escenarios de implementación típicos.

Micro Kernels

Los microkernels actúan como gestores de persistencia en AEM. Existen tres tipos de micronúcleos que se utilizan con AEM: TarMK, MongoDB y Base de datos relacional (bajo soporte restringido). Elegir uno que se adapte a sus necesidades depende de la finalidad de la instancia y del tipo de implementación que se esté planteando. Para obtener información adicional sobre Micro Kernels, consulte la página Implementaciones recomendadas.

Nodestore

En AEM, los datos binarios se pueden almacenar independientemente de los nodos de contenido. La ubicación en la que se almacenan los datos binarios se denomina Almacén de datos, mientras que la ubicación de los nodos y las propiedades de contenido se denomina Almacén de nodos.
Adobe recomienda que TarMK sea la tecnología de persistencia predeterminada que utilizan los clientes para las instancias de AEM Author y Publish.
El micronúcleo de la base de datos relacional está bajo soporte restringido. Póngase en contacto con el Servicio de atención al cliente de Adobe antes de utilizar este tipo de micronúcleo.

Data Store

Cuando se trata de un gran número de binarios, se recomienda utilizar un almacén de datos externo en lugar de los almacenes de nodos predeterminados para maximizar el rendimiento. Por ejemplo, si su proyecto requiere un gran número de recursos multimedia, almacenarlos en el archivo o en el almacén de datos de Azure/S3 hará que el acceso a ellos sea más rápido que almacenarlos directamente en una base de datos Mongo.
Para obtener más información sobre las opciones de configuración disponibles, consulte Configuración de nodos y almacenes de datos.
Adobe recomienda elegir la opción de implementar AEM en los servicios web de Azure o Amazon (AWS) mediante los servicios gestionados de Adobe, donde los clientes se beneficiarán de un equipo que tenga la experiencia y las habilidades de implementar y operar AEM en estos entornos informáticos en la nube. Consulte nuestra documentación adicional sobre los servicios administrados de Adobe.
Para obtener recomendaciones sobre cómo implementar AEM en Azure o AWS, fuera de los servicios gestionados de Adobe, le recomendamos encarecidamente que trabaje directamente con el proveedor de nube o con uno de nuestros socios que admita la implementación de AEM en el entorno de nube que elija. El proveedor o socio de nube seleccionado es responsable de las especificaciones de tamaño, el diseño y la implementación de la arquitectura que admitirán para satisfacer sus requisitos específicos de rendimiento, carga, escalabilidad y seguridad.
Para obtener más información, consulte también la página de requisitos Plataformas compatibles técnicos.

Búsqueda

En esta sección se enumeran los proveedores de índice personalizados que se utilizan con AEM. Para obtener más información sobre la indexación, consulte Consultas de Oak e Indexación .
Para la mayoría de las implementaciones, Adobe recomienda utilizar el índice Lucene. Debe utilizar Solr únicamente para la escalabilidad en implementaciones especializadas y complejas.

Directrices de desarrollo

Debe desarrollarse para AEM con el objetivo de rendimiento y escalabilidad . A continuación se presentan varias prácticas recomendadas que puede seguir:
DO
  • Aplicar separación de presentación, lógica y contenido
  • Usar las API de AEM existentes (por ejemplo: Sling) y herramientas (por ejemplo: Replicación)
  • Desarrollar en el contexto del contenido real
  • Desarrollar para lograr una máxima capacidad de caché
  • Minimizar el número de guardas (por ejemplo: mediante flujos de trabajo transitorios)
  • Asegúrese de que todos los puntos finales HTTP son RESTful
  • Restringir el alcance de la observación JCR
  • Tenga en cuenta el subproceso asincrónico
NO
  • No utilice las API de JCR directamente, si puede
  • No cambie /libs, sino que utilice superposiciones
  • No utilizar consultas siempre que sea posible
  • No utilice Sling Bindings para obtener los servicios OSGi en el código Java, sino más bien utilice:
    • @Referencia en un componente DS
    • @Inyectar en un modelo Sling
    • sling.getService() en una clase Sightly Use
    • sling.getService() en un JSP
    • a ServiceTracker
    • acceso directo al registro de servicios OSGi
Para obtener más información sobre el desarrollo de AEM, consulte Desarrollo: conceptos básicos . Para obtener información sobre las prácticas recomendadas adicionales, consulte Prácticas recomendadas de desarrollo .

Escenarios de referencia

Todas las pruebas de referencia mostradas en esta página se han realizado en un laboratorio.
Los escenarios de prueba detallados a continuación se utilizan para las secciones de referencia de los capítulos TarMK, MongoMk y TarMK vs MongoMk. Para ver qué escenario se utilizó para una prueba de referencia concreta, lea el campo Escenario de la tabla Especificaciones Prueba comparativa del rendimiento de TarMK técnicas.
Escenario de un solo producto
AEM Assets:
  • Interacciones del usuario: Recursos de exploración / Recursos de búsqueda / Descargar recurso / Leer metadatos de recursos / Actualizar metadatos de recursos / Cargar recursos / Ejecutar flujo de trabajo de carga de recursos
  • Modo de ejecución: usuarios simultáneos, interacción única por usuario
Escenario de mezcla de productos
AEM Sites + Assets:
  • Interacciones del usuario del sitio: Leer página de artículos / Leer página / Crear párrafo / Editar párrafo / Crear página de contenido / Activar página de contenido / Búsqueda de autor
  • Interacciones del usuario de recursos: Recursos de exploración / Recursos de búsqueda / Descargar recurso / Leer metadatos de recursos / Actualizar metadatos de recursos / Cargar recursos / Ejecutar flujo de trabajo de carga de recursos
  • Modo de ejecución: usuarios simultáneos, interacciones mixtas por usuario
Caso de uso vertical
Medios:
  • Leer página de artículos (27,4%), página de lectura (10,9%), crear sesión (2,6%), activar página de contenido (1,7%), crear página de contenido (0,4%), crear párrafo (4,3%), editar párrafo (0,9%), componente de imagen (0,9%), recursos de exploración (20%), leer metadatos de recursos (8,5%), descargar recursos (4,2%), Recurso de búsqueda (0,2%), Actualizar metadatos del recurso (2,4%), Cargar recurso (1,2%), Examinar proyecto (4,9%), Leer proyecto (6,6%), Proyecto Agregar recurso (1,2%), Proyecto Agregar sitio (1,2%), Crear proyecto (0,1%), Búsqueda de autor (0,4%)
  • Modo de ejecución: usuarios simultáneos, interacciones mixtas por usuario

TarMK

Este capítulo proporciona directrices generales de rendimiento para TarMK que especifican los requisitos mínimos de arquitectura y la configuración de configuración. También se proporcionan pruebas de referencia para una mayor aclaración.
Adobe recomienda que TarMK sea la tecnología de persistencia predeterminada que utilizan los clientes en todos los escenarios de implementación, tanto para las instancias de AEM Author como para las de Publish.
Para obtener más información sobre TarMK, consulte Escenarios de implementación y Almacenamiento de etiquetas .

Directrices de arquitectura mínima de TarMK

Las directrices de arquitectura mínimas que se presentan a continuación son para entornos de producción y sitios de alto tráfico. Estas no son las especificaciones Requisitos previos mínimas necesarias para ejecutar AEM.
Para establecer un buen rendimiento al utilizar TarMK, debe comenzar con la siguiente arquitectura:
  • Una instancia de Autor
  • Dos instancias de publicación
  • Dos despachantes
A continuación se ilustran las directrices de arquitectura para los sitios de AEM y Recursos AEM.
Si se comparte el almacén de datos del archivo, la replicación sin binarios debe activarse en ON.
Directrices de arquitectura de etiquetas para sitios AEM
Directrices de arquitectura de etiquetas para AEM Assets

Directrices de configuración de TarMK

Para un buen rendimiento, debe seguir las directrices de configuración que se presentan a continuación. Para obtener instrucciones sobre cómo cambiar la configuración, consulte esta página .
Configuración Parámetro Value Descripción
Colas de trabajo de Sling queue.maxparallel Establezca el valor en la mitad del número de núcleos de CPU. De forma predeterminada, el número de subprocesos simultáneos por cola de trabajos es igual al número de núcleos de CPU.
Cola de flujo de trabajo transitoria de granito Max Parallel Establezca el valor en la mitad del número de núcleos de CPU
Parámetros de JVM
Doak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
500000
100 000
250000
Verdadero
Agregue estos parámetros JVM en la secuencia de comandos de inicio de AEM para evitar que las consultas extensivas sobrecarguen los sistemas.
Configuración del índice Lucene
CopyOnRead
CopyOnWrite
Prefetch Index Files
Activado
Activado
Activado
Para obtener más información sobre los parámetros disponibles, consulte esta página .
Almacén de datos = Almacén de datos S3
maxCachedBinarySize
cacheSizeInMB
1048576 (1 MB) o inferior
2-10% del tamaño máximo del montón
Consulte también Configuraciones del almacén de datos .
Flujo de trabajo de recursos de actualización DAM Transient Workflow comprobado Este flujo de trabajo administra la actualización de recursos.
Reescritura de metadatos DAM Transient Workflow comprobado Este flujo de trabajo administra la escritura XMP en el binario original y establece la fecha de la última modificación en JCR.

Prueba comparativa del rendimiento de TarMK

Especificaciones técnicas

Las pruebas de referencia se realizaron con arreglo a las siguientes especificaciones:
Nodo de autor
Servidor
Hardware de metal desnudo (HP)
Sistema operativo
RedHat Linux
CPU/núcleos
CPU Intel(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos
RAM
32GB
Disco
Magnético
Java
Oracle JRE versión 8
JVM Heap
16GB
Producto
AEM 6.2
Nodestore
TarMK
Almacén de datos
Archivo DS
Escenario
Producto único: Recursos / 30 subprocesos simultáneos

Resultados del indicador de rendimiento

Los números que se presentan a continuación se han normalizado a 1 como base de referencia y no son los números de rendimiento reales.

MongoMK

La razón principal para elegir el servidor de persistencia MongoMK sobre TarMK es escalar las instancias horizontalmente. Esto significa tener dos o más instancias de autor activas ejecutándose en todo momento y usando MongoDB como sistema de almacenamiento de persistencia. La necesidad de ejecutar más de una instancia de autor se debe en general al hecho de que la CPU y la capacidad de memoria de un único servidor, que admite todas las actividades de creación concurrentes, ya no son sostenibles.
Para obtener más información sobre TarMK, consulte Escenarios de implementación y Almacenamiento Almacenamiento de Mongo mongol.

Directrices de arquitectura mínima de MongoMK

Para establecer un buen rendimiento al utilizar MongoMK, debe comenzar con la siguiente arquitectura:
  • Tres instancias de creación
  • Dos instancias de publicación
  • Tres instancias de MongoDB
  • Dos despachantes
En entornos de producción, MongoDB siempre se utilizará como conjunto de réplicas con un primario y dos secundarios. Las lecturas y las escrituras van a la primaria y las lecturas pueden ir a la secundaria. Si el almacenamiento no está disponible, uno de los secundarios se puede reemplazar por un árbitro, pero los conjuntos de réplicas de MongoDB siempre deben estar compuestos por un número impar de instancias.
Si se comparte el almacén de datos del archivo, la replicación sin binarios debe activarse en ON.

Directrices de configuración de MongoMK

Para un buen rendimiento, debe seguir las directrices de configuración que se presentan a continuación. Para obtener instrucciones sobre cómo cambiar la configuración, consulte esta página .
Configuración Parámetro Valor (predeterminado) Descripción
Colas de trabajo de Sling queue.maxparallel Establezca el valor en la mitad del número de núcleos de CPU. De forma predeterminada, el número de subprocesos simultáneos por cola de trabajos es igual al número de núcleos de CPU.
Cola de flujo de trabajo transitoria de granito Max Parallel Establezca el valor en la mitad del número de núcleos de CPU.
Parámetros de JVM
Doak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
Doak.mongo.maxQueryTimeMS
500000
100 000
250000
Verdadero
60000
Agregue estos parámetros JVM en la secuencia de comandos de inicio de AEM para evitar que las consultas extensivas sobrecarguen los sistemas.
Configuración del índice Lucene
CopyOnRead
CopyOnWrite
Prefetch Index Files
Activado
Activado
Activado
Para obtener más información sobre los parámetros disponibles, consulte esta página .
Almacén de datos = Almacén de datos S3
maxCachedBinarySize
cacheSizeInMB
1048576 (1 MB) o inferior
2-10% del tamaño máximo del montón
Consulte también Configuraciones del almacén de datos .
DocumentNodeStoreService
cache
nodeCachePercentage
childrenCachePercentage
diffCachePercentage
docChildrenCachePercentage
prevDocCachePercentage
persistentCache
2048
35 (25)
20 (10)
30 (5)
10 (3)
4 (4)
./cache,size=2048,binario=0,-compacto,-compress
El tamaño predeterminado de la caché se establece en 256 MB.
Tiene impacto en el tiempo que lleva realizar la invalidación de caché.
observación de robles
thread pool
length
min & max = 20
50000

Prueba comparativa de rendimiento de MongoMK

Especificaciones técnicas

Las pruebas de referencia se realizaron con arreglo a las siguientes especificaciones:
Nodo de creación
Nodo MongoDB
Servidor
Hardware de metal desnudo (HP)
Hardware de metal desnudo (HP)
Sistema operativo
RedHat Linux
RedHat Linux
CPU/núcleos
CPU Intel(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos
CPU Intel(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos
RAM
32GB
32GB
Disco
Magnético: >1.000 IOPS
Magnético: >1.000 IOPS
Java
Oracle JRE versión 8
N/D
JVM Heap
16GB
N/D
Producto
AEM 6.2
MongoDB 3.2 WiredTiger
Nodestore
MongoMK
N/D
Almacén de datos
Archivo DS
N/D
Escenario
Producto único: Recursos / 30 subprocesos simultáneos
Producto único: Recursos / 30 subprocesos simultáneos

Resultados del indicador de rendimiento

Los números que se presentan a continuación se han normalizado a 1 como base de referencia y no son los números de rendimiento reales.

TarMK vs MongoMK

La regla básica que debe tenerse en cuenta al elegir entre los dos es que TarMK está diseñado para el rendimiento, mientras que MongoMK se utiliza para la escalabilidad. Adobe recomienda que TarMK sea la tecnología de persistencia predeterminada que utilizan los clientes en todos los escenarios de implementación, tanto para las instancias de AEM Author como para las de Publish.
La razón principal para elegir el servidor de persistencia MongoMK sobre TarMK es escalar las instancias horizontalmente. Esto significa tener dos o más instancias de autor activas ejecutándose en todo momento y usando MongoDB como sistema de almacenamiento de persistencia. La necesidad de ejecutar más de una instancia de autor suele deberse a que la CPU y la capacidad de memoria de un único servidor, que admite todas las actividades de creación concurrentes, ya no son sostenibles.
Para obtener más información sobre TarMK y MongoMK, consulte Implementaciones recomendadas .

Directrices TarMK vs MongoMk

Beneficios de TarMK
  • Diseñado para aplicaciones de administración de contenido
  • Los archivos son siempre coherentes y se pueden realizar copias de seguridad con cualquier herramienta de backup basada en archivos
  • Proporciona un mecanismo de conmutación por error: consulte Cold Standby para obtener más información
  • Proporciona almacenamiento de datos confiable y de alto rendimiento con un overhead operacional mínimo
  • Menor TCO (costo total de propiedad)
Criterios para elegir MongoMK
  • Número de usuarios con nombre conectados en un día: en miles o más
  • Número de usuarios simultáneos: en cientos o más
  • Volumen de ingestas de recursos por día: en cientos de miles o más
  • Volumen de las ediciones de página por día: en cientos de miles o más
  • Volumen de búsquedas por día: en decenas de miles o más

Prueba comparativa TarMK vs MongoMK

Los números que se presentan a continuación se han normalizado a 1 como base de referencia y no son números de rendimiento reales.

Especificaciones técnicas del escenario 1

Nodo OAK de creación Nodo MongoDB
Servidor Hardware de metal desnudo (HP) Hardware de metal desnudo (HP)
Sistema operativo RedHat Linux RedHat Linux
CPU/núcleos CPU Intel(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos CPU Intel(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos
RAM 32GB 32GB
Disco Magnético: >1.000 IOPS Magnético: >1.000 IOPS
Java Oracle JRE versión 8 N/D
JVM Heap16 GB 16GB N/D
Producto AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore TarMK o MongoMK N/D
Almacén de datos Archivo DS N/D
Escenario
Producto único: Recursos / 30 subprocesos simultáneos por ejecución

Resultados del indicador de rendimiento del escenario 1

Especificaciones técnicas del escenario 2

Para habilitar el mismo número de autores con MongoDB que con un sistema TarMK, necesita un clúster con dos nodos AEM. Un clúster MongoDB de cuatro nodos puede gestionar 1,8 veces el número de autores que una instancia TarMK. Un clúster MongoDB de ocho nodos puede gestionar 2,3 veces el número de autores que una instancia TarMK.
Nodo TarMK de creación Nodo MongoMK de creación Nodo MongoDB
Servidor AWS c3.8xlarge AWS c3.8xlarge AWS c3.8xlarge
Sistema operativo RedHat Linux RedHat Linux RedHat Linux
CPU/núcleos 32 32 32
RAM 60GB 60GB 60GB
Disco SSD: 10.000 IOPS SSD: 10.000 IOPS SSD: 10.000 IOPS
Java Oracle JRE versión 8 Oracle JRE versión 8 N/D
JVM Heap16 GB 30GB 30GB N/D
Producto AEM 6.2 AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore TarMK MongoMK N/D
Almacén de datos Archivo DS Archivo DS N/D
Escenario
Caso de uso vertical: Medios / 2000 subprocesos simultáneos

Resultados del indicador de rendimiento del escenario 2

Directrices de escalabilidad de arquitectura para sitios y recursos de AEM

Resumen de las directrices de rendimiento

Las directrices presentadas en esta página se pueden resumir de la siguiente manera:
  • TarMK con File Datastore es la arquitectura recomendada para la mayoría de los clientes:
    • Topología mínima: una instancia de autor, dos instancias de publicación, dos despachantes
    • Replicación sin binarios activada si se comparte el almacén de datos de archivos
  • MongoMK con File Datastore es la arquitectura recomendada para la escalabilidad horizontal del nivel Autor:
    • Topología mínima: tres instancias de creación, tres instancias de MongoDB, dos instancias de publicación, dos despachantes
    • Replicación sin binarios activada si se comparte el almacén de datos de archivos
  • Nodestore debe almacenarse en el disco local, no en un almacenamiento de información conectado en red (NAS)
  • Al usar Amazon S3 :
    • El almacén de datos de Amazon S3 se comparte entre el nivel Autor y Publicación
    • La replicación sin binario debe estar activada
    • La colección de elementos no utilizados del almacén de datos requiere una primera ejecución en todos los nodos Autor y Publicar y, a continuación, una segunda ejecución en Autor
  • El índice personalizado debe crearse además del índice predeterminado basado en las búsquedas más comunes
    • Los índices de Lucene deben usarse para los índices personalizados
  • La personalización del flujo de trabajo puede mejorar sustancialmente el rendimiento , por ejemplo, eliminando el paso del vídeo en el flujo de trabajo "Actualizar recurso", desactivando los oyentes que no se utilizan, etc.
Para obtener más información, consulte también la página Implementaciones recomendadas.