Compartir a través de

Información general sobre escenarios de prueba

En este tema se proporciona información general sobre la aplicación de prueba; una descripción de la metodología de pruebas usada y enumera los indicadores clave de rendimiento (KPI) capturados durante las pruebas de carga.

Prueba de la aplicación

Se usó una aplicación de solicitud-respuesta sincrónica para comparar el rendimiento de BizTalk Server que se ejecuta en Hyper-V a BizTalk Server que se ejecuta en hardware físico. Esta aplicación se usó para ilustrar el rendimiento de una solución de BizTalk Server que se ha optimizado para una latencia baja. La mensajería de baja latencia es fundamental para determinados escenarios, como la banca en línea, donde un cliente envía una solicitud y espera un mensaje de respuesta en un intervalo muy corto (por ejemplo < , 3 segundos).

En la ilustración siguiente se muestra la arquitectura de alto nivel utilizada. Visual Studio Team System (VSTS) 2008 Test Load Agent invocó una clase de prueba personalizada, que usaba el transporte WCF para generar la carga en BizTalk Server. La aplicación de BizTalk Server en este escenario se expuso mediante una ubicación receptora de solicitud-respuesta de tipo WCF-BasicHttp. VsTS 2008 Test Load Agent se usó como cliente de prueba debido a la gran flexibilidad que proporciona, incluida la capacidad de configurar el número de mensajes enviados en total, el número de subprocesos simultáneos y el intervalo de suspensión entre las solicitudes enviadas.

Varios equipos del Agente de carga de pruebas de VSTS 2008 se pueden ejecutar conjuntamente para simular patrones de carga reales. Para estas pruebas, los equipos del Agente de carga de pruebas de VSTS 2008 estaban controlados por un único equipo controlador de agente de carga de pruebas de VSTS 2008 que también ejecutaba BizUnit 3.0. Como resultado, se envió una carga coherente a los equipos físicos y virtuales de BizTalk Server. Para obtener más información sobre el uso de VSTS 2008 Test Edition para generar la carga simulada para las pruebas, vea https://go.microsoft.com/fwlink/?LinkID=132311.

Prueba de arquitectura de Probar la arquitectura de la aplicación

  1. Un WCF-BasicHttp o WCF-Custom Request-Response ubicación de recepción recibe una nueva CalculatorRequest desde un equipo del Agente de carga de pruebas.

  2. El componente de desensamblador XML promueve el elemento Method dentro del documento xml CalculatorRequest. El Agente de Mensajes envía el mensaje entrante a la base de datos Caja de Mensajes (BizTalkMsgBoxDb).

  3. La solicitud entrante inicia una nueva instancia de LogicalPortsOrchestration. Esta orquestación usa un puerto enlazado directo para recibir los mensajes CalculatorRequest con la propiedad promocionada Method = "LogicalPortsOrchestration".

  4. LogicalPortsOrchestration usa un bucle para recuperar operaciones y para cada elemento lo invoca en el servicio web WCF Calculadora en sentido descendente mediante un puerto lógico Solicit-Response. El mensaje de solicitud para el servicio web WCF calculator se crea mediante un componente auxiliar y se publica en el Cuadro de mensajes.

  5. Un puerto de envío de WCF-BasicHttp consume el mensaje de solicitud.

  6. El puerto de envío WCF-BasicHttp invoca uno de los métodos (Agregar, Restar, Multiplicar, Dividir) del servicio web WCF de la calculadora.

  7. El servicio web WCF Calculator devuelve un mensaje de respuesta.

  8. El mensaje de respuesta se publica en el Cuadro de mensajes.

  9. El mensaje de respuesta se devuelve al autor de la llamada LogicalPortsOrchestration. La orquestación repite este patrón para cada operación dentro del documento XML de entrada CalculatorRequest.

  10. LogicalPortsOrchestration publica el mensaje CalculatorResponse en el cuadro de mensajes.

  11. El mensaje de respuesta es recuperado por la ubicación de recepción Request-Response WCF-BasicHttp.

  12. El mensaje de respuesta se devuelve al ordenador del Agente de Pruebas de Carga.

    A continuación se muestra una captura de pantalla de la orquestación usada durante la prueba de carga:

Nota:

Para fines de ilustración, la orquestación que se muestra a continuación es una versión simplificada de la orquestación que se usó realmente durante las pruebas de carga. La orquestación usada durante las pruebas de carga incluía varios ámbitos, lógica de control de errores y tipos de puerto adicionales.

Prueba de orquestación de aplicaciones Prueba de orquestación de aplicaciones

Metodología de pruebas

Las pruebas de rendimiento implican muchas tareas, que si se realizan manualmente son repetitivas, monotonosas y propensas a errores. Para mejorar la eficacia de las pruebas y proporcionar coherencia entre las ejecuciones de pruebas, visual Studio 2013 Team System (VSTS) Test Edition con BizUnit 3.0 se usó para automatizar las tareas necesarias durante el proceso de prueba. Los equipos del Agente de carga de pruebas de VSTS 2008 se usaron como cliente de prueba para generar la carga de mensajes en el sistema y los mismos tipos de mensaje se usaron en cada ejecución de prueba para mejorar la coherencia. Después de este proceso se proporciona un conjunto coherente de datos para cada ejecución de prueba. Para obtener más información sobre BizUnit 3.0, vea https://go.microsoft.com/fwlink/?LinkID=85168. Para obtener más información sobre Visual Studio 2013 Team System Test Edition, vea https://go.microsoft.com/fwlink/?LinkID=141387.

Los pasos siguientes se automatizaron:

  • Detenga los hosts de BizTalk.

  • Limpie los directorios de prueba.

  • Reinicie IIS.

  • Limpie la base de datos del cuadro de mensajes de BizTalk Server.

  • Reinicie SQL Server.

  • Borre los registros de eventos.

  • Cree una carpeta de resultados de prueba para cada ejecución para almacenar los archivos de registro y las métricas de rendimiento asociados.

  • Inicie Hosts de BizTalk.

  • Contadores del Monitor de Rendimiento de Carga.

  • Preparar el entorno de BizTalk con una pequeña carga de trabajo.

  • Enviar mediante un proceso representativo.

  • Escriba registros de rendimiento en una carpeta de resultados.

  • Recopile registros de aplicación y escriba en un archivo .csv en la carpeta de resultados.

  • Ejecute las herramientas de Análisis de rendimiento de registros (PAL), Relog y Log Parser en los registros de rendimiento recopilados para generar estadísticas, gráficos e informes. Para obtener más información sobre PAL, Relog y Log Parser, vea Apéndice D: Herramientas para medir el rendimiento.

Nota:

Todo el seguimiento se deshabilitó y el trabajo del Agente SQL Server de BizTalk Server se deshabilitó durante las pruebas.

Para asegurarse de que los resultados de este laboratorio pudieron proporcionar una comparación del rendimiento de BizTalk Server en un entorno físico y Hyper-V, las métricas de rendimiento y los registros se recopilaron en una ubicación centralizada para cada ejecución de prueba.

El cliente de prueba se usó para crear un directorio de resultados único para cada ejecución de prueba. Este directorio contenía todos los registros de rendimiento, los registros de eventos y los datos asociados necesarios para la prueba. Este enfoque proporcionó información necesaria cuando se requería el análisis retroactivo de las ejecuciones de pruebas anteriores. Al final de cada prueba, los datos sin procesar se compilaron en un conjunto de resultados coherentes y indicadores clave de rendimiento (KPI). La recopilación de conjuntos de resultados coherentes para máquinas físicas y virtualizadas proporcionó los puntos de comparación necesarios entre las distintas ejecuciones de pruebas y entornos diferentes. Los datos recopilados incluyen:

  • Medio ambiente– Para registrar en qué entorno se estaba ejecutando la prueba, BizTalk Server en hardware físico o BizTalk Server en Hyper-V.

  • Número de ejecución de prueba: Para identificar de forma única cada ejecución de prueba

  • Caso de prueba: Para registrar la arquitectura de la solución de BizTalk Server utilizada durante las pruebas. (Por ejemplo, Orquestación con puertos lógicos frente a Orquestación mediante envíos en línea)

  • Fecha– Para registrar la fecha y hora en que se ejecutó la prueba

  • Hora de inicio: Según lo notificado por el primer agente de prueba de carga de VSTS iniciado

  • Tiempo detenido: Según lo informado por el último agente de prueba de carga de VSTS que completó

  • Duración de la prueba en minutos: Para registrar la duración de la prueba.

  • Mensajes enviados en total: Para registrar el número total de mensajes enviados desde los equipos del Agente de carga a los equipos de BizTalk Server durante la prueba.

  • Mensajes enviados por segundo: Para registrar los mensajes enviados por segundo desde los equipos del Agente de carga a los equipos de BizTalk Server durante la prueba.

  • Latencia media de cliente: Para registrar la cantidad media de tiempo entre el momento en que los clientes del Agente de carga de pruebas iniciaron una solicitud y recibieron una respuesta de los equipos de BizTalk Server durante la prueba de carga.

  • Request-Response Duración media (ms) – Tal y como ha informado el contador de Monitor de rendimiento de BizTalk:Messaging Latency\Request-Response Latencia (seg) para BizTalkServerIsolatedHost

    Nota:

    Se utilizó un promedio de estos indicadores, según lo calculado a partir de los registros, donde varios hosts de BizTalk virtualizados estaban ejecutándose.

  • Orquestaciones completadas por segundo: Según lo informado por el contador Orchestrations XLANG/s(BizTalkServerApplication)\Orchestrations completed/sec Performance Monitor. Este contador proporciona una buena medida del rendimiento de la solución de BizTalk Server.

  • % de mensajes procesados < 3 segundos: para registrar el número total de mensajes procesados en un plazo de 3 segundos durante la prueba.

    La prueba de carga de VSTS 2008 se usó para generar una carga coherente en todas las pruebas. La siguiente configuración de ejecución de pruebas y el patrón de carga se modificaron durante las pruebas para ajustar el perfil de carga de cada prueba:

  • Configuración de ejecución de pruebas

    La siguiente configuración de ejecución de pruebas se modificó en función de la prueba que se está realizando:

    • Duración de la ejecución: Especifica cuánto tiempo se ejecuta la prueba.

      Configuración de ejecución de pruebas Configuración de ejecución de pruebas

  • Configuración del patrón de prueba

    La siguiente configuración del patrón de prueba se modificó en función de la prueba que se realiza:

    1. Patrón – Especifica cómo se ajusta la carga del usuario simulado durante una prueba de carga. Los patrones de carga están basados en constante, pasos o objetivos. Todas las pruebas de carga realizadas fueron constantes o escalonadas.

      Nota:

      Todas las pruebas realizadas con fines de esta guía usaron un patrón de carga constante o un patrón de carga de pasos . Los patrones de carga constante y los patrones de carga paso proporcionan la siguiente funcionalidad:

      • Patrón de carga constante: El patrón de carga es el mismo durante la prueba, el número de usuarios simulados comienza en un nivel predefinido y no cambia.
        • Patrón de carga de pasos: El patrón de carga se incrementa durante la ejecución de la prueba; el número de usuarios simulados comienza en un nivel predefinido y se incrementa por una cantidad predefinida a intervalos predefinidos durante la prueba.

    2. Recuento de usuarios constantes (patrón de carga constante): Número de usuarios virtuales que generan carga en la dirección del punto de conexión especificado en el archivo app.config del proyecto de prueba de carga de Visual Studio. Este valor se especifica en la configuración del patrón de carga que se usa para la prueba de carga.

    3. Recuento inicial de usuarios (patrón de carga de pasos): Número de usuarios virtuales que generan carga en la dirección de punto de conexión especificada al principio de una prueba de patrón de carga de pasos. Este valor se especifica en la configuración del patrón de carga que se usa para la prueba de carga.

    4. Número máximo de usuarios (patrón de carga de pasos): Número de usuarios virtuales que generan carga en la dirección de punto de conexión especificada al final de una prueba de patrón de carga de pasos. Este valor se especifica en la configuración del patrón de carga que se usa para la prueba de carga.

    5. Duración del paso (patrón de carga de pasos): Número de segundos que los usuarios virtuales generan carga en la dirección de punto de conexión especificada para un paso específico de una prueba de carga.

    6. Recuento de usuarios por etapa (patrón de carga escalonada): Número de usuarios virtuales que se van a aumentar en cada paso cuando se usa un patrón de carga escalonada.

      Configuración del patrón de prueba Configuración del patrón de prueba

    Para obtener más información sobre cómo trabajar con pruebas de carga en Visual Studio 2013, vea el tema Trabajar con pruebas de carga en la documentación de Visual Studio 2013 Team System en https://go.microsoft.com/fwlink/?LinkId=141486.

Indicadores clave de rendimiento medidos durante las pruebas

Los siguientes contadores del Monitor de rendimiento se capturaron como indicadores clave de rendimiento (KPI) para todas las ejecuciones de pruebas:

Nota:

Para obtener más información sobre cómo evaluar el rendimiento con contadores de monitor de rendimiento, vea Lista de comprobación: Medición del rendimiento en Hyper-V.

BizTalk Server KPI

  • Documentos procesados por segundo – Según lo medido por el contador BizTalk:Messaging/Documents procesados/Seg.

  • Latencia – Medida según lo devuelto por el controlador de pruebas de carga de VSTS 2008.

    SQL Server KPI

  • Uso del procesador de SQL Server: Según lo medido por el contador SQL\Processor(Total)\%Processor Time. Este contador mide el uso de CPU del procesamiento de SQL Server en el equipo con SQL Server.

  • Rendimiento del procesamiento de comandos de Transact SQL: Medido por el contador \SQL Server:SQL Statistics\Batch Requests/sec . Este contador mide el número de lotes de comandos de Transact-SQL recibidos por segundo. Este contador se usa para medir el rendimiento en el equipo con SQL Server.

    KPI de red

  • Rendimiento de red de BizTalk Server: Medido por el contador del monitor de rendimiento \Network Interface(*)\Bytes Total/s en los equipos de BizTalk Server.

  • Rendimiento de red de SQL Server: Según lo mide la Interfaz de Red de SQL\Bytes Total/seg (Promedio) que devuelve el Controlador de Pruebas de Carga VSTS 2008.

    KPI de memoria

  • Memoria disponible: Medida por el contador \Memory\Available Mbytes para los distintos escenarios.

Detalles de la infraestructura física

Para cada uno de los servidores que se instalaron las siguientes opciones de configuración se ajustaron.

Para todos los servidores:

  • El archivo de paginación se configuró en 1,5 veces la cantidad de memoria física asignada. El archivo de paginación se estableció en un tamaño fijo asegurándose de que el tamaño inicial y los valores máximos eran idénticos en MB.

  • La opción "Ajustar para mejorar el rendimiento" se seleccionó en la pantalla Propiedades avanzadas del sistema.

  • Se comprobó que el sistema se había ajustado para obtener el mejor rendimiento de los servicios en segundo plano en la sección Opciones de rendimiento de propiedades del sistema.

  • Windows Server 2008 SP2 se instaló como sistema operativo invitado en cada una de las máquinas virtuales.

  • Windows Update se ejecutó correctamente en todos los servidores para instalar las actualizaciones de seguridad más recientes.

    Para SQL Server:

  • SQL Server se instaló según la guía de instalación disponible en https://go.microsoft.com/fwlink/?LinkId=141021.

  • SQL Server usado tenía los LUN de SAN configurados según la tabla siguiente. Los archivos de la base de datos y los archivos de registro se separaron entre los LUNs de la siguiente manera para evitar la posible contención de E/S de disco.

    • El volumen Data_Sys se usó para almacenar todos los archivos de base de datos (incluidas las bases de datos del sistema y bizTalk), excepto las bases de datos MessageBox y TempDb.

    • El volumen de Log_Sys se usó para almacenar todos los archivos de registro (incluidas las bases de datos de Sistema y BizTalk Server), excepto las bases de datos MessageBox y TempDb.

    • El volumen Data_TempDb se usó para almacenar el archivo de base de datos TempDb.

    • El volumen Logs_TempDb se usó para almacenar el archivo de registro de TempDb.

    • El archivo de base de datos MessageBox se almacenó en el volumen de Data_BtsMsgBox y el archivo de registro se almacenó en el volumen de Log_BtsMsgBox.

  • Además, se proporcionó un LUN independiente para el archivo de registro del MSDTC. En sistemas de BizTalk de alto rendimiento, se ha mostrado que la actividad del archivo de registro MSDTC provoca un cuello de botella de E/S si se deja en la misma unidad física que el sistema operativo.

    Nombre del volumen Archivos TAMAÑO DEL LUN EN GB Tamaño de partición de host GB Tamaño de clúster
    Sistema_Datos Archivos de datos MASTER y MSDB 10 10 64 KB
    Logs_Sys Archivos de registro MASTER y MSDB 10 10 64 KB
    Data_TempDb Archivo de datos de TempDB 50 50 64 KB
    Logs_TempDb Archivo de registro de TempDB 50 50 64 KB
    Data_BtsMsgBox Archivo de datos de BizTalkMsgBoxDb 300 100 64 KB
    Logs_BtsMsgBox Archivo de registro de BizTalkMsgBoxDb 100 100 64 KB
    Data_BAMPrimaryImport Archivo de datos BAMPrimaryImport 10 10 64 KB
    Registros_BAMPrimaryImport Archivo de registro de BAMPrimaryImport 10 10 64 KB
    Data_BizTalkDatabases Otros archivos de datos de base de datos de BizTalk 20 20 64 KB
    Logs_BizTalkDatabases Otros archivos de registro de base de datos de BizTalk 20 20 64 KB
    No disponible Archivo de registro MSDTC 5 5 No disponible

  • BizTalk Server se instaló según las guías de instalación disponibles en https://go.microsoft.com/fwlink/?LinkId=128383.

  • La herramienta Analizador de procedimientos recomendados de BizTalk Server (BPA) se usó para realizar la validación de la plataforma una vez configurado el sistema. BizTalk Server(https://www.microsoft.com/download/details.aspx?id=43382).

Detalles de virtualización

Se usó un único VHD fijo de 50 GB para hospedar el sistema operativo para cada máquina virtual Hyper-V.

Se usaron discos duros virtuales fijos en lugar de discos duros virtuales de tamaño dinámico porque asignan inmediatamente el almacenamiento máximo para el disco duro virtual al archivo en la unidad donde se hospeda. Esto reduce la fragmentación del archivo VHD que se produce en la unidad física donde se hospeda, lo que mejora el rendimiento de E/S del disco.

Para configurar las máquinas virtuales, se realizó una instalación de la edición de 64 bits de Windows Server 2008 SP2 en un único disco duro virtual. Una vez instaladas todas las actualizaciones adecuadas, la máquina virtual base se imagenizó mediante la utilidad sysprep que se instala con Windows Server 2008 SP2, en el directorio %WINDIR%\system32\sysprep.

A continuación, este VHD base se copió y usó como base para todas las máquinas virtuales tipo Hyper-V que se implementaron en todo el entorno. Sysprep se ejecutó en la imagen de disco duro virtual base para restablecer los identificadores de seguridad del sistema antes de que se implementaran archivos binarios de SQL Server o BizTalk Server en el sistema.

Nota:

Ejecutar Sysprep después de instalar y configurar BizTalk Server en el servidor se puede realizar mediante el uso de un archivo de respuesta sysprep y scripts proporcionados con BizTalk Server. Estos scripts de ejemplo están diseñados para su uso con BizTalk Server instalado solo en versiones de 32 bits y de 64 bits de Windows Server 2008 SP2. Para obtener más información, consulte la documentación en línea de BizTalk Server.

La referencia de instalación desatendida de Windows está disponible en https://go.microsoft.com/fwlink/?LinkId=142364.

Véase también

Apéndice C: Compatibilidad con BizTalk Server y SQL Server Hyper-V