Optimización del rendimiento performance-optimization

Un problema clave es el tiempo que tarda el sitio web en responder a las solicitudes de los visitantes. Aunque este valor variará para cada solicitud, se puede definir un valor de objetivo promedio. Una vez comprobado que este valor es alcanzable y mantenible, puede utilizarse para monitorear el rendimiento del sitio web e indicar el desarrollo de posibles problemas.

Los tiempos de respuesta que va a buscar serán diferentes en los entornos de autor y publicación, lo que refleja las diferentes características de la audiencia de destino:

Entorno de creación author-environment

Este entorno lo utilizan los autores que introducen y actualizan contenido. Debe satisfacer a un pequeño número de usuarios, cada uno de los cuales genera un número elevado de solicitudes de rendimiento intensivo al actualizar páginas de contenido y los elementos individuales de esas páginas.

Entorno de publicación publish-environment

Este entorno contiene contenido que puede poner a disposición de los usuarios. En este caso, el número de solicitudes es incluso bueno y la velocidad es igualmente vital, pero dado que la naturaleza de las solicitudes es menos dinámica, se pueden aplicar mecanismos adicionales de mejora del rendimiento; como almacenar en caché el contenido o el equilibrio de carga.

Metodología de optimización del rendimiento performance-optimization-methodology

Una metodología de optimización del rendimiento para AEM proyectos se puede resumir en cinco reglas muy sencillas que se pueden seguir para evitar problemas de rendimiento desde el principio:

Estas reglas, en gran medida, se aplican a los proyectos web en general y son relevantes para los administradores de proyectos y sistemas a fin de garantizar que sus proyectos no enfrenten desafíos de rendimiento cuando llegue el momento de lanzamiento.

Planificación para la optimización planning-for-optimization

Alrededor del 10% del esfuerzo del proyecto debe planificarse para la fase de optimización del rendimiento. Por supuesto, los requisitos reales de optimización del rendimiento dependerán del nivel de complejidad de un proyecto y de la experiencia del equipo de desarrollo. Aunque el proyecto puede (en última instancia) no requerir todo el tiempo asignado, es recomendable planificar siempre la optimización del rendimiento en la región sugerida.

Siempre que sea posible, un proyecto debe iniciarse de forma flexible para una audiencia limitada con el fin de obtener experiencia en la vida real y realizar más optimizaciones, sin la presión adicional que sigue a un anuncio completo.

Una vez que esté "activo", la optimización del rendimiento no ha finalizado. Este es el momento en el que experimenta la carga "real" en su sistema. Es importante planificar ajustes adicionales después del lanzamiento.

Dado que la carga del sistema cambia y los perfiles de rendimiento del sistema cambian con el tiempo, se debe programar una "configuración" o "comprobación de estado" de rendimiento a intervalos de 6 a 12 meses.

Simular realidad simulate-reality

Si se activa con un sitio web y después del lanzamiento descubre que se encuentra con problemas de rendimiento, solo hay una razón para ello: Las pruebas de carga y rendimiento no simulaban la realidad lo suficientemente de cerca.

Simular la realidad es difícil y el esfuerzo que usted querrá razonablemente invertir en ser "real" depende de la naturaleza de su proyecto. "Real" significa no solo "código real" y "tráfico real", sino también "contenido real", especialmente con respecto al tamaño y la estructura del contenido. Tenga en cuenta que las plantillas pueden comportarse de forma completamente diferente según el tamaño y la estructura del repositorio.

Establecer objetivos sólidos establish-solid-goals

No debe subestimarse la importancia de establecer adecuadamente los objetivos de ejecución. A menudo, una vez que las personas se centran en objetivos de rendimiento específicos, es muy difícil cambiar estos objetivos después, incluso si se basan en suposiciones salvajes.

El establecimiento de objetivos de rendimiento sólidos y buenos es en realidad una de las áreas más complicadas. A menudo es mejor recopilar "logs" de la vida real y puntos de referencia de un sitio web comparable (por ejemplo, el predecesor del nuevo sitio web).

Mantener relevancia stay-relevant

Es importante optimizar un cuello de botella a la vez. Si intenta hacer cosas en paralelo sin validar el impacto de una optimización, perderá el seguimiento de qué medida de optimización ayudó en realidad.

Ciclos de iteración ágiles agile-iteration-cycles

El ajuste del rendimiento es un proceso iterativo que implica, mide, analiza, optimiza y valida hasta que se alcanza el objetivo. Para tener en cuenta este aspecto adecuadamente, implemente un proceso de validación ágil en la fase de optimización en lugar de un proceso de prueba de mayor peso después de cada iteración.

Esto significa en gran medida que el desarrollador que implementa la optimización debería tener una forma rápida de saber si la optimización ya ha alcanzado el objetivo. Esta información es valiosa, ya que cuando se alcanza el objetivo, la optimización finaliza.

Directrices básicas de rendimiento basic-performance-guidelines

En términos generales, mantenga sus solicitudes html sin almacenar en caché a menos de 100 ms. Más concretamente, puede servir de guía:

Los números anteriores asumen las siguientes condiciones:

Hay una serie de problemas que con frecuencia contribuyen a los problemas de rendimiento. Estas giran principalmente en torno a:

El ajuste a nivel de JVM y OS no suele dar lugar a grandes avances en el rendimiento y, por lo tanto, debe realizarse al final del ciclo de optimización.

La forma en que se estructura un repositorio de contenido también puede afectar al rendimiento. Para obtener el mejor rendimiento, el número de nodos secundarios conectados a nodos individuales en un repositorio de contenido no debe superar los 1000 (como regla general).

Sus mejores amigos durante un ejercicio de optimización de rendimiento habitual son:

Rendimiento al cargar y editar recursos digitales performance-when-loading-and-editing-digital-assets

Debido al gran volumen de datos implicados al cargar y editar recursos digitales, el rendimiento puede convertirse en un problema.

Dos cosas afectan al rendimiento aquí:

Para mejorar el rendimiento, puede considerar lo siguiente:

Monitorización del rendimiento performance-monitoring

El rendimiento (o la falta de él) es una de las primeras cosas que los usuarios notan, por lo que, al igual que con cualquier aplicación con una interfaz de usuario, el rendimiento es fundamental. Para optimizar el rendimiento de la instalación de AEM, debe monitorizar varios atributos de la instancia y su comportamiento.

Para obtener información sobre cómo realizar la supervisión del rendimiento, consulte Monitorización del rendimiento.

Los problemas que causan problemas de rendimiento a menudo son difíciles de rastrear, incluso cuando sus efectos son fáciles de ver.

Un punto de partida básico es un buen conocimiento de su sistema cuando está funcionando con normalidad. A menos que sepa cómo se "ve" y "se comporta" su entorno cuando está funcionando correctamente, puede ser difícil localizar el problema cuando el rendimiento se deteriora. Esto significa que debería pasar algún tiempo investigando su sistema cuando se está ejecutando sin problemas y asegurarse de que recopilar información de rendimiento es una tarea constante. Esto le proporcionará una base para la comparación en caso de que sufra el rendimiento.

El diagrama siguiente ilustra la ruta que puede tomar una solicitud de contenido AEM y, por lo tanto, el número de elementos diferentes que pueden afectar al rendimiento.

El rendimiento también es un equilibrio entre volumen y capacidad:

Volumen Cantidad de salida que procesa y entrega el sistema.

Capacidad La capacidad del sistema para entregar el volumen.

Esto se puede ilustrar en varias ubicaciones de la cadena web.

Hay varias áreas funcionales que a menudo son responsables de afectar el rendimiento:

Reglas básicas sobre rendimiento basic-rules-regarding-performance

Algunas reglas deben tenerse en cuenta al optimizar el rendimiento:

Configuración del rendimiento configuring-for-performance

Ciertos aspectos de AEM (y/o el repositorio subyacente) se pueden configurar para optimizar el rendimiento. Las siguientes son posibilidades y sugerencias, debe asegurarse de si utiliza la funcionalidad en cuestión antes de realizar cambios o cómo hacerlo.

Indexación de búsqueda search-indexing

A partir de AEM 6.0, Adobe Experience Manager utiliza una arquitectura de repositorios basada en Oak.

Puede encontrar la información de indexación actualizada aquí:

Procesamiento De Flujo De Trabajo Simultáneo concurrent-workflow-processing

Limite el número de procesos de flujo de trabajo que se ejecutan simultáneamente para mejorar el rendimiento. De forma predeterminada, el motor de flujo de trabajo procesa tantos flujos de trabajo en paralelo como procesadores disponibles para la VM de Java. Cuando los pasos del flujo de trabajo requieren grandes cantidades de recursos de procesamiento (RAM o CPU), la ejecución de varios de estos flujos de trabajo en paralelo puede suponer una gran demanda para los recursos de servidor disponibles.

Por ejemplo, cuando se cargan imágenes (o recursos DAM en general), los flujos de trabajo importan automáticamente las imágenes a DAM. Las imágenes suelen ser de alta resolución y pueden consumir fácilmente cientos de MB de memoria para su procesamiento. El manejo de estas imágenes en paralelo coloca una carga alta en el subsistema de memoria y en el recolector de basura.

El motor de flujo de trabajo utiliza colas de trabajos de Apache Sling para gestionar y programar el procesamiento de elementos de trabajo. Los siguientes servicios de cola de trabajos se han creado de forma predeterminada desde la fábrica del servicio Apache Sling Job Queue Configuration para procesar los trabajos de flujo de trabajo:

Configure estos servicios para limitar el número máximo de procesos de flujo de trabajo que se ejecuten simultáneamente.

Nota: La configuración de estas colas de trabajos afecta a todos los flujos de trabajo a menos que haya creado una cola de trabajos para un modelo de flujo de trabajo específico (consulte Configuración de la cola para un modelo de flujo de trabajo específico más abajo).

Configuración en el repositorio configuration-in-the-repo

Si está configurando los servicios uso de un nodo sling:OsgiConfig, debe encontrar el PID de los servicios existentes, por ejemplo: org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. Puede descubrir el PID mediante la consola web.

Debe configurar la propiedad denominada queue.maxparallel.

Configuración en la consola web configuration-in-the-web-console

Para configurar estos servicios uso de la consola web, busque los elementos de configuración existentes debajo de la fábrica del servicio Apache Sling Job Queue Configuration.

Debe configurar la propiedad denominada Cantidad máxima de trabajos paralelos.

Configuración de la cola para un flujo de trabajo específico configure-the-queue-for-a-specific-workflow

Cree una cola de trabajos para un modelo de flujo de trabajo específico para que pueda configurar la gestión de trabajos para ese modelo de flujo de trabajo. De este modo, las configuraciones afectan al procesamiento de un flujo de trabajo específico, mientras que la configuración de la cola de flujo de trabajo predeterminada de Granite controla el procesamiento de otros flujos de trabajo.

Cuando se ejecutan los modelos de flujo de trabajo, crean trabajos de Sling para un tema específico. De forma predeterminada, el tema coincide con los temas configurados para la cola general de flujo de trabajo de Granite o la cola de trabajos de proceso externo de Granite Workflow:

Los temas de trabajo reales que generan los modelos de flujo de trabajo incluyen el sufijo específico del modelo. Por ejemplo, el modelo de flujo de trabajo de DAM Update Asset genera trabajos con el siguiente tema:

com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model

Por lo tanto, puede crear una cola de trabajos para el tema que coincida con los temas del trabajo del modelo de flujo de trabajo. La configuración de las propiedades de la cola relacionadas con el rendimiento afecta únicamente al modelo de flujo de trabajo que genera los trabajos que coinciden con el tema de la cola.

El siguiente procedimiento crea una cola de trabajos para un flujo de trabajo, utilizando el flujo de trabajo de recursos de actualización de DAM como ejemplo.

Servicio de sincronización de recursos DAM AEM cq-dam-asset-synchronization-service

La variable AssetSynchronizationService se utiliza para sincronizar activos desde repositorios montados (incluidos LiveLink, Documentum, entre otros). De forma predeterminada, esto hace una comprobación regular cada 300 segundos (5 minutos), por lo que si no utiliza repositorios montados, puede desactivar este servicio.

Esto se hace mediante configuración del servicio OSGi Servicio de sincronización de recursos CQ DAM para configurar la variable Período de sincronización ( scheduler.period) a (como mínimo) 1 año (definido en segundos).

Varias instancias DAM multiple-dam-instances

La implementación de varias instancias de DAM puede ayudar al rendimiento cuando, por ejemplo:

Otras consideraciones son:

Prácticas recomendadas para garantizar la calidad best-practices-for-quality-assurance

El rendimiento es de gran importancia para su entorno de publicación. Por lo tanto, debe planificar y analizar cuidadosamente las pruebas de rendimiento que realizará para el entorno de publicación al implementar el proyecto.

Esta sección tiene como objetivo proporcionar una visión general estandarizada de los problemas relacionados con la definición de un concepto de prueba específicamente para las pruebas de rendimiento en su publicar entorno. Esto es de interés principalmente para los ingenieros de control de calidad, los directores de proyectos y los administradores de sistemas.

A continuación se incluye un enfoque estandarizado de las pruebas de rendimiento para una aplicación AEM en el Publicación entorno. Esto incluye las siguientes 5 fases:

El control es un proceso adicional y completo, necesario pero no limitado a las pruebas.

Verificación del conocimiento verification-of-knowledge

Un primer paso es documentar la información de base que necesita conocer antes de comenzar a probar:

Arquitectura de prueba test-architecture

Debe documentar claramente la arquitectura del entorno de prueba que se utiliza para las pruebas de rendimiento.

Necesitará una reproducción del entorno de publicación de producción planificado, junto con Dispatcher y Load Balancer.

Mapa de aplicaciones application-map

Para obtener una descripción general clara, puede crear un mapa de toda la aplicación (puede que lo tenga de las pruebas en el entorno Autor).

Una representación de diagrama de los elementos internos de la aplicación puede ofrecer una visión general de los requisitos de prueba; con la codificación por colores, también puede servir de base para la creación de informes.

Definición del ámbito scope-definition

Una aplicación suele tener una selección de casos de uso. Algunos serán muy importantes, otros menos.

Para centrar el ámbito de las pruebas de rendimiento en la publicación, se recomienda definir lo siguiente:

El número de casos de uso depende de usted, pero debe limitarse a un número fácilmente manejable (por ejemplo, entre 5 y 10).

Una vez seleccionados los casos de uso clave, los indicadores de rendimiento clave (KPI) y las herramientas utilizadas para medirlos se pueden definir para cada caso. Algunos ejemplos de KPI comunes son:

Metodologías de prueba test-methodologies

Este concepto tiene 4 escenarios utilizados para definir y probar los objetivos de rendimiento:

Se basa en los principios siguientes:

Puntos de interrupción de los componentes component-breakpoints

Transacciones transactions

Definición de los objetivos de rendimiento defining-the-performance-goals

Una vez definido el ámbito y los KPI relacionados, se pueden establecer los objetivos de rendimiento específicos. Esto implica diseñar escenarios de prueba, junto con valores de destino.

Tendrá que probar el rendimiento tanto en condiciones de media como de pico. Además, necesitará probar el escenario de Activación para asegurarse de que puede aumentar el interés en su sitio web cuando esté disponible por primera vez.

Cualquier experiencia o estadística que haya recopilado de un sitio web existente también puede ser útil para determinar objetivos futuros; por ejemplo, el tráfico principal del sitio web activo.

Pruebas de un solo componente single-component-tests

Los componentes críticos deberán probarse en condiciones medias y máximas.

En ambos casos, se puede definir el número esperado de transacciones por segundo cuando un número predefinido de usuarios utiliza el sistema.

Pruebas de componentes combinadas combined-component-tests

La prueba de los componentes en combinación ofrece un reflejo más profundo del comportamiento de las aplicaciones. Una vez más, deben probarse las condiciones medias y máximas.

Pruebas en directo going-live-tests

Durante los primeros días después de que su sitio web esté disponible, puede esperar un mayor nivel de interés. Probablemente esto será incluso bueno respecto a los valores pico que ha estado probando. Se recomienda probar los escenarios en directo para asegurarse de que el sistema pueda solucionar esta situación.

Pruebas del escenario de error error-scenario-tests

Los escenarios de error también deben probarse para garantizar que el sistema reaccione correcta y adecuadamente. No solo en la forma en que se gestiona el error en sí, sino también en el impacto que puede tener en el rendimiento. Por ejemplo:

Al diseñar estas pruebas, debe recordarse que no todos los escenarios se producirán con regularidad. Sin embargo, su impacto en todo el sistema es importante.

Pruebas de resistencia endurance-tests

Algunos problemas solo se encontrarán una vez que el sistema se haya ejecutado durante un período de tiempo continuo; sea en horas o incluso días. Se utiliza una prueba de resistencia para probar una carga promedio constante durante un período de tiempo requerido. A continuación, se puede analizar cualquier degradación del rendimiento.

Optimización optimization

En las etapas posteriores de la implementación, deberá optimizar la aplicación para cumplir/maximizar los objetivos de rendimiento.

Las optimizaciones realizadas deberán probarse para garantizar que:

Hay una selección de herramientas disponibles para ayudarle con la generación de carga, la monitorización del rendimiento y/o el análisis de resultados:

Después de la optimización, tendrá que volver a realizar pruebas para confirmar el impacto.

Informes reporting

Se necesitarán informes en curso para mantener informados a todos sobre el estado. Como se mencionó anteriormente con la codificación por colores, el mapa de arquitectura se puede usar para esto.

Una vez completadas todas las pruebas, debe informar sobre:

Optimización del rendimiento al utilizar Dispatcher optimizing-performance-when-using-the-dispatcher

La variable Dispatcher es la herramienta de almacenamiento en caché o equilibrio de carga de Adobe. Al utilizar Dispatcher, debe considerar la posibilidad de optimizar el rendimiento de la caché del sitio web.

Dispatcher ofrece una serie de mecanismos integrados que puede utilizar para optimizar el rendimiento si el sitio web los aprovecha. Esta sección le explica cómo diseñar su sitio web para maximizar los beneficios del almacenamiento en caché.

Cálculo de la proporción de caché de Dispatcher calculating-the-dispatcher-cache-ratio

La fórmula de proporción de caché calcula el porcentaje de solicitudes gestionadas por la caché a partir del número total de solicitudes que llegan al sistema. Para calcular la proporción de caché necesita lo siguiente:

La fórmula para calcular la proporción de caché es:

Por ejemplo, si el número total de solicitudes es 129491 y el número de solicitudes atendidas por la instancia de publicación es 58959, la proporción de caché es: (129491 - 58959)/129491= 54,5%.

Si no tiene un emparejamiento de uno a uno de los publicadores/dispatcher, deberá agregar solicitudes de todos los distribuidores y editores juntos para obtener una medición precisa. Consulte también Implementaciones recomendadas.

Utilizar una codificación de página coherente using-consistent-page-encoding

Con la versión 4.1.11 de Dispatcher puede almacenar en caché los encabezados de respuesta. Si no está almacenando encabezados de respuesta en caché en Dispatcher, se pueden producir problemas si almacena información de codificación de página en el encabezado. En este caso, cuando Dispatcher sirve una página desde la caché, se utiliza la codificación predeterminada del servidor web para esa página. Existen dos formas de evitar este problema:

        <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

Evitar parámetros de URL avoid-url-parameters

Si es posible, evite los parámetros de URL para las páginas que desee almacenar en caché. Por ejemplo, si tiene una galería de imágenes, la siguiente URL nunca se almacenará en caché (a menos que Dispatcher esté configurado así):

www.myCompany.com/pictures/gallery.html?event=christmas&page=1

Sin embargo, puede colocar estos parámetros en la dirección URL de la página de la siguiente manera:

www.myCompany.com/pictures/gallery.christmas.1.html

Personalizar por dirección URL customize-by-url

Si permite a los usuarios cambiar el tamaño de la fuente (o cualquier otra personalización del diseño), asegúrese de que las diferentes personalizaciones se reflejen en la dirección URL.

Por ejemplo, las cookies no se almacenan en caché, por lo que si almacena el tamaño de la fuente en una cookie (o mecanismo similar), no se conservará para la página en caché. Como resultado, Dispatcher devuelve aleatoriamente documentos con cualquier tamaño de la fuente.

Incluir el tamaño de la fuente en la URL como selector evita este problema:

www.myCompany.com/news/main.large.html

Invalidar archivos de imagen utilizados como títulos invalidating-image-files-used-as-titles

Si procesa títulos de páginas u otros textos como imágenes, se recomienda almacenar los archivos para que se eliminen tras actualizar el contenido de la página:

Por ejemplo, puede almacenar el título de la página myPage.html en el archivo myPage.title.gif. Este archivo se eliminará automáticamente si se actualiza la página, por lo que cualquier cambio en el título de la página se reflejará automáticamente en la caché.

Invalidar archivos de imagen utilizados para la navegación invalidating-image-files-used-for-navigation

Si utiliza imágenes para las entradas de navegación, el método es básicamente el mismo que con los títulos, un poco más complejo. Almacene todas las imágenes de navegación con las páginas de destino. Si utiliza dos imágenes para la normal y la activa, puede utilizar los siguientes scripts:

Es importante crear estas imágenes con el mismo nombre que la página, para garantizar que una actualización de contenido elimine estas imágenes, así como la página.

En las páginas que no se modifiquen, las imágenes permanecerán en la caché, aunque las páginas en sí suelen invalidarse automáticamente.

Personalización personalization

Se recomienda limitar la personalización a donde sea necesario. Para explicar por qué:

Si personaliza cada página (por ejemplo, colocando el nombre del usuario en la barra de título), puede tener un impacto en el rendimiento.

Con respecto a la mezcla de contenido restringido y público en una página, es posible que desee considerar una estrategia que aproveche las inclusiones del lado del servidor en Dispatcher, o las inclusiones del lado del cliente a través de Ajax en el explorador.

Conexiones fijas sticky-connections

Las conexiones fijas garantizan que todos los documentos de un usuario se compongan en el mismo servidor. Si un usuario abandona esta carpeta y más tarde vuelve a ella, la conexión se mantiene. Defina una carpeta para guardar todos los documentos que requieran conexiones fijas para el sitio web. Intente no meter otros documentos en ella. Esto afecta al equilibrio de cargas si utiliza páginas personalizadas y datos de sesión.

Tipos MIME mime-types

Existen dos maneras en las que un explorador puede determinar el tipo de archivo:

Para la mayoría de los archivos, el tipo MIME está implícito en la extensión del archivo. es decir:

Si el nombre del archivo no tiene extensión, se mostrará como texto sin formato.

Con la versión 4.1.11 de Dispatcher puede almacenar en caché los encabezados de respuesta. Si no almacena en caché los encabezados de respuesta en Dispatcher, tenga en cuenta que el tipo MIME forma parte del encabezado HTTP. Por lo tanto, si la aplicación AEM devuelve archivos que no tienen un final de archivo reconocido y dependen del tipo MIME en su lugar, estos archivos pueden mostrarse incorrectamente.

Para asegurarse de que los archivos se almacenan en caché correctamente, siga estas directrices:

Rendimiento de copia de seguridad backup-performance

Esta sección presenta una serie de puntos de referencia utilizados para evaluar el performance de los backups AEM y los efectos de la actividad de backup en el performance de las aplicaciones. Una copia de seguridad AEM presenta una carga significativa en el sistema mientras se ejecuta, y lo medimos, así como los efectos de la configuración de demora de la copia de seguridad que intenta modular estos efectos. El objetivo es ofrecer algunos datos de referencia sobre el rendimiento esperado de los backups en configuraciones realistas y cantidades de datos de producción, y proporcionar orientación sobre cómo estimar los tiempos de backup para sistemas planificados.

Entorno de referencia reference-environment

Sistema físico physical-system

Los resultados recogidos en este documento se obtuvieron a partir de puntos de referencia ejecutados en un entorno de referencia con la siguiente configuración. Esta configuración está diseñada para ser similar a un entorno de producción típico en un centro de datos:

El subsistema de disco de este servidor es bastante rápido, representativo de una configuración RAID de alto rendimiento que podría usarse en un servidor de producción. El performance del backup puede ser sensible al performance del disco, y los resultados en este entorno reflejan el performance en una configuración RAID muy rápida. La imagen VMWare está configurada para tener un solo volumen de disco grande que reside físicamente en el almacenamiento de disco local, en el arreglo RAID.

La configuración AEM coloca el repositorio y el almacén de datos en el mismo volumen lógico, junto con todo el sistema operativo y el software AEM. El directorio de destino para copias de seguridad también reside en este sistema de archivos lógico.

Volúmenes de datos data-volumes

La siguiente tabla ilustra el tamaño de los volúmenes de datos que se utilizan en los puntos de referencia de backup. El contenido de la línea de base inicial se instala por primera vez y, a continuación, se añaden cantidades conocidas adicionales de datos para aumentar el tamaño del contenido del que se realiza una copia de seguridad. Las copias de seguridad se crearán en incrementos específicos para representar un gran aumento del contenido y lo que se puede producir en un día. La distribución de contenido (páginas, imágenes, etiquetas) se basará, aproximadamente, en una composición de recursos de producción realista. Las páginas, imágenes y etiquetas se limitarán a un máximo de 800 páginas secundarias. Cada página incluirá los componentes de título, Flash, texto/imagen, vídeo, presentación de diapositivas, formulario, tabla, nube y carrusel. Las imágenes se cargarán desde un grupo de 400 archivos únicos de un tamaño que oscila entre 37 kB y 594 kB.

La referencia de copia de seguridad se repite con los conjuntos de contenido adicionales agregados en cada repetición.

Escenarios de referencia benchmark-scenarios

Los puntos de referencia de copia de seguridad cubren dos escenarios principales: cuando el sistema está bajo carga de aplicación significativa, y realiza backups cuando el sistema está inactivo. Aunque la recomendación general es que las copias de seguridad deben realizarse cuando AEM esté lo más inactivo posible, hay situaciones en las que es necesario que la copia de seguridad se ejecute cuando el sistema está en carga.

Los tiempos de copia de seguridad y el tamaño de la copia de seguridad resultante se obtienen de los registros del servidor AEM. Normalmente, se recomienda que los backups se programen para tiempos de inactividad cuando el AEM esté inactivo, por ejemplo, a mitad de la noche. Este escenario es representativo del enfoque recomendado.

La carga consistirá en creaciones/eliminaciones de páginas, recorridos y consultas con la mayoría de la carga proveniente de recorridos y consultas de páginas. Agregar y quitar demasiadas páginas aumenta continuamente el tamaño del espacio de trabajo e impide que se completen las copias de seguridad. La distribución de la carga que utilizará la secuencia de comandos es un 75% de travesías de página, un 24% de consultas y un 1% de creaciones de páginas (un nivel sin subpáginas anidadas). El promedio de transacciones por segundo máximo en un sistema inactivo se logra con 4 subprocesos simultáneos, que es lo que se utilizará al probar copias de seguridad en carga.

El impacto de la carga en el performance del backup puede estimarse por la diferencia entre el performance con y sin esta carga de aplicación. El impacto del backup en el rendimiento de las aplicaciones se encuentra comparando el rendimiento del escenario en transacciones por hora con y sin un backup simultáneo en curso, y con backups que operan con diferentes configuraciones de "retraso de backup".

Resumen de los resultados summary-of-results

Tiempo y Rendimiento de Backup backup-time-and-throughput

El resultado principal de estos análisis de rendimiento es mostrar cómo varían los tiempos de backup en función del tipo de backup y la cantidad total de datos. El siguiente gráfico muestra el tiempo de copia de seguridad obtenido mediante la configuración de copia de seguridad predeterminada, en función del número total de páginas.

Los tiempos de backup en una instancia inactiva son bastante consistentes, con un promedio de 0,608 MB/s independientemente de los backups completos o incrementales (ver gráfico a continuación). El tiempo de backup es simplemente una función de la cantidad de datos de los que se está haciendo backup. El tiempo para completar una copia de seguridad completa aumenta claramente con la cantidad total de páginas. El tiempo para completar una copia de seguridad incremental también aumenta con el número total de páginas, pero a una tasa mucho más baja. El tiempo que se tarda en completar la copia de seguridad incremental es mucho menor debido a la cantidad relativamente pequeña de datos de los que se hace backup.

El tamaño de la copia de seguridad producida es el principal determinante del tiempo que se tarda en completar una copia de seguridad. El siguiente gráfico muestra el tiempo que se tarda como una función del tamaño final de la copia de seguridad.

Este gráfico ilustra que tanto los backups incrementales como los completos siguen un patrón de tamaño y tiempo simple que podemos medir como rendimiento. Los tiempos de backup en una instancia inactiva son bastante consistentes, con un promedio de 0,61 MB/s independientemente de los backups completos o incrementales en el entorno de referencia.

Retraso de copia de seguridad backup-delay

El parámetro de demora de copia de seguridad se proporciona para limitar la medida en que los backups pueden interferir con las cargas de trabajo de producción. El parámetro especifica un tiempo de espera en milisegundos, que se intercala en la operación de copia de seguridad archivo por archivo. El efecto general depende en parte del tamaño de los archivos afectados. La medición del performance de backup en MB/seg ofrece una manera razonable de comparar los efectos del retraso en el backup.

Para comparar el rendimiento obtenido usando una copia de seguridad del sistema de archivos (usando 'tar') para hacer backup de los mismos archivos del repositorio. El rendimiento del tar es comparable, pero ligeramente superior al de la copia de seguridad con retraso establecido en cero. La configuración de incluso un pequeño retraso reduce considerablemente el rendimiento del backup y el retraso predeterminado de 10 ms da como resultado un rendimiento mucho menor. En situaciones en las que las copias de seguridad se pueden programar cuando el uso general de las aplicaciones es muy bajo o la aplicación puede estar completamente inactiva, probablemente sea conveniente reducir el retraso por debajo del valor predeterminado para permitir que la copia de seguridad se realice más rápidamente.

El impacto real del rendimiento de las aplicaciones de un backup en curso depende de los detalles de la infraestructura y las aplicaciones. La elección del valor de retraso debe hacerse mediante un análisis empírico de la aplicación, pero debe elegirse lo más pequeño posible, de modo que las copias de seguridad puedan completarse lo más rápido posible. Dado que sólo hay una correlación débil entre la elección del valor de demora y el impacto en el rendimiento de las aplicaciones, la elección del retraso debería favorecer tiempos de backup generales más cortos, a fin de minimizar el impacto general de los backups. Una copia de seguridad que tarda 8 horas en completarse, pero que afecta al rendimiento en un -20%, probablemente tendrá un bueno impacto general que una que tarde 2 horas en completarse pero afecta al rendimiento en un -30%.

Referencias references