Directrices de rendimiento performance-guidelines
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):
Cuándo utilizar las directrices de rendimiento when-to-use-the-performance-guidelines
Utilice las directrices de rendimiento en las siguientes situaciones:
- Primera implementación: Cuando se planifica implementar AEM Sites o Assets por primera vez, es importante comprender las opciones disponibles. Especialmente al configurar el Micro Kernel, 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 a almacén de datos de archivo.
- 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. AEM AEM Por ejemplo, si actualiza de la versión 6.1 a la versión 6.2, o de la versión 6.0 CRX2 a la versión 6.2 de OAK, la actualización se realizará de la versión 6.1 a la versión 6.2.
- El tiempo de respuesta es lento: Cuando la arquitectura de Nodestore seleccionada 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 archivo 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 nodo Autor ha alcanzado la capacidad máxima disponible, comprenda las diferencias de rendimiento. Compare MongoMK con tres o más nodos de Author. Por ejemplo, implementar MongoMK en lugar de TarMK.
- Añadir más contenido: cuando la arquitectura de almacén de datos recomendada no cumple con sus requisitos, es importante comprender las diferencias de rendimiento en comparación con otras opciones de 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 archivo.
Introducción introduction
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 the-aem-platform
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 La arquitectura de la the-aem-architecture
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.
Micro Kernels micro-kernels
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.
Nodestore nodestore
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.
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 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.
Búsqueda search-features
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.
Directrices de desarrollo development-guidelines
AEM Desarrollar para el objetivo de la de rendimiento y escalabilidad. Las siguientes son prácticas recomendadas que puede seguir:
HACER
- Aplicar la separación de presentación, lógica y contenido
- AEM Utilice las API existentes de la (por ejemplo, Sling) y las herramientas (por ejemplo, Replication)
- Desarrollar en el contexto de contenido real
- Desarrollar para lograr una caché óptima
- Minimizar el número de guardados (por ejemplo, mediante flujos de trabajo transitorios)
- Asegúrese de que todos los puntos finales HTTP sean RESTful
- Restringir el ámbito de la observación JCR
- Tenga en cuenta el subproceso asincrónico
NO LO HAGAS
-
No utilice directamente las API de JCR, 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:
- @Reference en un componente DS
- @Inject en un modelo Sling
- sling.getService() en una clase de uso de Sightly
- sling.getService() en un JSP
- un ServiceTracker
- acceso directo al registro de servicios OSGi
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.
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 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:
- Interacciones del usuario: Examinar recursos/Buscar recursos/Descargar recurso/Leer metadatos del recurso/Actualizar metadatos del recurso/Cargar recurso/Ejecutar flujo de trabajo de cargar recurso
- Modo de ejecución: usuarios simultáneos, una sola interacción por usuario
Escenario de mezcla de productos
AEM Sites + Recursos:
- Interacciones de usuario de Sites: 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/Búsqueda de autor
- Interacciones de usuario de Assets: Examinar recursos/buscar recursos/descargar recursos/leer metadatos de recursos/actualizar metadatos de recursos/cargar recursos/ejecutar flujo de trabajo de cargar recursos
- Modo de ejecución: usuarios simultáneos, interacciones mixtas por usuario
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%)- Modo de ejecución: usuarios simultáneos, interacciones mixtas por usuario
TarMK tarmk
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 AEM recomienda que TarMK sea la tecnología de persistencia predeterminada utilizada por los clientes en todos los escenarios de implementación, tanto para las instancias de autor de la 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 usar TarMK, debe comenzar desde la siguiente arquitectura:
- Una instancia de autor
- Dos instancias de publicación
- Dos Dispatcher
AEM A continuación se ilustran las directrices de arquitectura para sitios de 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, ver esta página.
Referencia de rendimiento de TarMK tarmk-performance-benchmark
Especificaciones técnicas technical-specifications
Los ensayos de referencia se realizaron con arreglo a las siguientes especificaciones:
Resultados de referencia de rendimiento performance-benchmark-results
MongoMK mongomk
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.
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 Dispatcher
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, ver esta página.
Análisis de rendimiento de MongoMK mongomk-performance-benchmark
Especificaciones técnicas technical-specifications-1
Los ensayos de referencia se realizaron con arreglo a las siguientes especificaciones:
Resultados de referencia de rendimiento performance-benchmark-results-1
TarMK vs MongoMK tarmk-vs-mongomk
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 AEM recomienda que TarMK sea la tecnología de persistencia predeterminada utilizada por los clientes en todos los escenarios de implementación, tanto para las instancias de autor de la 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.
Directrices TarMK vs MongoMk tarmk-vs-mongomk-guidelines
Ventajas de TarMK
- Creado específicamente para aplicaciones de gestión de contenido
- Los archivos siempre son coherentes y se pueden realizar copias de seguridad utilizando 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 información
- Proporciona un alto rendimiento y un almacenamiento de datos fiable con una sobrecarga operativa mínima
- Menor coste total de propiedad (TCO)
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 ediciones de página al día: en cientos de miles o más
- Volumen de búsquedas por día: en decenas de miles o más
Puntos de referencia de TarMK vs MongoMK tarmk-vs-mongomk-benchmarks
Especificaciones técnicas del escenario 1 scenario-technical-specifications
Resultados de referencia de rendimiento del escenario 1 scenario-performance-benchmark-results
Especificaciones técnicas del escenario 2 scenario-technical-specifications-1
Resultados de referencia de rendimiento del escenario 2 scenario-performance-benchmark-results-1
Directrices de escalabilidad de arquitectura para AEM Sites y Assets 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 almacén de datos de archivos - 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 se comparte el almacén de datos de archivos
-
MongoMK con almacén de datos de archivos - La arquitectura recomendada para la escalabilidad horizontal del nivel de Author:
- 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 se comparte el almacén de datos de archivos
-
Nodestore - Almacenado en el disco local, no en un almacenamiento conectado a la red (NAS)
-
Al utilizar Amazon S3:
- El almacén de datos de Amazon S3 se comparte entre los niveles Author y Publish
- La replicación sin binarios debe estar activada
- La recolección de elementos no utilizados del almacén de datos requiere una primera ejecución en todos los nodos de autor y publicación y, a continuación, una segunda ejecución en autor
-
Se debe crear un índice personalizado además del índice predeterminado - Según las búsquedas más comunes
- Los índices de Lucene deben utilizarse para los índices personalizados
-
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.