Pautas para configurar el tamaño del hardware

Estas directrices de tamaño oferta 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 previsto 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 computacional

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

• Rendimiento de E/S

  • Rendimiento y eficacia 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 activos al mismo tiempo

Arquitectura

Una configuración de AEM típica consiste en un autor y un entorno de publicación. Estos entornos tienen diferentes requerimientos en cuanto al tamaño del hardware subyacente y a la configuración del sistema. Las consideraciones detalladas para ambos entornos se describen en las secciones entorno de creación y entorno de publicación.

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

• Entorno
  de desarrolloDesarrollar nuevas características o realizar cambios significativos. Lo mejor es trabajar con un entorno de desarrollo por desarrollador (generalmente instalaciones locales en sus sistemas personales).

• Crear
  entorno de pruebaPara comprobar los cambios. El número de entornos de prueba puede variar en función de los requisitos del proyecto (por ejemplo, por separado para control de calidad, pruebas de integración o pruebas de aceptación del usuario).

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

• Crear
  entorno de producciónPara que los autores editen contenido.

• Publicar
  entorno de producciónPara ofrecer contenido publicado.

Además, los entornos pueden variar, desde un sistema de un solo servidor que ejecuta AEM y un servidor de aplicaciones, hasta un conjunto de instancias agrupadas de varios servidores y varias CPU de 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 de tamaño de hardware

En las secciones que figuran a continuación se proporciona orientación sobre cómo calcular los requisitos de hardware, teniendo en cuenta diversas consideraciones. Para 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 referencia para un proyecto específico. Asegúrese de aplicar los consejos proporcionados en la documentación de optimización del rendimiento antes de realizar pruebas de referencia y utilizar sus resultados para cualquier cálculo del tamaño del 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 y 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 admitidos

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 los cambios de contenido y, por tanto, la creación de versiones de contenido
• volumen de las representaciones de recursos DAM que se generarán
• el crecimiento global 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 disponible en disco cae por debajo de un valor crítico, el proceso se cancelará. El valor crítico es el 25% del espacio de disco actual del repositorio y no se puede configurar. Se recomienda ajustar el tamaño del 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 arreglos redundantes de discos independientes (RAID, por ejemplo, RAID 10) para la redundancia de datos.

Virtualización

AEM funciona bien en entornos virtualizados, pero puede haber factores como CPU o E/S que no pueden equipararse 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 de su entorno es necesaria para comprender con precisión qué recursos se necesitarán.

Paralelización de instancias de AEM

Error de seguridad

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

Capacidad de ampliación de los recursos del sistema

Mientras todos los sistemas están en funcionamiento, hay disponible un mayor rendimiento computacional. Que el rendimiento adicional no es necesariamente lineal con el número de nodos de 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 casos de uso específicos del proyecto web en particular:

• Desde el punto de vista de la seguridad frente a fallos, es necesario determinar, para todos los entornos, la gravedad del fallo y el tiempo de compensación del fallo en función del tiempo que tarde en recuperarse un nodo de clúster.
• Para el aspecto de la escalabilidad, el número de operaciones de escritura es básicamente el factor más importante; consulte 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 operaciones que accedan al sistema únicamente para procesar operaciones de lectura; consulte Dispatcher para obtener más información.

Crear cálculos específicos de entorno

Con fines de referencia, Adobe ha desarrollado algunas pruebas de referencia para instancias independientes de creación.

• Prueba comparativa 1
  Calcule el rendimiento máximo de un perfil de carga en el que 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 y una imagen o texto, agregar una nube de etiquetas y, a continuación, activar la página.

  • ​
    ResultadoEl 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 comparativa 2
  Calcule el rendimiento máximo cuando el perfil de carga tiene una combinación de creación de página nueva (10%), modificación de una página existente (80%) y posterior modificación de una página en sucesión (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 agregando 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 definida en la prueba de referencia 1.

  • ​
    ResultadoSe encontró que el rendimiento máximo para un escenario de operación de mezcla era de 3252 transacciones por hora.

Las dos pruebas anteriores destacan claramente que el rendimiento varía según el tipo de operación. Utilice las actividades del entorno como base para ajustar el tamaño del 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 del autor, la eficacia de almacenamiento en caché suele ser mucho menor, ya que los cambios en el sitio web son más frecuentes y el contenido es muy interactivo y personalizado. Con el despachante, 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 además encabezados para el almacenamiento en caché del navegador en estos recursos, se reducirá el número de solicitudes HTTP y se mejorará la capacidad de respuesta del sistema según la experiencia de los autores.

Autores que trabajan en paralelo

En el entorno del autor, 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 instancias de autor de dos nodos compartido de nada.

• Prueba comparativa 1
  aCon un clúster activo-activo de no compartir nada de 2 instancias de creación, calcule el rendimiento máximo con un perfil de carga en el que 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.

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

• Prueba comparativa 2
  bCon un clúster activo-activo de contenido compartido de 2 instancias de creación, 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 en sucesión (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 agregando una imagen y modificando el contenido del texto. Nuevamente, el ejercicio se realizó sobre una carga base de 300 páginas de complejidad, tal como se define en la prueba de referencia 1.

  • ​
    ResultadoEl rendimiento máximo para un escenario de operación mixta de este tipo fue de 6288 transacciones/hora. Se trata de 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 básicas de edición con AEM. En general, AEM es más eficaz en la escala de las operaciones de lectura.

En un sitio web típico, la mayoría de la creación se realiza durante la fase del proyecto. Después de que el sitio web se ponga en marcha, el número de autores que trabajan en paralelo suele reducirse a una media inferior (modo operativo).

Puede calcular el número de equipos (o CPU) 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 CPU cuando los autores realizan operaciones básicas con AEM. Supone que el sistema y la aplicación están optimizados. Sin embargo, la fórmula no tendrá el valor true para características avanzadas como MSM o Recursos (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 el entorno de creación que se recomienda para el entorno de publicación. Normalmente, el tráfico de sitios web es mucho menor en los sistemas de creación, pero la eficiencia 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, la agrupación de AEM (del entorno de creación) es más eficaz para escalar las operaciones de lectura; en otras palabras, un clúster de 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 CPU Intel Xeon X5450 de cuatro núcleos a 3,00 GHz
• 8 GB de RAM
• Gigabit Ethernet Broadcom NetXtreme II BCM5708
• Controladora 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 del entorno

Eficacia y tráfico de almacenamiento en caché

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

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

Complejidad de plantillas y aplicaciones

Si utiliza plantillas complejas AEM necesitará más tiempo para procesar una página. Esto no afecta a las páginas tomadas de la caché, pero el tamaño de la página sigue siendo relevante cuando se considera el tiempo de respuesta general. El procesamiento de una página compleja puede tardar diez veces más que el procesamiento de una página simple.

Fórmula

Con la fórmula siguiente, puede calcular una estimación de la complejidad general de la 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 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 medio a alto rendimiento

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

Cálculos específicos de caso de uso adicionales

Además del cálculo para una aplicación Web predeterminada, es posible que deba considerar factores específicos para los siguientes casos de uso. Los valores calculados se añadirán 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 pila y configure el recurso de actualización de DAM flujo de trabajo para utilizar el paquete Camera Raw para la ingestión de imágenes sin procesar.

Administrador de múltiples sitios

El consumo de recursos al usar 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 se va a desplegar
• Funcionalidad conectada de las acciones de implementación

La prueba del caso de uso planificado con un fragmento 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 trabajen en paralelo percibirán efectos secundarios de rendimiento si los casos de uso de MSM AEM consumen más recursos de los previstos.

Consideraciones de 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 de tamaño de un sitio de 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 del contenido generado por el usuario (UGC) enviados se almacenan por separado del contenido de la página. Mientras que la plataforma de AEM utiliza un almacén de nodos que replica el contenido del sitio del autor para publicarlo, 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 las comunidades

Recursos de Business.Adobe.com

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