AEM Esta página proporciona directrices generales sobre cómo optimizar el rendimiento de la implementación de la implementación de la. AEM Si es nuevo en el sector de la, revise las siguientes páginas antes de empezar a leer las directrices de rendimiento:
AEM A continuación se ilustran las opciones de implementación disponibles para los usuarios (desplácese para ver todas las opciones):
AEM Producto |
Topología |
Sistema operativo |
Servidor de aplicaciones |
JRE |
Seguridad |
Microkernel |
Almacén de datos |
Indexación |
Servidor web |
Explorador |
Experience Cloud |
Sites |
Sin AH |
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 |
Autor-Descarga |
HP-UX |
Tomcat |
|
|
RDB/DB2 |
MongoDB |
|
|
Chrome |
Social |
Móvil |
Author-Cluster |
IBM® AIX® |
JBoss® |
|
|
RDB/MySQL |
RDBMS |
|
|
Safari |
Audiencia |
En varios sitios |
ASRP |
SUSE® |
|
|
|
RDB/SQLServer |
|
|
|
|
Assets |
Comercio |
MSRP |
SO APPLE |
|
|
|
|
|
|
|
|
Activación |
Dynamic Media |
JSRP |
|
|
|
|
|
|
|
|
|
Móvil |
Brand Portal |
J2E |
|
|
|
|
|
|
|
|
|
|
AoD |
|
|
|
|
|
|
|
|
|
|
|
LiveFyer |
|
|
|
|
|
|
|
|
|
|
|
Screens |
|
|
|
|
|
|
|
|
|
|
|
Doc Security |
|
|
|
|
|
|
|
|
|
|
|
Administración de procesos |
|
|
|
|
|
|
|
|
|
|
|
Aplicación de escritorio de |
|
|
|
|
|
|
|
|
|
|
|
Las directrices de rendimiento se aplican principalmente a AEM Sites.
Utilice las directrices de rendimiento en las siguientes situaciones:
AEM En este capítulo se ofrece una descripción general de la arquitectura de la y sus componentes más importantes. También proporciona directrices de desarrollo y describe los escenarios de prueba utilizados en las pruebas de referencia de TarMK y MongoMK.
AEM La plataforma de consta de los siguientes componentes:
AEM Para obtener más información sobre la plataforma de la, consulte AEM ¿Qué es la?.
AEM Existen tres componentes básicos importantes para una implementación de la. El 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 componente es el Dispatcher que es un módulo que administra el almacenamiento en caché y el filtrado de URL y que está instalado en el servidor web. AEM Para obtener más información sobre la arquitectura de la, consulte Escenarios de implementación habituales.
AEM Los Micro Kernels actúan como administradores de persistencia en la. AEM Existen tres tipos de Micro Kernels utilizados con el sistema: TarMK, MongoDB y Base de datos relacional (con soporte restringido). Elegir una que se ajuste a sus necesidades depende del propósito de su instancia y del tipo de implementación que esté considerando. Para obtener más información sobre Micro Kernels, consulte la Implementaciones recomendadas página.
AEM En, los datos binarios se pueden almacenar de forma independiente de los nodos de contenido. La ubicación donde se almacenan los datos binarios se denomina Almacén de datos, mientras que la ubicación de los nodos de contenido y las propiedades se denomina Almacenamiento de nodos.
Adobe recomienda que TarMK sea la tecnología de persistencia predeterminada que utilizan los clientes tanto para las instancias de autor de AEM como para las de publicación.
El micronúcleo de la base de datos relacional tiene compatibilidad restringida. Contacto Adobe del Servicio de atención al cliente antes de usar 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 muchos recursos multimedia, almacenarlos en el almacén de datos de Azure/S3 o de archivos 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 AEM recomienda elegir la opción de implementación de la aplicación en Azure o Amazon Web Service (AWS) mediante Adobe Managed Services. AEM Los clientes se benefician de un equipo con la experiencia y las habilidades necesarias para implementar y operar en estos entornos de computación en la nube (cloud computing) con el fin de obtener una mayor experiencia y capacidad de operación en estos entornos. Consulte Documentación adicional sobre Adobe Managed Services.
AEM Para obtener recomendaciones sobre cómo implementar en Azure o AWS, fuera de Adobe Managed Services, Adobe recomienda trabajar directamente con el proveedor de la nube. O bien, trabaje con uno de los socios de Adobe AEM que admita la implementación de las soluciones de en el entorno de nube que prefiera. 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 admiten para satisfacer los requisitos específicos de rendimiento, carga, escalabilidad y seguridad.
Consulte también la requisitos técnicos página.
AEM En esta sección se enumeran los proveedores de índices personalizados utilizados con las listas de proveedores de índices de. 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 Lucene. Utilice Solr únicamente para la escalabilidad en implementaciones especializadas y complejas.
AEM Desarrollar para el objetivo de la de rendimiento y escalabilidad. Las siguientes son prácticas recomendadas que puede seguir:
HACER
NO LO HAGAS
No utilice las API de JCR directamente, si es posible
No cambie /libs, sino que utilice superposiciones
No utilice consultas siempre que sea posible
No utilice enlaces de Sling para obtener servicios OSGi en código Java™, sino que utilice:
AEM Para obtener más información sobre el desarrollo de la, 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 un entorno 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 vs MongoMk. Para ver qué escenario se ha utilizado para una prueba de referencia determinada, lea el campo Escenario del Especificaciones técnicas tabla.
Escenario de un solo producto
AEM Assets:
Escenario de mezcla de productos
AEM Sites + Recursos:
Caso de uso vertical
Medios:
Read Article Page (27.4%), Read Page (10.9%), Create Session (2.6%), Activate Content Page (1.7%), Create Content Page (0.4%), Create Paragraph (4.3%), Edit Paragraph (0.9%), Image Component (0.9%), Browse Assets (20%), Read Asset Metadata (8.5%), Download Asset (4.2%), Search Asset (0.2%), Update Asset Metadata (2.4%), Upload Asset (1.2%), Browse Project (4.9%), Read Project (6.6%), Project Add Asset (1.2%), Project Add Site (1.2%), Create Project (0.1%), Author Search (0.4%)
Este capítulo proporciona directrices generales de rendimiento para TarMK que especifican los requisitos mínimos de arquitectura y la 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 autor de AEM 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 con alto tráfico. Estas directrices son no el especificaciones mínimas AEM para ejecutar la.
Para establecer un buen rendimiento al usar TarMK, debe comenzar desde la siguiente arquitectura:
AEM A continuación se ilustran las directrices de arquitectura para sitios de y AEM Assets.
La replicación sin binarios debe activarse ACTIVADO si se comparte el almacén de datos de archivos.
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, ver esta página.
Configuración | Parámetro | Valor | Descripción |
Colas de trabajos 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 |
AEM Para evitar que las consultas expansivas se sobrecarguen en los sistemas, añada estos parámetros JVM en el script de inicio de la. |
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 = Almacén de datos S3 |
|
1048576 (1 MB) o inferior 2-10% del tamaño máximo de la pila |
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 | XMP Este flujo de trabajo gestiona la reescritura de la al binario original y define la fecha de la última modificación en JCR. |
Los ensayos de referencia se realizaron con arreglo a las siguientes especificaciones:
Nodo de autor | |
---|---|
Servidor | Hardware de metal desnudo (HP) |
Sistema operativo | Red Hat® Linux® |
CPU/núcleos | CPU Intel® Xeon® E5-2407 @2,40 GHz, 8 núcleos |
RAM | 32 GB |
Disco | Magnético |
Java™ | Oracle JRE versión 8 |
Montón de JVM | 16 GB |
Producto | AEM 6.2 |
Nodestore | TarMK |
Almacén de datos | DS de archivo |
Escenario | Un solo producto: recursos / 30 hilos simultáneos |
Los números que se presentan a continuación se han normalizado a 1 como línea de base y no son los números de rendimiento real.
La razón principal para elegir el backend de persistencia MongoMK sobre TarMK es escalar las instancias horizontalmente. Esta capacidad significa tener dos o más instancias de autor activas siempre en ejecución y utilizar MongoDB como sistema de almacenamiento de persistencia. La necesidad de ejecutar más de una instancia de autor se debe generalmente al hecho de que la capacidad de CPU y memoria de un solo servidor, que admite todas las actividades de creación simultáneas, 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 utiliza como un conjunto de réplicas con un principal y dos secundarios. Las lecturas y 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.
La replicación sin binarios debe activarse ACTIVADO si se comparte el almacén de datos de archivos.
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, ver esta página.
Configuración | Parámetro | Valor (predeterminado) | Descripción |
Colas de trabajos 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 |
AEM Para evitar que las consultas expansivas se sobrecarguen en los sistemas, añada estos parámetros JVM en el script de inicio de la. |
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 = Almacén de datos S3 |
|
1048576 (1 MB) o inferior 2-10% del tamaño máximo de la 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,binary=0,-compact,-compress |
El tamaño predeterminado de la caché se establece en 256 MB. Afecta al tiempo que se tarda en realizar la invalidación de la caché. |
oak-observación |
|
mín. y máx. = 20 50000 |
Los ensayos de referencia se realizaron con arreglo a las siguientes especificaciones:
Nodo Autor | Nodo MongoDB | |
---|---|---|
Servidor | Hardware de metal desnudo (HP) | Hardware de metal desnudo (HP) |
Sistema operativo | Red Hat® Linux® | Red Hat® Linux® |
CPU/núcleos | CPU Intel® Xeon® E5-2407 @2,40 GHz, 8 núcleos | CPU Intel® Xeon® E5-2407 @2,40 GHz, 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 |
Montón de JVM | 16 GB | N/D |
Producto | AEM 6.2 | MongoDB 3.2 WiredTiger |
Nodestore | MongoMK | N/D |
Almacén de datos | DS de archivo | N/D |
Escenario | Un solo producto: recursos / 30 hilos simultáneos | Un solo producto: recursos / 30 hilos simultáneos |
Los números que se presentan a continuación se han normalizado a 1 como línea de base y no son los números de rendimiento real.
La regla básica a tener 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 autor de AEM como para las de publicación.
La razón principal para elegir el backend de persistencia MongoMK sobre TarMK es escalar las instancias horizontalmente. Esta funcionalidad significa tener dos o más instancias de autor activas siempre en ejecución y utilizar MongoDB como sistema de almacenamiento de persistencia. La necesidad de ejecutar más de una instancia de autor suele deberse al hecho de que la capacidad de CPU y memoria de un solo servidor, que admite todas las actividades de creación simultáneas, ya no es sostenible.
Para obtener más información sobre TarMK frente a MongoMK, consulte Implementaciones recomendadas.
Ventajas de TarMK
Criterios para elegir MongoMK
Los números que se presentan a continuación se han normalizado a 1 como línea de base y no son números de rendimiento real.
Nodo OAK de autor | Nodo MongoDB | ||
Servidor | Hardware de metal desnudo (HP) | Hardware de metal desnudo (HP) | |
Sistema operativo | Red Hat® Linux® | Red Hat® Linux® | |
CPU/núcleos | CPU Intel(R) Xeon(R) E5-2407 @2,40 GHz, 8 núcleos | CPU Intel(R) Xeon(R) E5-2407 @2,40 GHz, 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 | |
Montón de JVM16 GB | 16 GB | N/D | |
Producto | AEM 6.2 | MongoDB 3.2 WiredTiger | |
Nodestore | TarMK o MongoMK | N/D | |
Almacén de datos | DS de archivo | N/D | |
Escenario |
|
AEM Para habilitar el mismo número de Autores con MongoDB que con un sistema TarMK, necesita un clúster con dos nodos de. Un clúster MongoDB de cuatro nodos puede administrar 1,8 veces el número de autores que una instancia de TarMK. Un clúster de MongoDB de ocho nodos puede administrar 2,3 veces el número de autores que una instancia de TarMK.
Nodo TarMK de autor | Nodo MongoMK de autor | Nodo MongoDB | |
Servidor | AWS c3.8xlarge | AWS c3.8xlarge | AWS c3.8xlarge |
Sistema operativo | Red Hat® Linux® | Red Hat® Linux® | Red Hat® 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 |
Montón de JVM16 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 | DS de archivo | DS de archivo |
N/D |
Escenario |
|
Las directrices presentadas en esta página se pueden resumir de la siguiente manera:
TarMK con almacén de datos de archivos - La arquitectura recomendada para la mayoría de los clientes:
MongoMK con almacén de datos de archivos - La arquitectura recomendada para la escalabilidad horizontal del nivel de Author:
Nodestore - Almacenado en el disco local, no en un almacenamiento conectado a la red (NAS)
Al utilizar Amazon S3:
Se debe crear un índice personalizado además del índice predeterminado - Según las búsquedas más comunes
La personalización del flujo de trabajo puede mejorar sustancialmente el rendimiento - Elimine el paso de vídeo en el flujo de trabajo "Actualizar recurso", desactivando los oyentes que no se utilizan, etc.
Para obtener más información, lea la Implementaciones recomendadas página.