¿Qué es el rendimiento sostenible?

2025-06-05

Al planear y calcular la sostenibilidad del sistema, es fundamental pensar en términos de sostenibilidad a largo plazo. Las consideraciones principales 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. La certificación de pruebas y preparación se basará en poder controlar estas cargas a largo plazo.
Otras actividades y procesos que compiten por los recursos del servidor: no solo se trata de la carga del mensaje. Hay otros procesos y actividades que tienen lugar en los servidores que afectan al rendimiento, como el mantenimiento de la base de datos y las consultas de cuadro de mensajes.
Interrupciones y tiempos de inactividad planeados y no planeados del sistema: los eventos de Floodgate y el trabajo pendiente de mensajes pueden cambiar el perfil de carga efectivo.

Al pensar en la creación de sistemas sostenibles y las pruebas para certificarlos, asegúrese de tener en cuenta estos factores y planearlos.

¿Su rendimiento es sostenible?

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

La carga más alta del tráfico de mensajes que un sistema puede controlar indefinidamente en un entorno de producción.

Aunque esto parece sencillo, hay muchos factores que debe tener en cuenta al evaluar si una solución, que se ejecuta en un conjunto determinado de hardware, podrá soportar las cargas experimentadas diariamente después de poner la solución en producción.

Antes de poner la solución en producción, tenga en cuenta los siguientes factores para evaluar si la solución puede controlar la carga más alta del tráfico de mensajes indefinidamente:
Objetivos de rendimiento deseados y perfiles de rendimiento/latencia.
Otros procesos que se ejecutan en el mismo hardware, como:
- Supervisión y solución de problemas normales
- Mantenimiento de la base de datos operativa, como el trasvase de registros, la copia de seguridad, la purga, el mantenimiento de índices y las actualizaciones de estadísticas.
- Otras aplicaciones
Interrupciones planeadas y no planeadas del sistema, como:
- Sitios de asociados inactivos que bloquean el envío o recepción de mensajes
- Tiempo de inactividad programado del mantenimiento del sistema

Conocer sus objetivos de rendimiento

Para poder evaluar la solución para la sostenibilidad, debe tener un conocimiento detallado de las cargas de producción esperadas. Sin un objetivo bien entendido, no se puede evaluar la preparación. Un conjunto bien formado de objetivos de rendimiento es fundamental, ya que impulsará sus estrategias en torno a las pruebas del sistema y la certificación. Los objetivos de rendimiento deben tener los siguientes elementos:

Curva que define el rendimiento como una función de tiempo. Estas funciones pueden oscilar entre extremadamente sencilla y muy compleja.
Requisito de rendimiento asociado a la función de rendimiento.
Distribución de tamaños y tipos de archivo.

Ejemplo 1

Cada día, los mensajes se acumulan de 0 msgs/s a las 8:00 a.m. a 80 msgs/s al mediodía y, a continuación, vuelven a 0 msgs/s a las 9:00 p. m., aproximadamente en forma de curva 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 ventas oscilan entre 2 y 10 kilobytes y componen 75% de los recuentos de mensajes en un momento dado. Los documentos de pedido de reserva y solicitud de stock siempre están cerca de 1 kilobyte en tamaño y componen el resto, 10% y 15% del recuento de mensajes en cualquier momento dado, respectivamente.

Ejemplo 2

Cada noche a medianoche, llega un lote de 500 000 mensajes para su procesamiento.
Todos los mensajes del lote deben procesarse completamente en 8 horas.
Todos los mensajes son del 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 son de 10 megabytes cada uno y deben subdividirse en entradas de catálogo individuales para su procesamiento.

Ejemplo 3

Cada mañana a las 8:00 a.m., 4000 representantes de servicio al cliente inician sesión en el sistema interactivo y realizan, en promedio, 4 consultas por representante por minuto hasta la hora de cierre a las 5:00 p.m., 7 días por semana.
Todas las consultas deben devolver resultados en menos de 2 segundos.
Todas las consultas son del mismo tipo y se distribuyen uniformemente entre 500 y 1000 bytes de tamaño, ambos incluidos.

Requisito de rendimiento asociado a la función de rendimiento

Siguiendo 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.

Distribución de tamaños y tipos de archivo

Ejemplo 1 (continuación): hay tres tipos de documentos: Cesta de ventas, Pedido pendiente y Solicitud de stock. Los documentos de cesta de ventas oscilan entre 2 y 10 kilobytes y componen 75% de los recuentos de mensajes en un momento dado. Los documentos de pedido de reserva y solicitud de stock siempre están cerca de 1 kilobyte en tamaño y componen el resto, 10% y 15% del recuento de mensajes en cualquier momento dado, respectivamente.
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 son de 10 megabytes cada uno y deben subdividirse en entradas de catálogo individuales para su procesamiento.
Ejemplo 3 (continuación): todas las consultas son del mismo tipo y se distribuyen uniformemente entre 500 y 1000 bytes de tamaño, ambos incluidos.

Contabilidad de otros procesos

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

Cada base de datos, grande o pequeña, requiere mantenimiento operativo periódico, como el trasvase de registros, la copia de seguridad, el archivo y la purga. La supervisión y la solución de problemas son otros ejemplos de operaciones que debe tener en cuenta al definir y certificar lo que es sostenible. Por ejemplo, consultar el Cuadro de mensajes (por ejemplo, a través de la página Centro de grupo de la consola de administración) para ver cuántos mensajes de un tipo determinado se han suspendido en las últimas 24 horas requiere recursos de SQL Server que, de lo contrario, se podrían usar para procesar mensajes.

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

Envío 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 de grupo de BizTalk Server. Para obtener más información, vea Copia de seguridad y restauración de bases de datos de BizTalk Server. Consulte también Transferencia de registros.
Archivar y purgar datos de seguimiento. Además del plan general de trasvase de registros y copia 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, ya que el archivado y la purga de la base de datos de seguimiento de BizTalk suele ser un cuello de botella cuando el seguimiento está en uso.
Consultas del sistema. El uso de 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 son parte de la funcionalidad principal de BizTalk Server y que mantienen la base de datos MessageBox al eliminar los mensajes e instancias que ya han terminado de procesarse. Como parte del motor principal, la velocidad a la que se pueden completar estos trabajos es un factor clave en la medición de la sostenibilidad. Para obtener más información sobre estos trabajos y su rol, vea Mantener BizTalk Server1.
Actividades de implementación de soluciones. Al implementar, enlazar e iniciar nuevas aplicaciones o nuevas versiones de aplicaciones existentes, se coloca una carga adicional en BizTalk, como la creación de nuevas suscripciones en las bases de datos de Cuadro de mensajes. Una vez implementadas las aplicaciones, los mensajes que se procesan competirán por los recursos y, por tanto, afectarán al rendimiento de las aplicaciones existentes.

Para cada una de estas áreas, debe preguntar: ¿Cuál es la recomendación para minimizar el impacto de estas actividades? Por ejemplo, ¿deberían planear ejecutarlos a las 3:00 de la mañana?

Considerar interrupciones planeadas y no planeadas

Los efectos que tienen las interrupciones en el rendimiento del sistema variarán en función del sistema que experimente la interrupción, pero las consecuencias más comunes son:

Eventos de Floodgate. Cuando los sistemas están inactivos durante un período de tiempo, los mensajes pueden acumularse y, a continuación, llegar a la vez para su procesamiento una vez que los sistemas vuelvan 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 se recojan. Cuando la aplicación se vuelve a iniciar, es como si un gran número de mensajes llegara "todo a la vez".
Acumulación de mensajes Cuando los sistemas a los que se envían los mensajes están inactivos, normalmente hay un ciclo de reintento que se emplea que usa recursos adicionales. Una vez agotado el ciclo de reintento, los mensajes normalmente se suspenden. A continuación, los sistemas inactivos vuelven a estar en línea, y se produce una oleada de mensajes, donde grandes cantidades de mensajes pueden reanudarse o enviarse correctamente.

Sin duda, las interrupciones planeadas, como el mantenimiento programado periódicamente, deben tenerse en cuenta al diseñar y certificar un sistema. También se recomienda que se considere un análisis de interrupciones no planeadas y sus efectos.

La identificación de los tipos de interrupciones que pueden producirse, clasificarlas por nivel de riesgo estimado (es decir, probabilidad por gravedad) y estimar la duración y el efecto (por ejemplo, eventos de apertura de compuertas, volumen de mensajes suspendidos, trabajo pendiente, etc.) de las interrupciones de mayor riesgo indicará la capacidad deseada del sistema si se producen estas interrupciones. Cualquier sistema asincrónico basado en la mensajería y de almacenamiento y reenvío, como BizTalk Server, debe diseñarse con el margen de procesamiento suficiente para hacer frente a interrupciones planeadas y no planeadas.

Véase también

Persistencia y durabilidad del motor
Recomendaciones de planeación de proyectos por fase
Medición del rendimiento máximo sostenible del motor
Medición del rendimiento máximo de seguimiento sostenible
Escalado de las soluciones
Identificación de cuellos de botella de rendimiento
Rendimiento y capacidad del motor