Información general del escenario 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 con BizTalk Server que se ejecutan 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 BizTalk Server en este escenario se expone a través de una ubicación de recepción de solicitud-respuesta 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 fueron controlados por un único equipo controlador de agente de carga de prueba de VSTS 2008 que también estaba ejecutando BizUnit 3.0. Como resultado, se envió una carga coherente a los equipos físicos y virtuales BizTalk Server. Para obtener más información sobre el uso de VSTS 2008 Test Edition para generar una carga simulada para pruebas, vea https://go.microsoft.com/fwlink/?LinkID=132311.
Probar la arquitectura de la aplicación
Un WCF-BasicHttp o WCF-Custom Request-Response ubicación de recepción recibe un nuevo Objeto CalculatorRequest desde un equipo del Agente de carga de pruebas.
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 messageBox (BizTalkMsgBoxDb).
La solicitud de entrada 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".
LogicalPortsOrchestration usa un bucle para recuperar las operaciones y para cada elemento que invoca el servicio web WCF calculadora de bajada mediante un puerto de Solicit-Response lógico. El mensaje de solicitud para el servicio web WCF calculator se crea mediante un componente auxiliar y se publica en el cuadro de mensajes.
Un puerto de envío de WCF-BasicHttp consume el mensaje de solicitud.
El WCF-BasicHttp Puerto de envío invoca uno de los métodos (Add, Subtract, Multiply, Divide) expuestos por el servicio web WCF calculator.
El servicio web WCF calculator devuelve un mensaje de respuesta.
El mensaje de respuesta se publica en el cuadro de mensajes.
El mensaje de respuesta se devuelve al llamador LogicalPortsOrchestration. La orquestación repite este patrón para cada operación dentro del documento xml CalculatorRequest de entrada.
LogicalPortsOrchestration publica el mensaje CalculatorResponse en el Cuadro de mensajes.
El Request-Response WCF-BasicHttp ubicación de recepción recupera el mensaje de respuesta.
El mensaje de respuesta se devuelve al equipo 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.
aplicaciones Probar orquestación de aplicaciones
Metodología de prueba
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 se usaron los mismos tipos de mensaje 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 BizTalk Server Cuadro de mensajes.
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.
Cargar contadores de Monitor de rendimiento.
Preparar el entorno de BizTalk con una carga pequeña.
Enviar a través de la ejecución representativa.
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 la herramienta Análisis de rendimiento de registros (PAL), Relog and Log Parser tools (Relog and 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 de BizTalk Server Agente SQL 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 de 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 un análisis retrospectiva de las ejecuciones de pruebas anteriores. Al final de cada prueba, los datos sin procesar se compilaron en un conjunto de resultados coherentes e 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 diferentes entornos. Los datos recopilados incluyen:
Ambiente– Para registrar en qué entorno se estaba ejecutando la prueba, ya sea 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 usada durante las pruebas. (Por ejemplo, Orquestación con puertos lógicos frente a orquestación mediante envíos insertados)
Fecha– Para registrar la fecha y hora en que se ejecutó la prueba
Hora de inicio: Tal y como ha informado el primer agente de prueba de carga de VSTS iniciado
Tiempo detenido: Tal y como ha informado el último agente de prueba de carga de VSTS para completarse
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 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 BizTalk Server durante la prueba.
Latencia media del 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.
Promedio de duración de solicitud-respuesta (ms): Como ha informado biztalk:Messaging Latency\Request-Response Latency (sec) Monitor de rendimiento contador para BizTalkServerIsolatedHost
Nota
Donde varios hosts de BizTalk virtualizados ejecutaban un promedio de estos contadores según se calculaba a partir de los registros.
Orquestaciones completadas por segundo: Como ha informado el contador de orquestaciones XLANG/s(BizTalkServerApplication)\Orquestaciones completada Monitor de rendimiento s por segundo. 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 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 prueba y el patrón de carga se modificaron durante las pruebas para ajustar el perfil de carga de cada prueba:
Configuración de la ejecución de prueba
La siguiente configuración de ejecución de prueba se modificó en función de la prueba que se realiza:
Duración de ejecución: Especifica cuánto tiempo se ejecuta la prueba.
Configuración de ejecución de prueba
Configuración de patrones de prueba
La siguiente configuración del patrón de prueba se modificó en función de la prueba que se realiza:
Patrón– Especifica cómo se ajusta la carga del usuario simulado durante una prueba de carga. Los patrones de carga son constantes, pasos o objetivos basados en objetivos. Todas las pruebas de carga realizadas eran Constante o Paso.
Nota
Todas las pruebas realizadas con fines de esta guía usan un patrón de carga constante o un patrón de carga paso . Los patrones de carga constante y los patrones de carga de pasos 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 aumenta durante la ejecución de pruebas; el número de usuarios simulados comienza en un nivel predefinido y se incrementa por una cantidad predefinida a intervalos predefinidos durante la prueba.
- 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.
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.
Recuento inicial de usuarios (patrón de carga de pasos): Número de usuarios virtuales que generan carga en la dirección del 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.
Número máximo de usuarios (patrón de carga de pasos): Número de usuarios virtuales que generan carga en la dirección del 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.
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 de prueba de carga.
Recuento de usuarios de pasos (patrón de carga de pasos): Número de usuarios virtuales que se van a aumentar en cada paso cuando se usa un patrón de carga de pasos.
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 de Monitor de rendimiento se capturaron como indicadores clave de rendimiento (KPI) para todas las ejecuciones de prueba:
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.
KPI de BizTalk Server
Documentos procesados por segundo: Medido por el contador BizTalk:Messaging/Documents procesados por segundo .
Latencia– Se mide según lo devuelto por la Load Test Controller vsTS 2008.
KPI de SQL Server
SQL Server uso del procesador: medido por el contador SQL\Processor(Total)\%Processor Time. Este contador mide el uso de cpu de SQL Server procesamiento en el equipo 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 SQL Server.
KPI de redes
BizTalk Server rendimiento de red: medido por el contador de monitor de rendimiento \Interfaz de red(*)\Bytes Total/s en los equipos BizTalk Server.
SQL Server rendimiento de red: medido por la interfaz de red de SQL\Bytes Totales por segundo (promedio) devuelto por el Load Test Controller vsTS 2008.
KPI de memoria
Memoria disponible: Medido por el contador \Memory\Available Mbytes para los distintos escenarios.
Características específicas de la infraestructura física
Para cada uno de los servidores que se instalaron se ajustaron las siguientes opciones de configuración.
Para todos los servidores:
El archivo de paginación se estableció 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 de rendimiento "Ajustar para el mejor 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.
En 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 base de datos y de registro se separaron entre los LUN como se indica a continuación para reducir la posible contención de E/S de disco:
El volumen de 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 del 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 Data_BtsMsgBox y el archivo de registro se almacenó en el volumen de Log_BtsMsgBox.
Además de esto, se proporcionó un LUN independiente para el archivo de registro MSDTC. En los sistemas de BizTalk de alto rendimiento, se ha mostrado la actividad del archivo de registro MSDTC para provocar 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 DE LUN GB Gb de tamaño de partición de host Tamaño de clúster Data_Sys 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 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 Logs_BAMPrimaryImport Archivo de registro 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 N/D Archivo de registro MSDTC 5 5 N/D BizTalk Server se instaló según las guías de instalación disponibles en https://go.microsoft.com/fwlink/?LinkId=128383.
La herramienta BizTalk Server Analizador de procedimientos recomendados (BPA) se usó para realizar la validación de la plataforma una vez configurado el sistema. El 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 de 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 instalada 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 de Hyper-V que se implementaron en todo el entorno. Sysprep se ejecutó en la imagen de VHD base para restablecer los identificadores de seguridad del sistema antes de que se implementaran los archivos binarios de SQL Server o BizTalk Server en el sistema.
Nota
La ejecución de Sysprep después de BizTalk Server se ha instalado y configurado 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 instalados solo en versiones de 32 y 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.
Consulte también
Apéndice C: compatibilidad de Hyper-V de BizTalk Server y SQL Server
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de