Compartir a través de

¿Qué es rendimiento sostenible?

  • Artículo

Cuando se planea la sostenibilidad estimada de un sistema, es fundamental pensar en términos de sostenibilidad a largo plazo. Las principales consideraciones son:

  • Perfiles de carga y objetivos de rendimiento: no puede tener demasiados detalles en lo que respecta a los perfiles de carga y los objetivos de rendimiento. Las pruebas y la certificación de aptitud estarán basadas en la capacidad para controlar estas cargas a largo plazo.

  • Otras actividades y procesos que compiten por los recursos del servidor: no se trata solo de la carga del mensaje. Hay otros procesos y actividades que tienen lugar en los servidores que afectan al rendimiento, como el mantenimiento de las bases de datos y las consultas del cuadro de mensajes.

  • Interrupciones y tiempos de inactividad del sistema planeados y no planeados: los eventos de Floodgate y el trabajo pendiente de mensajes pueden cambiar el perfil de carga efectivo.

    A la hora de pensar en la creación de sistemas sostenibles y las pruebas para certificarlos, asegúrese de tener en cuenta estos factores y planear de acuerdo con ellos.

¿Es sostenible el rendimiento?

Al analizar el rendimiento de BizTalk Server, definimos el rendimiento máximo sostenible de la siguiente manera:

  • La mayor carga de tráfico de mensajes que puede administrar un sistema indefinidamente en un entorno de producción.

    Si bien esto parece sencillo, hay muchos factores que debe considerar a la hora de evaluar si una solución, ejecutándose en un conjunto de hardware concreto, podrá admitir o no la carga del día a día al pasarla a un entorno de producción.

    Antes de pasar la solución a producción, considere los siguientes factores para evaluar si la solución puede administrar la carga más alta de tráfico de mensajes indefinidamente:

  • Objetivos de rendimiento deseado y perfiles de producción y latencia.

  • Otros procesos que se ejecutan en el mismo hardware, como:

    • Solución de problemas y supervisión habituales

    • Mantenimiento de las bases de datos, como trasvases, copias de seguridad, purga, mantenimiento de índices y actualizaciones de estadísticas.

    • Otras aplicaciones

  • Interrupciones del suministro eléctrico planeadas y no planeadas, como:

    • Inactividad de sitios de asociados que bloquea el envío o la recepción de mensajes

    • Tiempo de inactividad debido al mantenimiento habitual del sistema

Conozca sus objetivos de rendimiento

Para poder evaluar si la solución es sostenible, debe tener muy claros los objetivos de producción esperados. Sin un objetivo claro, no puede evaluar la aptitud. Una serie de objetivos de rendimiento bien planteados es fundamental, puesto que orientará sus estrategias a la hora de realizar las pruebas y la certificación. Los objetivos de rendimiento deben tener los siguientes elementos:

  • Una curva que defina el rendimiento como una función de tiempo. Estas funciones pueden ser desde extremadamente sencillas hasta muy complejas.

  • Un requisito de rendimiento asociado con la función de rendimiento.

  • Una distribución de tamaños y tipos de archivo.

Ejemplo 1

  • cada día, los mensajes aumentan desde 0 mensajes por segundo a las 8:00 a.m. hasta 80 mensajes por segundo a las 12:00 a.m., y después vuelven a disminuir a 0 mensajes por segundo a las 9:00 p.m., aproximadamente una curva con forma de campana.

  • El sistema no tiene ningún requisito de latencia específico para cada mensaje, pero debe poder procesar esta carga, además de toda la carga del mensaje del día anterior (por ejemplo, en caso de una interrupción del sistema de 24 horas) sin estar detrás.

  • Hay tres tipos de documentos: Cesta de ventas, Pedido pendiente y Solicitud de stock. Los documentos de cesta de la compra varían en tamaño desde 2 hasta 10 KB y constituyen un 75% de los mensajes en cualquier momento. Los documentos de pedido en espera y petición de existencias suelen tener un tamaño aproximado de 1 KB y constituyen los restantes 10% y 15% respectivamente de los mensajes en cualquier momento.

Ejemplo 2

  • cada noche a las 12:00 p.m. llega un lote de 500.000 mensajes para procesarlos.

  • todos los mensajes del lote se deben procesar en 8 horas.

  • todos los mensajes son del mismo tipo y se distribuyen de forma equitativa entre 10 y 50 KB, inclusive. Además, el lote siempre contiene 10 mensajes de tipo de catálogo que tienen 10 MB cada uno y se deben subdividir en entradas de catálogo individuales para procesarlos.

Ejemplo 3

  • Cada mañana a las 8:00 a.m. 4.000 representantes de atención al cliente inician sesión en el sistema interactivo y realizan una media de 4 consultas por representante y por minuto hasta que se cierra a las 5:00 p.m., los siete días de la semana.

  • todas las consultas deben devolver resultados en menos de 2 segundos.

  • todas las consultas son del mismo tipo y su tamaño se distribuye equitativamente entre 500 y 1.000 bytes, inclusive.

Un requisito de rendimiento asociado con la función de rendimiento

Continuando con los ejemplos anteriores:

  • Ejemplo 1 (continuación): el sistema no tiene ningún requisito de latencia específico para cada mensaje, pero debe poder procesar esta carga, además de toda la carga del mensaje del día anterior (por ejemplo, en caso de una interrupción del sistema de 24 horas) sin estar detrás.

  • Ejemplo 2 (continuación): todos los mensajes del lote deben procesarse para completarse en 8 horas.

  • Ejemplo 3 (continuación): todas las consultas deben devolver resultados en menos de 2 segundos.

Una distribución de tamaños y tipos de archivo

  • Ejemplo 1 (continuación): hay tres tipos de documento: Cesta de ventas, Pedido pendiente y Solicitud de stock. Los documentos de cesta de la compra varían en tamaño desde 2 hasta 10 KB y constituyen un 75% de los mensajes en cualquier momento. Los documentos de pedido en espera y petición de existencias suelen tener un tamaño aproximado de 1 KB y constituyen los restantes 10% y 15% respectivamente de los mensajes en cualquier momento.

  • Ejemplo 2 (continuación): todos los mensajes tienen el mismo tipo y se distribuyen uniformemente entre 10 y 50 kilobytes, ambos incluidos. Además, el lote siempre contiene 10 mensajes de tipo de catálogo que tienen 10 MB cada uno y se deben subdividir en entradas de catálogo individuales para procesarlos.

  • Ejemplo 3 (continuación): todas las consultas tienen el mismo tipo y se distribuyen uniformemente entre 500 y 1000 bytes de tamaño, ambos incluidos.

Contabilizar otros procesos

Además de los perfiles de carga que pasan directamente a través del motor de BizTalk, hay siempre otros procesos que compiten por recursos del mismo hardware. Estos otros procesos reducen la capacidad global de rendimiento sostenible del sistema. El mantenimiento de las bases de datos es probablemente el ejemplo más común de este tipo de procesos.

Cada base de datos, grande o pequeña, requiere mantenimiento periódico, como trasvases, copias de seguridad, archivo y purga. La supervisión y la solución de problemas son otros ejemplos de operaciones que se deben tener en cuenta a la hora de definir y certificar lo que es sostenible. Por ejemplo, consultar el cuadro de mensajes (por ejemplo, desde la página Concentrador de grupo de la consola de administración) para ver cuántos mensajes de un tipo dado se han suspendido en las pasadas 24 horas requiere recursos de SQL Server que, de otro modo, se habrían podido usar para procesar mensajes.

A continuación se muestra una lista de actividades que normalmente tendrán el mayor efecto sobre la sostenibilidad general en BizTalk Server:

  • Trasvase de registros y copia de seguridad. Como parte de la mayoría de los planes de recuperación ante desastres que implican SQL Server, debe realizar el trasvase de registros y realizar copias de seguridad periódicamente para todas las bases de datos del grupo de BizTalk Server. Para obtener más información, consulte Copia de seguridad y restauración de bases de datos de BizTalk Server. Consulte también Trasvase de registros.

  • Archivar y purgar datos de seguimiento. Además del plan general de trasvase de registros y copias de seguridad, la base de datos de seguimiento de BizTalk (BizTalkDTADb) tiene sus propios regímenes de archivo y purga; para obtener más información, vea Archivar y purgar la base de datos de seguimiento de BizTalk. La velocidad a la que se pueden archivar y purgar los datos de la base de datos de seguimiento de BizTalk es especialmente importante, puesto que los procesos de archivo y purga de la base de datos de seguimiento de BizTalk suelen ser un cuello de botella cuando está activo el seguimiento.

  • Consultas del sistema. El uso de las API o la interfaz de usuario de la consola de administración de BizTalk Server para ejecutar varios tipos de consultas en el sistema afectarán al rendimiento sostenible.

  • Mantenimiento de cuadro de mensajes. Hay una serie de trabajos de SQL que forman parte de la funcionalidad principal de BizTalk Server que mantienen la base de datos de cuadro de mensajes mediante la limpieza de mensajes e instancias que han terminado de procesarse. Como parte del motor principal, la velocidad a la que se pueden realizar estos trabajos es un factor clave a la hora de evaluar la sostenibilidad. Para obtener más información sobre estos trabajos y su rol, vea Mantener BizTalk Server1.

  • Actividades de implementación de soluciones. Cuando se implementan, enlazan e inician nuevas aplicaciones o nuevas versiones de aplicaciones existentes, se produce una carga adicional en BizTalk, como la creación de nuevas suscripciones en las bases de datos de cuadro de mensajes. Tras implementar las aplicaciones, los mensajes que se procesan compiten por los recursos y, por tanto, afectan al rendimiento de las aplicaciones existentes.

    Para cada una de estas áreas, debe preguntar: ¿Cuál es su recomendación para minimizar el impacto de estas actividades? Por ejemplo, ¿se debería planear ejecutarlas a las 3:00 a.m.?

Considerar interrupciones del suministro eléctrico planeadas y no planeadas

Los efectos que tienen las interrupciones del suministro eléctrico en el rendimiento del sistema varían en función del sistema que experimenta la interrupción. No obstante, las consecuencias más comunes son:

  • Eventos de Floodgate. Cuando los sistemas están inactivos por un tiempo, los mensajes se pueden acumular y llegar todos de golpe para procesarlos una vez que el sistema vuelve a funcionar. Por ejemplo, si una aplicación que se ejecuta en BizTalk recibe mensajes a través de MSMQ y esa aplicación está inactiva durante algún tiempo, los mensajes se acumulan en las colas a la espera de que los recojan. Cuando se inicia de nuevo la aplicación, es como si un gran número de mensajes llegara "todos de golpe".

  • Trabajo pendiente de mensajes. Si los sistemas a los que se envían mensajes están inactivos, suele haber un ciclo de reintentos que utiliza recursos adicionales. Tras el ciclo de reintentos, los mensajes se suspenden. A continuación, los sistemas inactivos vuelven a estar en línea y tiene lugar un tipo de evento de control de tráfico (floodgate) donde grandes cantidades de mensajes se pueden reanudar o enviar correctamente.

    Por supuesto, las interrupciones de suministro eléctrico planeadas (por ejemplo, las debidas al mantenimiento programado) se deben tener en cuenta a la hora de diseñar y certificar un sistema. También se recomienda considerar un análisis de las interrupciones de suministro eléctrico no planeadas y sus efectos.

    Identificar los tipos de interrupciones de suministro eléctrico que se pueden producir, clasificándolos por el nivel de riesgo estimado (es decir, probabilidad por gravedad) y estimar la duración y el efecto (por ejemplo, eventos de control del tráfico (floodgate), volumen de mensajes suspendidos, registro, etc.) de las interrupciones de mayor riesgo indicarán la capacidad deseada de un sistema en el caso de que se produzcan interrupciones del suministro eléctrico. Cualquier sistema asincrónico basado en almacenamiento y reenvío, como BizTalk Server, debe diseñarse procesando el "espacio de espera" suficiente para hacer frente a interrupciones planeadas y no planeadas.

Consulte también

Persistencia y durabilidad del motor
Recomendaciones de planificación de proyectos por fases
Medir el rendimiento máximo sostenible del motor
Medir el rendimiento de seguimiento sostenible máximo
Escalar soluciones
Identificar cuellos de botella de rendimiento
Capacidad y rendimiento del motor