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
Velocidad de cómputo
Rendimiento de E/S
Disco duro
Memoria
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.
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:
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:
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.
El directorio temporal de una instancia de producción debe tener al menos 6 GB de espacio disponible.
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.
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:
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.
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.
La tasa de rendimiento no distingue entre tipos de transacciones dentro de un perfil de carga. El método utilizado para medir el rendimiento garantiza que una proporción fija de cada tipo de transacción se incluya en la carga de trabajo.
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).
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.
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.
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.
La tasa de rendimiento no distingue entre tipos de transacciones dentro de un perfil de carga. El método utilizado para medir el rendimiento garantiza que una proporción fija de cada tipo de transacción se incluya en la carga de trabajo.
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.
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:
AEM instancias se ejecutaban con un tamaño mínimo de pila de 256M, un tamaño máximo de pila de 1024M.
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:
Relación de caché | Páginas/s (pico) | Millones de páginas por día (media) |
---|---|---|
100% | 1000-2000 | 35-70 |
99 % | 910 | 32 |
95 % | 690 | 25 |
90% | 520 | 18 |
60% | 220 | 8 |
0% | 100 | 3.5 |
Renuncia de responsabilidad: Los números se basan en una configuración de hardware predeterminada y pueden variar según el hardware específico utilizado.
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.
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.
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:
tráfico | El tráfico máximo esperado por segundo. Puede estimar esto como el número de visitas al día de la página, dividido por 35 000. |
applicationComplexity | Utilice 1 para una aplicación simple, 2 para una aplicación compleja o un valor intermedio:
|
cacheRatio | El porcentaje de páginas que salen de la caché de Dispatcher. Utilice 1 si todas las páginas provienen de la caché, o 0 si todas las páginas están calculadas por AEM. |
templateComplexity | Utilice un valor entre 1 y 10 para indicar la complejidad de las plantillas. Los números más altos indican plantillas más complejas, utilizando el valor 1 para sitios con un promedio de 10 componentes por página, el valor 5 para un promedio de página de 40 componentes y 10 para un promedio de más de 100 componentes. |
activaciones | Número de activaciones promedio (replicación de páginas y recursos de tamaño medio desde el autor hasta el nivel de publicación) por hora dividido entre x, donde x es el número de activaciones realizadas en un sistema sin efectos secundarios de rendimiento para otras tareas procesadas por el sistema. También puede predefinir un valor inicial pesimista como x = 100. |
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
* Reserve suficiente RAM para su sistema operativo además de la memoria necesaria para su JVM.
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.
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.
Un mayor rendimiento de las imágenes significa que los recursos informáticos deben ser capaces de mantenerse al ritmo de las E/S del sistema y viceversa. Por ejemplo, si la importación de imágenes inicia los flujos de trabajo, la carga de muchas imágenes a través de WebDAV podría provocar un atraso en los flujos de trabajo.
El uso de discos separados para TarPM, almacén de datos e índice de búsqueda puede ayudar a optimizar el comportamiento de E/S del sistema (sin embargo, normalmente tiene sentido mantener el índice de búsqueda localmente).
Consulte también la Guía de rendimiento de recursos.
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:
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.
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