Directrices de rendimiento performance-guidelines
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):
Cuándo utilizar las directrices de rendimiento when-to-use-the-performance-guidelines
Debe utilizar las directrices de rendimiento en las situaciones siguientes:
- Implementación por primera vez: Al planificar la implementación de AEM Sites o Assets 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 en ejecución. Por ejemplo, actualizar 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.
- Adición de más autores: Cuando la topología TarMK recomendada no cumple los requisitos de rendimiento y el 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 cumpla con sus requisitos, es importante comprender las diferencias de rendimiento en comparación con otras opciones del almacén de datos. Ejemplo: usar el almacén de datos de Amazon S3 o Microsoft Azure en lugar de un almacén de datos de archivos.
Introducción introduction
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 the-aem-platform
La plataforma AEM consta de los siguientes componentes:
Para obtener más información sobre la plataforma AEM, consulte ¿Qué es AEM.
La arquitectura AEM the-aem-architecture
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.
Micro kernels micro-kernels
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.
Nodestore nodestore
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.
Almacén de datos 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 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.
Búsqueda search-features
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.
Directrices de desarrollo development-guidelines
Debe desarrollarse para AEM objetivo 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 API de AEM existentes (por ejemplo: Sling) y herramientas (por ejemplo: Replicación)
- Desarrollo en el contexto del contenido real
- Desarrollo para una capacidad de caché óptima
- Minimizar el número de guardos (por ejemplo: mediante flujos de trabajo transitorios)
- Asegúrese de que todos los puntos finales HTTP sean 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 utilice consultas siempre que sea posible
-
No utilice Sling Bindings para obtener servicios OSGi en el código Java, sino que utilice:
- @Reference en un componente DS
- @Inject in a Sling Model
- 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, lea Desarrollo: conceptos básicos. Para conocer las prácticas recomendadas adicionales, consulte Prácticas recomendadas de desarrollo.
Escenarios de referencia benchmark-scenarios
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:
- Interacciones del usuario: Examinar recursos / Buscar recursos / Descargar recurso / Leer metadatos de recursos / Actualizar metadatos de recursos / Cargar recursos / Ejecutar flujo de trabajo de recursos de carga
- Modo de ejecución: usuarios simultáneos, interacción única por usuario
Escenario de mezcla de productos
AEM Sites + Recursos:
- Interacciones de usuario del sitio: Leer página de artículo / Leer página / Crear párrafo / Editar párrafo / Crear página de contenido / Activar página de contenido / Buscar autor
- Interacciones de usuario de recursos: Examinar recursos / Buscar recursos / Descargar recurso / Leer metadatos de recursos / Actualizar metadatos de recursos / Cargar recursos / Ejecutar flujo de trabajo de recursos de carga
- Modo de ejecución: usuarios simultáneos, interacciones mixtas por usuario
Caso de uso vertical
Medios:
- Lea 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%), Examinar recursos (20%), Leer metadatos de recursos (8,5%), Descargar recurso (4,2%), Recurso de búsqueda (0,2%), Actualizar metadatos de recursos (2,4%), Cargar recursos (1,2%), Examinar proyectos (4,9%), Leer proyectos (6,6%), Agregar recursos de proyectos (1,2%), Agregar sitios de proyectos (1,2%), Crear proyectos (0,1%), Buscar autores (0,4%)
- Modo de ejecución: usuarios simultáneos, interacciones mixtas por usuario
TarMK tarmk
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.
Directrices de arquitectura mínima de TarMK tarmk-minimum-architecture-guidelines
Para establecer un buen rendimiento al utilizar TarMK, debe comenzar desde la siguiente arquitectura:
- Una instancia de autor
- Dos instancias de publicación
- Dos distribuidores
A continuación se ilustran las directrices de arquitectura para AEM sitios y AEM Assets.
Directrices de arquitectura Tar para AEM Sites
Directrices de arquitectura Tar para AEM Assets
Directrices de configuración de TarMK tarmk-settings-guideline
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.
Referencia de rendimiento de TarMK tarmk-performance-benchmark
Especificaciones técnicas technical-specifications
Los ensayos de referencia se realizaron con las siguientes especificaciones:
Resultados del marcador de rendimiento performance-bechmark-results
MongoMK mongomk
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.
Directrices de arquitectura mínima de MongoMK mongomk-minimum-architecture-guidelines
Para establecer un buen rendimiento al utilizar MongoMK, debe comenzar desde la siguiente arquitectura:
- Tres instancias de autor
- Dos instancias de publicación
- Tres instancias de MongoDB
- Dos distribuidores
Directrices de configuración de MongoMK mongomk-settings-guidelines
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.
Referencia de rendimiento de MongoMK mongomk-performance-benchmark
Especificaciones técnicas technical-specifications-1
Los ensayos de referencia se realizaron con las siguientes especificaciones:
Resultados de los indicadores de rendimiento performance-benchmark-results
TarMK frente a MongoMK 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 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.
Directrices TarMK frente a MongoMk tarmk-vs-mongomk-guidelines
Ventajas de TarMK
- Compilado con fines específicos para aplicaciones de administración de contenido
- Los archivos son siempre coherentes y se puede realizar una copia de seguridad con cualquier herramienta de copia de seguridad basada en archivos
- Proporciona un mecanismo de conmutación por error (consulte Espera en frío para obtener más detalles
- Proporciona un almacenamiento de datos confiable y de alto performance con una sobrecarga operacional mínima
- 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 ingesta de recursos por día: en cientos de miles o más
- Volumen de 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 frente a MongoMK tarmk-vs-mongomk-benchmarks
Especificaciones técnicas del escenario 1 scenario-technical-specifications
Resultados de la referencia de rendimiento del escenario 1 scenario-performance-benchmark-results
Especificaciones técnicas del escenario 2 scenario-technical-specifications-1
Resultados de la referencia de rendimiento del escenario 2 scenario-performance-benchmark-results-1
Directrices de escalabilidad de la arquitectura para AEM Sites y recursos architecture-scalability-guidelines-for-aem-sites-and-assets
Resumen de las directrices de rendimiento summary-of-performance-guidelines
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 instancias de Dispatcher
- Replicación sin binarios activada si el almacén de datos del archivo es compartido
-
MongoMK con File Datastore es la arquitectura recomendada para la escalabilidad horizontal del nivel Autor:
- Topología mínima: tres instancias de autor, tres instancias de MongoDB, dos instancias de publicación, dos instancias de Dispatcher
- Replicación sin binarios activada si el almacén de datos del archivo es compartido
-
Nodestore debe almacenarse en el disco local, no en un almacenamiento conectado a la red (NAS)
-
Al usar Amazon S3:
- El almacén de datos de Amazon S3 se comparte entre el nivel Author y Publish
- La replicación sin binario debe estar activada
- La colección de residuos del almacén de datos requiere una primera ejecución en todos los nodos Autor y Publicación y una segunda ejecución en Autor
-
El índice personalizado debe crearse además del índice predeterminado en función de las búsquedas más comunes
- Los índices Lucene deben usarse para los índices personalizados
-
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.