Pautas para configurar el tamaño del hardware

Estas directrices de tamaño ofrecen una aproximación de los recursos de hardware necesarios para implementar un proyecto AEM. Las estimaciones de tamaño dependen de la arquitectura del proyecto, la complejidad de la solución, el tráfico esperado y los requisitos del proyecto. Esta guía le ayuda a determinar las necesidades de hardware para una solución específica, o a encontrar una estimación superior e inferior de los requisitos de hardware.

Los factores básicos a tener en cuenta son (en este orden):

• Velocidad de red

  • Latencia de red
  • Ancho de banda disponible

• Velocidad de cómputo

  • Eficiencia de almacenamiento en caché
  • Tráfico esperado
  • Complejidad de las plantillas, aplicaciones y componentes
  • Autores simultáneos
  • Complejidad de la operación de creación (edición simple de contenido, implementación de MSM, etc.)

• Rendimiento de E/S

  • Rendimiento y eficiencia del almacenamiento de archivos o bases de datos

• Disco duro

  • al menos dos o tres veces más grande que el tamaño del repositorio

• Memoria

  • Tamaño del sitio web (número de objetos de contenido, páginas y usuarios)
  • Número de usuarios/sesiones que están activas al mismo tiempo

Arquitectura

Una configuración de AEM típica consta de un autor y un entorno de publicación. Estos entornos tienen diferentes requisitos con respecto al tamaño de hardware subyacente y la configuración del sistema. Las consideraciones detalladas para ambos entornos se describen en la sección entorno de creación y entorno de publicación secciones.

En una configuración de proyecto típica, tiene varios entornos en los que realizar la etapa de proyecto:

• Entorno de desarrollo
  Para desarrollar nuevas funciones o realizar cambios significativos. Una práctica recomendada es trabajar con un entorno de desarrollo por desarrollador (normalmente instalaciones locales en sus sistemas personales).

• Entorno de prueba de creación
  Para verificar los cambios. El número de entornos de prueba puede variar en función de los requisitos del proyecto (por ejemplo, por separado para el control de calidad, las pruebas de integración o las pruebas de aceptación del usuario).

• Publicar entorno de prueba
  Principalmente para probar casos de uso de colaboración social o la interacción entre el autor y varias instancias de publicación.

• Entorno de producción de creación
  Para que los autores editen el contenido.

• Publicar entorno de producción
  Para mostrar contenido publicado.

Además, los entornos pueden variar, desde un sistema de un solo servidor que ejecute AEM y un servidor de aplicaciones, hasta un conjunto de instancias agrupadas de múltiples servidores y varias CPU a gran escala. Le recomendamos que utilice un equipo independiente para cada sistema de producción y que no ejecute otras aplicaciones en estos equipos.

Consideraciones genéricas sobre el tamaño del hardware

Las secciones siguientes proporcionan instrucciones sobre cómo calcular los requisitos de hardware, teniendo en cuenta diversas consideraciones. Para los sistemas grandes, le sugerimos que realice un sencillo conjunto de pruebas de referencia internas en una configuración de referencia.

La optimización del rendimiento es una tarea fundamental que debe realizarse antes de poder realizar cualquier prueba comparativa para un proyecto específico. Asegúrese de aplicar los consejos proporcionados en la Documentación sobre la optimización del rendimiento antes de realizar pruebas de referencia y utilizar sus resultados para cualquier cálculo de tamaño de hardware.

Los requisitos de tamaño de hardware para casos de uso avanzados deben basarse en una evaluación detallada del rendimiento del proyecto. Las características de los casos de uso avanzado que requieren recursos de hardware excepcionales incluyen combinaciones de:

• carga útil/rendimiento de alto contenido
• uso extensivo de código personalizado, flujos de trabajo personalizados o bibliotecas de software de terceros
• integración con sistemas externos no compatibles

Espacio en disco/Disco duro

El espacio en disco necesario depende en gran medida del volumen y el tipo de la aplicación web. Los cálculos deben tener en cuenta:

• la cantidad y el tamaño de las páginas, los recursos y otras entidades almacenadas en el repositorio, como flujos de trabajo, perfiles, etc.
• la frecuencia estimada de cambios de contenido y, por lo tanto, la creación de versiones de contenido
• el volumen de las representaciones de recursos DAM que se generarán
• el crecimiento general del contenido a lo largo del tiempo

El espacio en disco se monitorea continuamente durante la limpieza de revisión en línea y sin conexión. Si el espacio en disco disponible cae por debajo de un valor crítico, el proceso se cancelará. El valor crítico es el 25% de la huella de disco actual del repositorio y no es configurable. Se recomienda dimensionar el disco al menos dos o tres veces más grande que el tamaño del repositorio, incluido el crecimiento estimado.

Considere una configuración de matrices redundantes de discos independientes (RAID, por ejemplo, RAID10) para la redundancia de datos.

Virtualización

AEM funciona bien en entornos virtualizados, pero puede haber factores como CPU o E/S que no se pueden equiparar directamente al hardware físico. Una recomendación es elegir una velocidad de E/S más alta (en general) ya que esto es un factor crítico en la mayoría de los casos. La evaluación comparativa del entorno es necesaria para comprender con precisión qué recursos se necesitarán.

Paralelización de instancias de AEM

Fallo de seguridad

Se implementa un sitio web seguro contra fallos en al menos dos sistemas separados. Si un sistema se rompe, otro puede tomar el control y compensar así el fallo del sistema.

Escalabilidad de los recursos del sistema

Mientras todos los sistemas están en ejecución, hay disponible un mayor rendimiento informático. Que el rendimiento adicional no es necesariamente lineal con el número de nodos del clúster, ya que la relación depende en gran medida del entorno técnico; consulte la Documentación del clúster para obtener más información.

La estimación de cuántos nodos de clúster son necesarios se basa en los requisitos básicos y en casos de uso específicos del proyecto web en particular:

• Desde la perspectiva de la seguridad ante fallos, es necesario determinar, para todos los entornos, la importancia de la falla y el tiempo de compensación de la falla en función del tiempo que tarda un nodo de cluster en recuperarse.
• Para el aspecto de la escalabilidad, el número de operaciones de escritura es básicamente el factor más importante; see Autores que trabajan en paralelo para el entorno de creación y Social Collaboration para el entorno de publicación. Se puede establecer el equilibrio de carga para las operaciones que acceden al sistema únicamente para procesar las operaciones de lectura; see Dispatcher para obtener más información.

Crear cálculos específicos de entorno

A efectos de evaluación comparativa, Adobe ha desarrollado algunas pruebas de referencia para instancias de autor independientes.

• Prueba de referencia 1
  Calcule el rendimiento máximo de un perfil de carga donde los usuarios realizan un simple ejercicio de creación de página sobre una carga base de 300 páginas existentes de naturaleza similar. Los pasos necesarios eran iniciar sesión en el sitio, crear una página con un SWF e imagen/texto, agregar una nube de etiquetas y, a continuación, activar la página.

  • Resultado
    El rendimiento máximo para un ejercicio de creación de página simple como el anterior (considerado como una transacción) se encontró en 1730 transacciones/hora.

• Prueba de referencia 2
  Calcule el rendimiento máximo cuando el perfil de carga tenga una combinación de creación de página nueva (10 %), modificación de una página existente (80 %) y creación y posterior modificación de una página sucesiva (10 %). La complejidad de las páginas sigue siendo la misma que en el perfil de la prueba de referencia 1. La modificación básica de la página se realiza añadiendo una imagen y modificando el contenido del texto. De nuevo, el ejercicio se realizó sobre una carga base de 300 páginas de la misma complejidad que la definida en la prueba de referencia 1.

  • Resultado
    El rendimiento máximo para un escenario de operación mixta de este tipo se encontró en 3252 transacciones por hora.

Las dos pruebas anteriores resaltan claramente que el rendimiento varía según el tipo de operación. Utilice las actividades del entorno como base para dimensionar el sistema. Obtendrá un mejor rendimiento con acciones menos intensivas, como la modificación (que también es más común).

Almacenamiento en caché

En el entorno de creación, la eficacia del almacenamiento en caché suele ser mucho menor, ya que los cambios en el sitio web son más frecuentes y también el contenido es altamente interactivo y personalizado. Con Dispatcher, puede almacenar en caché AEM bibliotecas, JavaScript, archivos CSS e imágenes de diseño. Esto acelera algunos aspectos del proceso de creación. Si configura el servidor web para que establezca encabezados adicionales para el almacenamiento en caché del explorador en estos recursos, se reducirá el número de solicitudes HTTP y, por lo tanto, se mejorará la capacidad de respuesta del sistema según la experiencia de los autores.

Autores que trabajan en paralelo

En el entorno de creación, el número de autores que trabajan en paralelo y la carga que sus interacciones añaden al sistema son los principales factores limitantes. Por lo tanto, le recomendamos que escale su sistema en función del rendimiento compartido de los datos.

Para estos escenarios, Adobe ejecutó pruebas de referencia en un clúster de dos nodos shared-nada de instancias de autor.

• Prueba de referencia 1a
  Con un clúster activo-activo de shared-nada de 2 instancias de autor, calcule el rendimiento máximo con un perfil de carga donde los usuarios realizan un simple ejercicio de creación de página sobre una carga base de 300 páginas existentes, todo de naturaleza similar.

  • Resultado
    El rendimiento máximo para un ejercicio de creación de página simple, como el anterior, (considerado como una transacción) se encuentra en transacciones de 2016/hora. Esto supone un aumento de aproximadamente el 16 % en comparación con una instancia de autor independiente para la misma prueba de referencia.

• Prueba de referencia 2b
  Con un clúster activo-activo de contenido compartido de nada de 2 instancias de autor, calcule el rendimiento máximo cuando el perfil de carga tenga una combinación de creación de página nueva (10 %), modificación de páginas existentes (80 %) y creación y modificación de una página sucesiva (10 %). La complejidad de la página sigue siendo la misma que en el perfil de la prueba de referencia 1. La modificación básica de la página se realiza añadiendo una imagen y modificando el contenido del texto. De nuevo, el ejercicio se realizó sobre una carga base de 300 páginas de complejidad igual a la definida en la prueba de referencia 1.

  • Resultado
    El rendimiento máximo para un escenario de operación mixta de este tipo se encontró en 6288 transacciones/hora. Esto supone un aumento de aproximadamente el 93 % en comparación con una instancia de autor independiente para la misma prueba de referencia.

Las dos pruebas anteriores resaltan claramente que AEM escala bien para los autores que realizan operaciones de edición básicas con AEM. En general, AEM es más eficaz en escalar las operaciones de lectura.

En un sitio web típico, la mayoría de la creación se produce durante la fase del proyecto. Una vez que el sitio web se pone en marcha, el número de autores que trabajan en paralelo normalmente se hunde en un promedio menor (modo operativo).

Puede calcular el número de equipos (o CPUs) necesarios para el entorno de creación de la siguiente manera:

n = numberOfParallelAuthors / 30

Esta fórmula puede servir como guía general para escalar CPUs cuando los autores realizan operaciones básicas con AEM. Se supone que el sistema y la aplicación están optimizados. Sin embargo, la fórmula no tendrá el valor "True" para funciones avanzadas como MSM o Assets (consulte las secciones siguientes).

Consulte también los comentarios adicionales sobre Paralelización y Optimización del rendimiento.

Hardware Recommendations

Normalmente, puede utilizar el mismo hardware para su entorno de creación que se recomienda para su entorno de publicación. Normalmente, el tráfico de sitios web es mucho menor en los sistemas de creación, pero la eficacia de la caché también es menor. Sin embargo, el factor fundamental aquí es el número de autores que trabajan en paralelo, junto con el tipo de acciones que se están realizando en el sistema. En general, el agrupamiento de AEM (del entorno de creación) es más eficaz para escalar las operaciones de lectura; en otras palabras, un clúster AEM escala bien con los autores que realizan operaciones de edición básicas.

Las pruebas de referencia en Adobe se realizaron utilizando el sistema operativo RedHat 5.5, que se ejecuta en una plataforma de hardware Hewlett-Packard ProLiant DL380 G5 con la siguiente configuración:

• Dos CPUs Intel Xeon X5450 de cuatro núcleos a 3,00 GHz
• 8 GB de RAM
• Broadcom NetXtreme II BCM5708 Gigabit Ethernet
• Controlador RAID HP Smart Array, caché de 256 MB
• Dos discos SAS de 146 GB a 10.000 RPM configurados como un conjunto de bandas RAID 0
• SPEC CINT2006 La puntuación de referencia de tasa es 110

AEM instancias se ejecutaban con un tamaño mínimo de pila de 256M, un tamaño máximo de pila de 1024M.

Publicar cálculos específicos de entornos

Eficiencia de almacenamiento en caché y tráfico

La eficacia de la caché es crucial para la velocidad del sitio web. La siguiente tabla muestra cuántas páginas por segundo puede gestionar un sistema de AEM optimizado mediante un proxy inverso, como Dispatcher:

La proporción de caché es el porcentaje de páginas que el despachante puede devolver sin tener que acceder a AEM. El 100 % indica que Dispatcher responde a todas las solicitudes, 0 % significa que AEM calcula cada página.

Complejidad de las plantillas y las aplicaciones

Si utiliza plantillas complejas, AEM necesitará más tiempo para procesar una página. Las páginas tomadas de la caché no se ven afectadas por esto, pero el tamaño de la página sigue siendo relevante cuando se considera el tiempo de respuesta general. La representación de una página compleja puede tardar diez veces más que la representación de una página simple.

Fórmula

Con la fórmula siguiente, puede calcular una estimación de la complejidad general de su solución AEM:

complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)

En función de la complejidad, puede determinar el número de servidores (o núcleos de CPU) que necesita para el entorno de publicación de la siguiente manera:

n = (traffic * complexity / 1000 ) * activations

Las variables de la ecuación son las siguientes:

Si tiene un sitio web más complejo, también necesita servidores web más potentes para que AEM responder a una solicitud en un tiempo aceptable.

• Complejidad por debajo de 4: ・ 1024 MB de RAM JVM*
  ・ CPU de bajo a mediano rendimiento

• Complejidad entre 4 y 8: ・ 2048 MB de RAM JVM*
  ・ CPU de mediano a alto rendimiento

• Complejidad superior a 8: ・ 4096 MB de RAM JVM*
  ・ CPU de alto a alto rendimiento

Cálculos específicos adicionales de casos de uso

Además del cálculo de una aplicación web predeterminada, es posible que deba tener en cuenta factores específicos para los siguientes casos de uso. Los valores calculados se añaden al cálculo predeterminado.

Consideraciones específicas de los recursos

El procesamiento extensivo de recursos digitales requiere recursos de hardware optimizados, los factores más relevantes son el tamaño de la imagen y el rendimiento máximo de las imágenes procesadas.

Asigne al menos 16 GB de memoria y configure la variable Recurso de actualización DAM flujo de trabajo para usar la variable paquete Camera Raw para la ingesta de imágenes sin procesar.

Administrador de varios sitios

El consumo de recursos al utilizar AEM MSM en un entorno de creación depende en gran medida de los casos de uso específicos. Los factores básicos son:

• Número de Live Copies
• Periodicidad de los lanzamientos
• Tamaño del árbol de contenido que desea desplegar
• Funcionalidad conectada de las acciones de despliegue

La prueba del caso de uso planificado con un extracto de contenido representativo puede ayudarle a comprender mejor el consumo de recursos. Si extrapola los resultados con el rendimiento planificado, puede evaluar los recursos adicionales necesarios para el MSM AEM.

Tenga en cuenta también que los autores que trabajan en paralelo percibirán efectos secundarios de rendimiento si AEM casos de uso de MSM consumen más recursos de los previstos.

Consideraciones sobre el tamaño de AEM Communities

AEM sitios que incluyen funciones de AEM Communities (sitios de la comunidad) experimentan un alto nivel de interacción de los visitantes del sitio (miembros) en el entorno de publicación.

Las consideraciones sobre el tamaño de un sitio de la comunidad dependen de la interacción esperada de los miembros de la comunidad y de si el rendimiento óptimo del contenido de la página es de mayor importancia.

Los miembros de contenido generado por el usuario (UGC) enviados se almacenan por separado del contenido de la página. Aunque la plataforma de AEM utiliza un almacén de nodos que replica el contenido del sitio de autor a publicación, AEM Communities utiliza un único almacén común para UGC que nunca se replica.

Para el almacén UGC, es necesario elegir un proveedor de recursos de almacenamiento (SRP), que influye en la implementación elegida.
Consulte

• Almacenamiento de contenido de la comunidad
• Topologías recomendadas para comunidades

Recursos de Business.Adobe.com

Ecommerce Integrations Auto Form Fill Asset Collections Version History Customer Experience Management Headless Cms