AEM 6.4 ha llegado al final de la compatibilidad ampliada y esta documentación ya no se actualiza. Para obtener más información, consulte nuestra períodos de asistencia técnica. Buscar las versiones compatibles here.
Esta página proporciona directrices generales sobre cómo optimizar el rendimiento de la implementación de AEM. Si es nuevo en AEM, vaya a las siguientes páginas 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 |
Sites |
No HA |
Windows |
CQSE |
Oracle |
LDAP |
Tar |
Segmento |
Propiedad |
Apache |
Edge |
Destino |
Assets |
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 |
Audiencia |
Varios sitios |
ASRP |
SUSE |
|
|
|
RDB/SQLServer |
|
|
|
|
Assets |
Comercio |
MSRP |
Apple OS |
|
|
|
|
|
|
|
|
Activación |
Dynamic Media |
JSRP |
|
|
|
|
|
|
|
|
|
Móvil |
Brand Portal |
J2E |
|
|
|
|
|
|
|
|
|
|
AoD |
|
|
|
|
|
|
|
|
|
|
|
LiveFile |
|
|
|
|
|
|
|
|
|
|
|
Screens |
|
|
|
|
|
|
|
|
|
|
|
Seguridad del documento |
|
|
|
|
|
|
|
|
|
|
|
Mgt de proceso |
|
|
|
|
|
|
|
|
|
|
|
Aplicación de escritorio de |
|
|
|
|
|
|
|
|
|
|
|
Las directrices de rendimiento se aplican principalmente a AEM Sites.
Debe utilizar las directrices de rendimiento en las situaciones siguientes:
Este capítulo ofrece información general sobre 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 AEM consta de los siguientes componentes:
Para obtener más información sobre la plataforma AEM, consulte ¿Qué es AEM.
Hay tres componentes básicos importantes para una implementación AEM. La variable 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 donde los usuarios finales acceden a ella. El tercer bloque de creación es el Dispatcher que es un módulo que gestiona el almacenamiento en caché y el filtrado de URL y está instalado en el servidor web. Para obtener información adicional sobre la arquitectura de AEM, consulte Escenarios de implementación habituales.
Los microkernels actúan como gestores de persistencia en AEM. Existen tres tipos de microkernels utilizados con AEM: TarMK, MongoDB y Base de Datos Relacional (bajo soporte restringido). La elección de una que se ajuste a sus necesidades depende del propósito de la instancia y del tipo de implementación que esté considerando. Para obtener información adicional sobre los microkernels, consulte la Implementaciones recomendadas página.
En AEM, los datos binarios se pueden almacenar de forma independiente 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 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 Micro Kernel de la Base de Datos Relacional está bajo soporte restringido. Contacto Servicio de atención al cliente de Adobe antes de utilizar este tipo de Micro Kernel.
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 el proyecto requiere un gran número de recursos multimedia, almacenarlos en el Archivo o el Almacén de datos de Azure/S3 hará que el acceso a ellos sea más rápido que almacenarlos directamente en un MongoDB.
Para obtener más información sobre las opciones de configuración disponibles, consulte Configuración de almacenes de datos y nodos.
Adobe recomienda elegir la opción de implementar AEM en Azure o Amazon Web Service (AWS) mediante Adobe Managed Services, donde los clientes se beneficiarán de un equipo que tenga la experiencia y las habilidades de implementar y operar AEM en estos entornos de computación en la nube. Consulte nuestra documentación adicional sobre Adobe Managed Services.
Para obtener recomendaciones sobre cómo implementar AEM en Azure o AWS, fuera de Adobe Managed Services, le recomendamos encarecidamente que trabaje directamente con el proveedor de la nube o con uno de nuestros socios para admitir la implementación de AEM en el entorno de la 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 admitan para satisfacer sus requisitos específicos de rendimiento, carga, escalabilidad y seguridad.
Para obtener más información, consulte requisitos técnicos página.
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 e indexación de Oak.
Para la mayoría de las implementaciones, Adobe recomienda utilizar el índice de Lucene. Solo debe utilizar Solr para la escalabilidad en implementaciones especializadas y complejas.
Debe desarrollarse para AEM objetivo rendimiento y escalabilidad. A continuación se presentan varias prácticas recomendadas que puede seguir:
DO
NO
No utilice las API de JCR directamente, si puede
No cambie /libs, sino que utilice superposiciones
No utilice consultas siempre que sea posible
No utilice Sling Bindings para obtener servicios OSGi en el código Java, sino que utilice:
Para obtener más información sobre el desarrollo de AEM, lea Desarrollo: conceptos básicos. Para conocer las prácticas recomendadas adicionales, consulte Prácticas recomendadas de desarrollo.
Todas las pruebas de referencia mostradas en esta página se han realizado en una configuración de laboratorio.
Los escenarios de prueba detallados a continuación se utilizan para las secciones de referencia de los capítulos TarMK, MongoMk y TarMK frente a MongoMk. Para ver qué escenario se utilizó para una prueba de referencia en particular, lea el campo Escenario de la sección Especificaciones técnicas tabla.
Escenario de un solo producto
AEM Assets:
Escenario de mezcla de productos
AEM Sites + Recursos:
Caso de uso vertical
Medios:
Este capítulo ofrece 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 obtener más aclaraciones.
Adobe recomienda que TarMK sea la tecnología de persistencia predeterminada que utilizan los clientes en todos los casos de implementación, tanto para las instancias de AEM Author como para las de publicación.
Para obtener más información sobre TarMK, consulte Escenarios de implementación y Almacenamiento de Tar.
Las directrices de arquitectura mínimas que se presentan a continuación son para entornos de producción y sitios de alto tráfico. Estos son not el especificaciones mínimas necesario para ejecutar AEM.
Para establecer un buen rendimiento al utilizar TarMK, debe comenzar desde la siguiente arquitectura:
A continuación se ilustran las directrices de arquitectura para AEM sitios y AEM Assets.
La replicación sin binario debe girarse ON si se comparte el almacén de datos del archivo.
Directrices de arquitectura Tar para AEM Sites
Directrices de arquitectura Tar para AEM Assets
Para obtener 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 | 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 transitorio de Granite | Max Parallel |
Establezca el valor en la mitad del número de núcleos de CPU | |
Parámetros de JVM |
|
500000 100 000 250000 Verdadero |
Añada estos parámetros de JVM en el script de inicio de AEM para evitar que las consultas expansivas sobrecarguen los sistemas. |
Configuración del índice Lucene |
|
Habilitado Habilitado Habilitado |
Para obtener más información sobre los parámetros disponibles, consulte esta página. |
Almacén de datos = S3 Datastore |
|
1048576 (1MB) o menor 2-10 % del tamaño máximo de pila |
Consulte también Configuraciones del almacén de datos. |
Flujo de trabajo de recursos de actualización de 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 XMP reescritura al binario original y establece la última fecha de modificación en JCR. |
Los ensayos de referencia se realizaron con las siguientes especificaciones:
Nodo de autor | |
---|---|
Servidor | Hardware de metal desnudo (HP) |
Sistema operativo | RedHat Linux |
CPU / núcleos | CPU Intel® Xeon® 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 |
Situación | Un solo producto: Recursos / 30 subprocesos simultáneos |
Los números presentados a continuación se han normalizado a 1 como referencia y no son los números de rendimiento reales.
La razón principal para elegir el backend 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 utilizando 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 capacidad de CPU y memoria de un solo servidor, que admite todas las actividades de creación concurrentes, ya no es sostenible.
Para obtener más información sobre TarMK, consulte Escenarios de implementación y Almacenamiento de Mongo.
Para establecer un buen rendimiento al utilizar MongoMK, debe comenzar desde la siguiente arquitectura:
En entornos de producción, MongoDB siempre se utilizará como conjunto de réplicas con un primario y dos secundarios. Las lecturas y escrituras van a la primaria y las lecturas pueden ir a las secundarias. Si el almacenamiento no está disponible, una de las secundarias puede reemplazarse por un árbitro, pero los conjuntos de réplicas de MongoDB siempre deben estar compuestos por un número impar de instancias.
La replicación sin binario debe girarse ON si se comparte el almacén de datos del archivo.
Para obtener 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 (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 transitorio de Granite | Max Parallel |
Establezca el valor en la mitad del número de núcleos de CPU. | |
Parámetros de JVM |
|
500000 100 000 250000 Verdadero 60000 |
Añada estos parámetros de JVM en el script de inicio de AEM para evitar que las consultas expansivas sobrecarguen los sistemas. |
Configuración del índice Lucene |
|
Habilitado Habilitado Habilitado |
Para obtener más información sobre los parámetros disponibles, consulte esta página. |
Almacén de datos = S3 Datastore |
|
1048576 (1MB) o menor 2-10 % del tamaño máximo de pila |
Consulte también Configuraciones del almacén de datos. |
DocumentNodeStoreService |
|
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 se tarda en realizar la invalidación de caché. |
oak-observation |
|
min & max = 20 50000 |
Los ensayos de referencia se realizaron con 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® Xeon® E5-2407 @2,40GHz, 8 núcleos | CPU Intel® Xeon® E5-2407 @2,40GHz, 8 núcleos |
RAM | 32GB | 32GB |
Disco | Magnetic - >1k IOPS | Magnetic - >1k 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 |
Situación | Un solo producto: Recursos / 30 subprocesos simultáneos | Un solo producto: Recursos / 30 subprocesos simultáneos |
Los números presentados a continuación se han normalizado a 1 como referencia y no son los números de rendimiento reales.
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 casos de implementación, tanto para las instancias de AEM Author como para las de publicación.
La razón principal para elegir el backend 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 utilizando 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 solo servidor, que admite todas las actividades de creación concurrentes, ya no son sostenibles.
Para obtener más información sobre TarMK frente a MongoMK, consulte Implementaciones recomendadas.
Ventajas de TarMK
Criterios para elegir MongoMK
Los números presentados a continuación se han normalizado a 1 como referencia y no son números de rendimiento reales.
Nodo OAK de autor | 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 | Magnetic - >1k IOPS | Magnetic - >1k 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 | |
Situación |
|
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 autor | Nodo MongoMK de autor | 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: IOPS de 10.000 | SSD: IOPS de 10.000 | SSD: IOPS de 10.000 |
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 |
Situación |
|
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:
MongoMK con File Datastore es la arquitectura recomendada para la escalabilidad horizontal del nivel Autor:
Nodestore debe almacenarse en el disco local, no en un almacenamiento conectado a la red (NAS)
Al usar Amazon S3:
El índice personalizado debe crearse además del índice predeterminado en función de las búsquedas más comunes
La personalización de flujos de trabajo puede mejorar sustancialmente el rendimiento, por ejemplo, si elimina el paso de vídeo del flujo de trabajo "Actualizar recurso", si deshabilita los oyentes que no se utilizan, etc.
Para obtener más información, lea también la Implementaciones recomendadas página.