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):

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
Público destinatario
Recursos
Publish-HA
Solaris™
WebLogic
IBM®
SAML
MongoDB
Archivo
Lucene
IIS
IE
Análisis
Comunidades
Author-CS
Red Hat®
WebSphere®
HP
Oauth
RDB/Oracle
S3/Azure
Solr
iPlanet
FireFox
Campaign
Formularios
Autor-Descarga
HP-UX
Tomcat
RDB/DB2
MongoDB
Chrome
Social
Mobile
Author-Cluster
IBM® AIX®
JBoss®
RDB/MySQL
RDBMS
Safari
Audiencia
En varios sitios
ASRP
SUSE®
RDB/SQLServer
Recursos
Comercio
MSRP
SO APPLE
Activación
Dynamic Media
JSRP
Mobile
Brand Portal
J2E
AoD
LiveFyer
Screens
Doc Security
Administración de procesos
aplicación de escritorio
NOTE
Las directrices de rendimiento se aplican principalmente a AEM Sites.

Cuándo utilizar las directrices de rendimiento when-to-use-the-performance-guidelines

Utilice las directrices de rendimiento en las siguientes situaciones:

  • Implementación por primera vez: Cuando planee implementar AEM Sites o Assets por primera vez, es importante entender 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 de CRX2 a la versión 6.2 de OAK, o bien de la versión 6.0 de la versión 6.2.
  • El tiempo de respuesta es lento: Cuando la arquitectura de Nodestore seleccionada no cumple con sus requisitos, es importante entender 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.
  • Agregar 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.
  • Agregar más contenido: Cuando la arquitectura de almacén de datos recomendada no cumple con sus requisitos, es importante entender las diferencias de rendimiento en comparación con otras opciones del 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:

chlimage_1

AEM AEM Para obtener más información acerca de la plataforma de la, vea Qué es la.

AEM La arquitectura de la the-aem-architecture

AEM Existen tres componentes básicos importantes para una implementación de la. 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 Publish Instance desde donde los usuarios finales acceden a él. El tercer bloque de creación es 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 información adicional acerca de la arquitectura de la, vea Escenarios de implementación típicos.

chlimage_1-1

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 información adicional sobre Micro Kernels, consulte la página Implementaciones recomendadas.

chlimage_1-2

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 Almacén de nodos.

NOTE
Adobe AEM recomienda que TarMK sea la tecnología de persistencia predeterminada utilizada por los clientes tanto para las instancias de autor como para las de Publish de la aplicación de la aplicación de la aplicación de la.
CAUTION
El micronúcleo de la base de datos relacional tiene compatibilidad restringida. Póngase en contacto con el Servicio de atención al cliente de Adobe antes de usar este tipo de microkernel.

chlimage_1-3

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 del nodo y los almacenes de datos.

NOTE
Adobe AEM recomienda elegir la opción de implementación de la aplicación en Azure o en 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. Ver documentación adicional sobre el 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 página requisitos técnicos.

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 acerca de la indexación, consulte Consultas e indexación de Oak.

NOTE
Para la mayoría de las implementaciones, Adobe recomienda utilizar el índice Lucene. Utilice Solr únicamente para la escalabilidad en implementaciones especializadas y complejas.

chlimage_1-4

Directrices de desarrollo development-guidelines

AEM Desarrollar para obtener un objetivo de 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 SE

  • 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 acerca de cómo desarrollar en el desarrollo, lea Desarrollo - Conceptos básicos. Para ver prácticas recomendadas adicionales, consulte Prácticas recomendadas de desarrollo.

Escenarios de referencia benchmark-scenarios

NOTE
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 utilizó para una prueba de referencia determinada, lea el campo Escenario de la tabla Especificaciones técnicas.

Escenario de un solo producto

AEM Assets:

  • Interacciones del usuario: Examinar Assets/Buscar Assets/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 + Assets:

  • 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 del usuario de Assets: Examinar Assets/Buscar Assets/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, interacciones mixtas por usuario

Escenario de 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 Publish.

Para obtener más información sobre TarMK, consulte Escenarios de implementación y Almacenamiento Tar.

Directrices de arquitectura mínima de TarMK tarmk-minimum-architecture-guidelines

NOTE
Las directrices de arquitectura mínimas que se presentan a continuación son para entornos de producción y sitios con alto tráfico. AEM Estas directrices son no las especificaciones mínimas para ejecutar el programa de trabajo de la aplicación de la manera de ejecutar el programa de trabajo.

Para establecer un buen rendimiento al usar TarMK, debe comenzar desde la siguiente arquitectura:

  • Una instancia de autor
  • Dos instancias de Publish
  • Dos Dispatcher

AEM A continuación se ilustran las directrices de arquitectura para sitios de y AEM Assets.

NOTE
La replicación sin binarios debe activarse ON si se comparte el almacén de datos de archivos.

Directrices de arquitectura Tar para AEM Sites

chlimage_1-5

Directrices de arquitectura Tar para AEM Assets

chlimage_1-6

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 Optimización del rendimiento.

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

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

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

CopyOnRead

CopyOnWrite

Prefetch Index Files

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

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) o inferior

2-10% del tamaño máximo de la pila

Consulte también Configuraciones de almacén de datos.
Flujo de trabajo de recursos de actualización DAM
Transient Workflow
activado
Este flujo de trabajo administra la actualización de recursos.
Reescritura de metadatos DAM
Transient Workflow
activado
XMP Este flujo de trabajo gestiona la reescritura de la al binario original y define la fecha de la última modificación en JCR.

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:

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: Assets / 30 hilos simultáneos

Resultados de referencia de rendimiento performance-benchmark-results

NOTE
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.

chlimage_1-7 chlimage_1-8

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 Publish
  • Tres instancias de MongoDB
  • Dos Dispatcher
NOTE
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.
NOTE
La replicación sin binarios debe activarse ON si se comparte el almacén de datos de archivos.

chlimage_1-9

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 Optimización del rendimiento.

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

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

Doak.mongo.maxQueryTimeMS

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

CopyOnRead

CopyOnWrite

Prefetch Index Files

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

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) o inferior

2-10% del tamaño máximo de la pila

Consulte también Configuraciones de almacén de datos.
DocumentNodeStoreService

cache

nodeCachePercentage

childrenCachePercentage

diffCachePercentage

docChildrenCachePercentage

prevDocCachePercentage

persistentCache

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

thread pool

length

mín. y máx. = 20

50000

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:

Nodo 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® 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: Assets / 30 hilos simultáneos
Un solo producto: Assets / 30 hilos simultáneos

Resultados de referencia de rendimiento performance-benchmark-results-1

NOTE
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.

chlimage_1-10 chlimage_1-11

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 Publish.

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 y 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 Suspensión 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

NOTE
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.

Especificaciones técnicas del escenario 1 scenario-technical-specifications

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
Un solo producto: Assets / 30 hilos simultáneos por ejecución

Resultados de referencia de rendimiento del escenario 1 scenario-performance-benchmark-results

chlimage_1-12

Especificaciones técnicas del escenario 2 scenario-technical-specifications-1

NOTE
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
Caso de uso vertical: Media / 2000 subprocesos simultáneos

Resultados de referencia de rendimiento del escenario 2 scenario-performance-benchmark-results-1

chlimage_1-13

Directrices de escalabilidad de arquitectura para AEM Sites y Assets architecture-scalability-guidelines-for-aem-sites-and-assets

chlimage_1-14

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 Publish, 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 Publish, 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 usar Amazon S3:

    • El almacén de datos de Amazon S3 se comparte entre el nivel de Author y Publish
    • La replicación sin binarios debe estar activada
    • La recopilación de elementos no utilizados del almacén de datos requiere una primera ejecución en todos los nodos de autor y Publish, y luego una segunda ejecución en Autor
  • Se debe crear un índice personalizado además del índice predeterminado, basado en 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 considerablemente el rendimiento: elimine el paso de vídeo del flujo de trabajo "Actualizar recurso", deshabilite los agentes de escucha que no se usen, etc.

Para obtener más información, lea también la página Implementaciones recomendadas.

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2