Al cambiar el tamaño del entorno para una implementación de Adobe Experience Manager Assets, es importante asegurarse de que haya suficientes recursos disponibles en términos de disco, CPU, memoria, E/S y rendimiento de red. Para cambiar el tamaño de muchos de estos recursos es necesario conocer la cantidad de recursos que se están cargando en el sistema. Si no hay una métrica mejor disponible, puede dividir el tamaño de la biblioteca existente por la edad de la biblioteca para encontrar la tasa a la que se crean los recursos.
Un error común que se produce al cambiar el tamaño del espacio en disco necesario para una implementación de Assets es basar los cálculos en el tamaño de las imágenes sin procesar que se van a introducir en el sistema. De forma predeterminada, Experience Manager crea tres representaciones además de la imagen original para utilizarlas en la renderización de los elementos de la interfaz de usuario Experience Manager. En implementaciones anteriores, se ha observado que estas representaciones suponen el doble del tamaño de los recursos ingeridos.
La mayoría de los usuarios definen representaciones personalizadas, además de las representaciones predeterminadas. Además de las representaciones, Assets permite extraer subrecursos de tipos de archivo comunes, como InDesign y Illustrator.
Por último, las funciones de control de versiones de AEM almacenan duplicados de los recursos en el historial de versiones. Puede configurar las versiones que desea depurar con frecuencia. Sin embargo, muchos usuarios eligen conservar versiones en el sistema durante mucho tiempo, lo que consume espacio de almacenamiento adicional.
Teniendo en cuenta estos factores, necesita una metodología para calcular un espacio de almacenamiento aceptablemente preciso para almacenar los activos de los usuarios.
Al realizar los pasos del 1 al 9, puede determinar lo siguiente:
Puede especificar estos números en la hoja de cálculo Tamaño de red para determinar el espacio total necesario para el almacén de datos. También es una herramienta útil para determinar el impacto de mantener versiones de recursos o modificar recursos en Experience Manager en el crecimiento del disco.
Los datos de ejemplo rellenados en la herramienta muestran la importancia de realizar los pasos mencionados. Si cambia el tamaño del almacén de datos en función únicamente de las imágenes sin procesar que se están cargando (1 TB), es posible que haya subestimado el tamaño del repositorio en un factor de 15.
Para grandes almacenes de datos, puede implementar un almacén de datos compartido a través de un almacén de datos de archivos compartidos en una unidad conectada a la red o a través de un almacén de datos S3. En este caso, las instancias individuales no necesitan mantener una copia de los binarios. Además, un almacén de datos compartido facilita la replicación sin binarios y ayuda a reducir el ancho de banda utilizado para replicar recursos para publicar entornos o descargar instancias.
El almacén de datos se puede compartir entre una instancia de autor principal y en espera para minimizar el tiempo que se tarda en actualizar la instancia en espera con los cambios realizados en la instancia principal. Adobe recomienda compartir el almacén de datos entre una instancia de autor principal y las instancias de autor de descarga para reducir los gastos generales en la descarga del flujo de trabajo. También puede compartir el almacén de datos entre el autor y las instancias de publicación para minimizar el tráfico durante la replicación.
Debido a algunos inconvenientes, no se recomienda compartir un almacén de datos en todos los casos.
Al tener un almacén de datos compartido, introduce un solo punto de fallo en una infraestructura. Considere un escenario en el que su sistema tiene un autor y dos instancias de publicación, cada una con su propio almacén de datos. Si alguno de ellos se bloquea, los otros dos pueden seguir ejecutándose. Sin embargo, si se comparte el almacén de datos, una única falla de disco puede eliminar toda la infraestructura. Por lo tanto, asegúrese de mantener una copia de seguridad del almacén de datos compartido desde el que pueda restaurar el almacén de datos rápidamente.
Se prefiere implementar el servicio AWS S3 para los almacenes de datos compartidos porque reduce significativamente la probabilidad de fallo en comparación con las arquitecturas de disco normales.
Los almacenes de datos compartidos también aumentan la complejidad de las operaciones, como la colección de residuos. Normalmente, la recolección de basura para un almacén de datos independiente se puede iniciar con un solo clic. Sin embargo, los almacenes de datos compartidos requieren operaciones de barrido de marca en cada miembro que utiliza el almacén de datos, además de ejecutar la colección real en un solo nodo.
Para las operaciones de AWS, la implementación de una única ubicación central (mediante S3), en lugar de crear una matriz RAID de volúmenes EBS, puede compensar de forma significativa la complejidad y los riesgos operativos del sistema.
Un almacén de datos compartido requiere que los binarios se almacenen en una unidad montada en red que se comparte entre todas las instancias. Dado que se accede a estos binarios a través de una red, el rendimiento del sistema se ve afectado negativamente. Puede mitigar parcialmente el impacto mediante el uso de una conexión de red rápida a una matriz rápida de discos. Sin embargo, esta es una propuesta cara. En el caso de las operaciones de AWS, todos los discos son remotos y requieren conectividad de red. Los volúmenes efímeros pierden datos cuando la instancia se inicia o se detiene.
La latencia en implementaciones S3 se introduce mediante los subprocesos de escritura en segundo plano. Los procedimientos de copia de seguridad deben tener en cuenta esta latencia y cualquier procedimiento de descarga. Es posible que el recurso S3 no esté presente en S3 cuando se inicie un trabajo de descarga. Además, los índices de Lucene pueden seguir incompletos al realizar una copia de seguridad. Se aplica a cualquier archivo con distinción de tiempo escrito en el almacén de datos S3 y al que se accede desde otra instancia.
Es difícil obtener cifras precisas de tamaño para un almacén de nodos o almacén de documentos debido a los recursos que consumen los siguientes:
Dado que los binarios se almacenan en el almacén de datos, cada binario ocupa algún espacio. La mayoría de los repositorios tienen un tamaño inferior a 100 GB. Sin embargo, puede haber repositorios más grandes de hasta 1 TB de tamaño. Además, para realizar la compactación sin conexión, se necesita suficiente espacio libre en el volumen para reescribir el repositorio compactado junto con la versión compactada previamente. Una buena regla general es cambiar el tamaño del disco a 1,5 veces el tamaño esperado para el repositorio.
Para el repositorio, utilice SSD o discos con un nivel IOPS bueno a 3000. Para eliminar las posibilidades de que IOPS introduzca cuellos de botella en el rendimiento, supervise los niveles de espera de E/S de CPU para detectar signos tempranos de problemas.
Assets tiene una serie de casos de uso que hacen que el rendimiento de la red sea más importante que en muchos de nuestros Experience Manager proyectos. Un cliente puede tener un servidor rápido, pero si la conexión de red no es lo suficientemente grande como para soportar la carga de los usuarios que cargan y descargan recursos del sistema, entonces seguirá pareciendo lenta. Existe una buena metodología para determinar el punto de interrupción en la conexión de red de un usuario a Experience Manager en Experience Manager Consideraciones de recursos para la experiencia del usuario, el tamaño de las instancias, la evaluación del flujo de trabajo y la topología de red.
Si agrega la aplicación de escritorio Experience Manager a la mezcla, los problemas de red se vuelven más graves debido a las ineficiencias en el protocolo WebDAV.
Para ilustrar estas ineficiencias, el Adobe probó el rendimiento del sistema mediante WebDAV en el sistema operativo X. Se abrió, editó y guardó un archivo de InDesign de 3,5 MB. Se formularon las siguientes observaciones:
Al analizar el tiempo de ahorro promedio para los archivos a través de WebDAV, se encontró que el rendimiento aumenta drásticamente a medida que el ancho de banda aumenta hasta el nivel de 5-10 Mbps. Por lo tanto, Adobe recomienda que cada usuario que acceda al sistema simultáneamente tenga al menos 10 Mbps de velocidad de carga y 5-10 Mbps de ancho de banda.
Para obtener más información, consulte Resolución de problemas Experience Manager aplicación de escritorio.
Al dimensionar una implementación, es importante tener en cuenta las limitaciones del sistema. Si la implementación propuesta supera estas limitaciones, utilice estrategias creativas, como la partición de los recursos en varias implementaciones de Assets.
El tamaño del archivo no es el único factor que contribuye a los problemas de falta de memoria (OOM). También depende de las dimensiones de la imagen. Puede evitar problemas con OOM proporcionando un tamaño de pila más alto al comenzar AEM.
Además, puede editar la propiedad de tamaño de umbral del componente com.day.cq.dam.commons.handler.StandardImageHandler
en Configuration Manager para utilizar un archivo temporal intermedio bueno a cero.
El límite en el número de archivos que pueden existir en un almacén de datos puede ser de 2.1 billones debido a las limitaciones del sistema de archivos. Es probable que el repositorio encuentre problemas debido a un gran número de nodos mucho antes de alcanzar el límite del almacén de datos.
Si las representaciones se generan incorrectamente, utilice la biblioteca Camera Raw. Sin embargo, en este caso, el lado más largo de la imagen no debe ser bueno de 65000 píxeles. Además, la imagen no debe contener más de 512 MP (512 * 1024 * 1024 píxeles)'. El tamaño del recurso es insignificante.
Es difícil estimar con precisión el tamaño del archivo TIFF compatible de serie (OOTB) con una pila específica para Experience Manager porque hay factores adicionales, como el procesamiento de la influencia del tamaño de los píxeles. Es posible que Experience Manager pueda procesar un archivo de tamaño de 255 MB OOTB, pero no puede procesar un tamaño de archivo de 18 MB porque este último consta de un número inusualmente mayor de píxeles en comparación con el primero.
De forma predeterminada, Experience Manager permite cargar recursos de tamaños de archivo de hasta 2 GB. Para cargar recursos muy grandes en AEM, consulte Configuración para cargar recursos muy grandes.