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 páginas siguientes antes de que inicio de leer las directrices de rendimiento:
A continuación se muestran las opciones de implementación disponibles para AEM (desplácese hasta la vista de 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 es de alta disponibilidad |
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 |
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 AEM Sites.
Debe utilizar las directrices de rendimiento en las siguientes situaciones:
Este capítulo ofrece una visió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 AEM consta de los siguientes componentes:
Para obtener más información sobre la plataforma AEM, consulte Qué es AEM.
Hay tres elementos básicos importantes para una implementación AEM. La 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 él. El tercer bloque de creación es el Dispatcher, que es un módulo que gestiona el almacenamiento en caché y el filtrado de direcciones URL y que se instala en el servidor web. Para obtener información adicional sobre la arquitectura de AEM, consulte Escenarios de implementación típicos.
Los micro kernels actúan como administradores de persistencia en AEM. Existen tres tipos de micronúcleos utilizados 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.
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 Adobe Customer Care antes de utilizar este tipo de micronúcleo.
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 los almacenes de datos y nodos.
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 de su elección. 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 requisitos técnicos.
En esta sección se enumeran los proveedores de índices personalizados que se utilizan con AEM. Para obtener más información sobre la indexación, consulte Consultas de roble e indización.
Para la mayoría de las implementaciones, Adobe recomienda el uso del índice de Lucene. Debe utilizar Solr únicamente para la escalabilidad en implementaciones especializadas y complejas.
Debe desarrollarse para AEM objetivo de performance 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 usar consultas siempre que sea posible
No utilice Sling Bindings para obtener los servicios OSGi en el código Java, sino más bien utilice:
Para obtener más información sobre el desarrollo de AEM, lea Desarrollar: conceptos básicos. Para obtener más información sobre las mejores prácticas, consulte Optimizaciones para el desarrollo.
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 en particular, lea el campo Escenario de la tabla Especificaciones técnicas.
Escenario de un solo producto
AEM Assets:
Escenario de mezcla de productos
AEM Sites + Assets:
Caso de uso vertical
Medios:
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 carro.
Las directrices de arquitectura mínimas que se presentan a continuación son para entornos de producción y sitios de alto tráfico. Son no las especificaciones mínimas necesarias para ejecutar AEM.
Para lograr un buen rendimiento al utilizar TarMK, debe realizar el inicio desde la siguiente arquitectura:
A continuación se ilustran las directrices de arquitectura para AEM sitios y AEM Assets.
Si se comparte el almacén de datos del archivo, la replicación sin binario debe activarse en.
Directrices de arquitectura de etiquetas para AEM Sites
Directrices de arquitectura de etiquetas para AEM Assets
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 |
|
500000 100 000 250000 Verdadero |
Añada estos parámetros JVM en la secuencia de comandos de inicio de AEM para evitar que consultas expansivas sobrecarguen los sistemas. |
Configuración del índice Lucene |
|
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 |
|
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 XMP escritura en el binario original y establece la fecha de la última modificación en JCR. |
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® Xeon® E5-2407 @2,40GHz, 8 núcleos |
RAM | 32 GB |
Disco | Magnético |
Java | Oracle JRE versión 8 |
JVM Heap | 16 GB |
Producto | AEM 6.2 |
Nodestore | TarMK |
Almacén de datos | Archivo DS |
Escenario | Producto único: Recursos / 30 subprocesos simultáneos |
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.
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 de mongo.
Para lograr un buen rendimiento al utilizar MongoMK, debe realizar el inicio de 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 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 binario debe activarse en.
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 |
|
500000 100 000 250000 Verdadero 60000 |
Añada estos parámetros JVM en la secuencia de comandos de inicio de AEM para evitar que consultas expansivas sobrecarguen los sistemas. |
Configuración del índice Lucene |
|
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 |
|
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 |
|
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 |
|
min & max = 20 50000 |
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® Xeon® E5-2407 @2,40GHz, 8 núcleos | CPU Intel® Xeon® E5-2407 @2,40GHz, 8 núcleos |
RAM | 32 GB | 32 GB |
Disco | Magnético: >1.000 IOPS | Magnético: >1.000 IOPS |
Java | Oracle JRE versión 8 | N/D |
JVM Heap | 16 GB | 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 |
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.
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 vs MongoMK, consulte Implementaciones recomendadas.
Beneficios de TarMK
Criterios para elegir 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.
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 | 32 GB | 32 GB | |
Disco | Magnético: >1.000 IOPS | Magnético: >1.000 IOPS | |
Java | Oracle JRE versión 8 | N/D | |
JVM Heap16 GB | 16 GB | 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 |
|
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 | 60 GB | 60 GB | 60 GB |
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 | 30 GB | 30 GB | 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 |
|
Las directrices presentadas en esta página se pueden resumir de la siguiente manera:
TarMK con File Datastorees la arquitectura recomendada para la mayoría de los clientes:
MongoMK con File Datastorees la arquitectura recomendada para la escalabilidad horizontal del nivel Autor:
No debe almacenarse en el disco local, no en un almacenamiento conectado a la red (NAS)
Al utilizar Amazon S3:
El índice personalizado debe crearse además del índice predeterminado basado en las búsquedas más comunes
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, lea también la página Implementaciones recomendadas.