Fase 1. ámbito de la valoración
En este tema se describen los aspectos de la fase de ámbito de una evaluación del rendimiento de BizTalk Server.
Un error común al participar en una evaluación de rendimiento es subestimar el ámbito de la evaluación de rendimiento. Si no se asignan recursos y tiempo suficientes de antemano, el equipo responsable de la evaluación del rendimiento no podrá completar todas las tareas necesarias para compilar y probar un entorno complejo similar a producción. El equipo que trabaja en la evaluación del rendimiento debe elegir cuidadosamente sus batallas. La mayoría de las evaluaciones de rendimiento se realizan dentro de un período de tiempo muy limitado, por lo que el equipo debe identificar y centrarse en uno o dos, quizás tres como máximo, objetivos clave de rendimiento. La aplicación que se va a probar debe desarrollarse específicamente para centrarse en los objetivos de rendimiento identificados y debe factorizar todas las demás variables tecnológicas tanto como sea posible. En este tema se describen los aspectos de la fase de ámbito de una evaluación del rendimiento de BizTalk Server.
Consideraciones antes de comenzar la evaluación del rendimiento
Se deben tener en cuenta los siguientes factores antes de realizar cualquier otro trabajo para una evaluación del rendimiento. Estos factores ayudarán a decidir la dirección general de la fase de ámbito y son un buen punto de partida para una evaluación del rendimiento.
Carga de mensajes
Es importante tener en cuenta directamente desde el principio cómo va a replicar la carga de mensajes que realmente pasará por el sistema de producción. Por ejemplo, si en producción el 20 por ciento de los mensajes tendrá <un tamaño de 20 KB, el 50 por ciento tendrá <un tamaño de 100 KB y el 30 por ciento restante podría tener un tamaño de hasta 1 MB, es importante que esto se replique en el laboratorio.
Desarrollar un breve detalle de los escenarios que se van a probar
Después de haber identificado los casos de prueba que se probarán, es importante identificar los componentes principales implicados en ellos. Esto incluye tanto componentes de BizTalk Server (como mensajería y orquestaciones) como otros componentes, incluidas tecnologías de terceros como MQSeries o SAP. Es muy importante que tenga en cuenta todos estos aspectos desde el principio, ya que le ayudará a medir la complejidad del laboratorio y le permitirá planear las aptitudes técnicas necesarias durante la participación.
Identificar qué adaptadores se usarán
Es de vital importancia que el laboratorio de evaluación del rendimiento use los adaptadores reales que se usarán en el entorno de producción. Si no se usan los adaptadores reales usados en producción, se producen problemas porque el rendimiento de los diferentes adaptadores varía significativamente. Por ejemplo, el adaptador de archivo es uno de los adaptadores de BizTalk Server más rápidos, pero carece de algunas de las características necesarias de algunos sistemas; en particular, el adaptador de archivos no proporciona compatibilidad con transacciones. La compatibilidad con transacciones proporciona la capacidad de leer mensajes y escribirlos en la base de datos de cuadro de mensajes, todo ello dentro del contexto de una transacción MSDTC. La compatibilidad con transacciones supone una sobrecarga. Por lo tanto, el uso del adaptador de archivos para simular un escenario de producción que requiere compatibilidad con transacciones no sería una comparación viable. En este escenario, los resultados de rendimiento son básicamente no válidos porque no son muy probables que reflejen el rendimiento real del sistema de producción.
Tiempo estimado necesario para la evaluación del rendimiento
Use las siguientes instrucciones para calcular el tiempo necesario para la evaluación del rendimiento:
Asigne dos semanas de tiempo de preparación para configurar el entorno de prueba. Se usará una semana para crear la infraestructura necesaria, los componentes de software y aplicar las actualizaciones de software. La segunda semana se dedicará a configurar el entorno específico que duplica el entorno de producción BizTalk Server.
Asigne una semana adicional para cada caso de prueba que se analizará durante la evaluación del rendimiento.
Asigne una semana al final de la evaluación de rendimiento real para documentar los resultados de la evaluación de rendimiento.
Por lo tanto, para una evaluación de rendimiento típica con dos casos de prueba, el tiempo estimado para completar la evaluación sería:
(dos semanas de tiempo de preparación) + (dos semanas para la evaluación real del rendimiento) + (una semana para documentar los resultados) = cinco semanas en total.
Documentación de la evaluación del rendimiento
Como parte del ámbito de la evaluación del rendimiento, los detalles de la evaluación deben documentarse en un resumen de la interacción. Este documento debe definir claramente objetivos y objetivos, partes interesadas e hitos para la evaluación del rendimiento. Este documento servirá como hoja de ruta para la evaluación del rendimiento, ayudará a garantizar que todas las partes interesadas acepten los detalles de compromiso y sirvan para asegurarse de que la evaluación del rendimiento permanece en marcha. Este documento debe actualizarse a lo largo de la evaluación del rendimiento e incluir un resumen de los resultados tras la conclusión de la evaluación del rendimiento.
Objetivos
Definir cuidadosamente los objetivos de rendimiento y latencia : ¿Qué criterios de rendimiento está intentando maximizar? Normalmente, una o varias de las siguientes medidas de rendimiento son el foco de una BizTalk Server evaluación del rendimiento.
Rendimiento : normalmente se mide como el número de mensajes por unidad de tiempo que se puede procesar durante un intervalo de tiempo especificado. Por ejemplo, un objetivo de rendimiento podría definirse como la capacidad de procesar 100 mensajes por segundo durante un período de 3 horas.
Latencia : normalmente se define como porcentaje de todos los mensajes que se pueden procesar de un extremo a otro dentro de un intervalo de tiempo determinado, por ejemplo:
El 95 % de todos los mensajes se deben procesar de un extremo a otro en dos segundos.
El 100 % de todos los mensajes deben procesarse de un extremo a otro en cuatro segundos.
Cargas máximas
Tiempo para completar un lote deX
Escenarios de recuperación de Floodgate
Arquitectura de alto nivel, incluido el hardware y el software
Los objetivos de rendimiento deben medirse en términos de "lograr las restricciones de hardware y software más altas posibles". Determine cómo se medirá el objetivo con antelación. Por ejemplo, "Rendimiento máximo sostenible de X de un extremo a otro medido por el contador "XLang/s\orchestrations completado / segundo".
Nota
En los ejemplos anteriores, X es un marcador de posición para la unidad que es el foco de la evaluación del rendimiento. X podría representar orquestaciones, mensajes u otras métricas de rendimiento relevantes para la solución de BizTalk.
¿Se puede lograr el rendimiento deseado?
Al evaluar las consideraciones de rendimiento, primero debe determinar si los recursos de hardware disponibles serán suficientes para cumplir los objetivos de rendimiento. En algunos casos, el rendimiento deseado simplemente no es posible sin inversión adicional en hardware. No hay ninguna fórmula mágica que se pueda usar para determinar qué rendimiento es o no es posible dada una configuración de hardware específica, ya que muchos factores influyen en el rendimiento de la solución, incluida la complejidad de las orquestaciones, el código personalizado que se usa, el número de veces que los mensajes se conservan en la base de datos messageBox y las limitaciones de los sistemas externos. En la tabla siguiente se proporciona un resumen del hardware usado para lograr objetivos de rendimiento específicos para determinados escenarios.
Nota
La siguiente información solo se proporciona para obtener instrucciones. Los requisitos de diferentes BizTalk Server solución varían considerablemente, por lo que los valores de esta tabla se deben usar como una "regla general" aproximada al calcular los recursos de hardware necesarios.
Escenarios de hardware de ejemplo
| Tipo de procesamiento | BizTalk Server equipos | SQL Server equipos | Rendimiento alcanzado | Notas |
|---|---|---|---|---|
| Orquestación expuesta como un servicio web, adaptador MQSeries | - 6 equipos BizTalk Server 2010 - Cada servidor que ejecuta dos procesadores de doble núcleo de 3 GHZ - Windows Server 2008 R2, 8 GB de memoria |
- 3 equipos SQL Server 2008 R2 - Cada servidor que ejecuta cuatro procesadores de doble núcleo de 3 GHZ - 64 bits, 16 GB de memoria - Base de datos de cuadro de mensajes única |
95 orquestaciones por segundo | - Latencia media 1.11s - 99 % de los mensajes procesados con <una latencia de 2 segundos |
| Mensajería | 6 equipos BizTalk Server 2010 | 3 equipos SQL Server 2008 R2 | El rendimiento máximo alcanzado durante un período de 2 horas era de 277 mensajes por segundo | Antes de optimizar la solución, el rendimiento máximo era de 125 mensajes por segundo. |
| Escenario de baja latencia mediante orquestaciones y servicios web | Un procesador dual BizTalk Server equipo 2010 | Un procesador cuádruple SQL Server equipo 2008 R2 | 60 orquestaciones por segundo | < Latencia de 350 milisegundos alcanzada |
| Escenario de baja latencia mediante orquestaciones | 23 Equipos de cuatro procesadores BizTalk Server 2010 | - 3 equipos SQL Server 2008 R2 - Una base de datos messageBox maestra de 16 CPU - Dos equipos de base de datos de cuadro de mensajes secundario de 8 CPU |
1156 orquestaciones por segundo | A partir de enero de 2010, el máximo rendimiento sostenible de BizTalk Server orquestaciones en ejecución grabadas |
Una vez que la infraestructura de hardware disponible se considere suficiente para lograr el rendimiento deseado, tenga en cuenta lo siguiente al determinar el ámbito de una evaluación de rendimiento de BizTalk Server:
¿Qué adaptadores o aceleradores son necesarios?
¿Cuáles son los requisitos para implementar orquestaciones en la solución?
Requisitos de rendimiento del documento: ¿Cuáles son los requisitos de rendimiento sostenibles máximos para la solución?
Requisitos de latencia: ¿Qué capacidad de respuesta necesita la solución para escenarios de solicitud-respuesta y solicitud-respuesta?
¿Qué tan bien se recupera la solución de los períodos de carga máxima del documento?
¿Cuáles son los requisitos de alta disponibilidad de la solución?
¿Cuáles son los requisitos de seguimiento de documentos de la solución?
¿Cuáles son las características de rendimiento de cualquier aplicación dependiente, como un servicio web remoto u otro sistema? Si las aplicaciones dependientes no se mantienen al día de la carga necesaria, el rendimiento general del sistema se degradará en consecuencia.
Información de hardware que se debe tener en cuenta durante la fase de ámbito
Al determinar el ámbito de la solución, cree un diagrama de hardware de alto nivel que incluya lo siguiente:
Arquitectura de equipo (como x86, x64 e IA64)
Requisitos de CPU (como tipo, velocidad, número, núcleos y uso de hyperthreading)
Requisitos de RAM para cada equipo
Almacenamiento en disco local (tipo, tamaño, velocidad)
SAN (requisitos de almacenamiento: número de LUNS; Tipo de tarjeta SAN)
Tarjetas de red (número en cada equipo, 100 megabits por segundo (Mbps) frente a 1 gigabit por segundo (1 Gbps).
¿Cómo se implementarán los firewalls en la solución?
¿Se usará el hardware de equilibrio de carga de red?
¿Se van a agrupar equipos específicos?
Información de software que se debe tener en cuenta durante la fase de ámbito
Igualmente importante como la información de hardware es la pila de software que se usará durante la evaluación del rendimiento. Debe asegurarse de documentar la siguiente información:
Sistema operativo para cada equipo (32 o 64 bits, agrupados o no).
Software de servidor que se va a instalar en cada equipo.
Software de virtualización usado.
Las características de software específicas no suelen instalarse, como correcciones de acumulación de COM+ o SQL Server correcciones de host necesarias.
Determinar si los cambios de código están dentro del ámbito de la evaluación de rendimiento
Este es uno de los aspectos más importantes que se deben determinar durante el proceso de ámbito. BizTalk Server y los componentes subyacentes que usa (SQL Server, Windows, IIS y muchos más) se pueden optimizar mediante las técnicas de optimización y los cambios de configuración descritos en esta guía. Sin embargo, si una aplicación no se ha desarrollado para un rendimiento óptimo, puede dificultar estas ganancias de rendimiento. Por lo tanto, los cambios de código solo deben quitarse del ámbito si tiene confianza en que se ha completado una revisión exhaustiva del código antes de que la aplicación entre en el laboratorio. Si es necesario, puede aceptar que solo se permitan determinados cambios, por ejemplo, la eliminación de puntos de persistencia dentro de las orquestaciones.
Roles y responsabilidades
Una de las áreas más importantes de la ejecución de una evaluación de rendimiento es asegurarse de que los roles y las responsabilidades están claramente asignados. Se deben asignar los siguientes roles clave al inicio de la evaluación del rendimiento:
Responsable de la participación: el responsable del compromiso es responsable de poseer el compromiso general de un extremo a otro. Normalmente, este rol lo realizará un consultor sénior o arquitecto. Lo ideal es que esta persona tenga experiencia en la optimización de sistemas basados en BizTalk Server. El conocimiento de SQL Server y cualquier otra tecnología, incluidas las de terceros, es deseable. Tenga en cuenta que no es necesario que el líder sea un experto en todas las áreas, pero necesitan tener al menos un conocimiento práctico de la tecnología para que puedan trabajar con los especialistas en esas áreas y comprender las optimizaciones que están aplicando.
Diseñador de pruebas : es necesario tener a alguien que esté dedicado a diseñar e implementar las pruebas que se ejecutarán durante el laboratorio. Esto implicará decidir sobre el marco de pruebas que se usará para crear pruebas, probar cada una de las pruebas para asegurarse de que cumplirá los requisitos del laboratorio y asegurarse de que los responsables de ejecutar las pruebas sean conscientes de cómo usar el cliente.
Propietario del entorno: tener un entorno representativo dentro del laboratorio que refleje con precisión el entorno de producción BizTalk Server es fundamental. La persona que realiza este rol será responsable de comprobar cada elemento de la pila de hardware y software utilizada y validar que no hay diferencias significativas. Por ejemplo, SQL Server 2008 R2 cuando se ejecuta en la plataforma de 32 bits solo puede abordar 4 GB de memoria física sin usar extensiones de direcciones físicas (PAE) o extensiones de ventana de direcciones (AWE). En SQL Server 2008 R2, se pueden solucionar hasta 1 terabyte de memoria de 64 bits (se trata de la memoria física máxima actual compatible con Windows Server 2008 R2). Por lo tanto, una diferencia significativa entre el cliente y el entorno de laboratorio sería la arquitectura de cpu usada por BizTalk Server y SQL Server. Además de estos factores obvios, otros factores menos obvios, como los niveles de Service Pack y las revisiones instaladas, pueden afectar al rendimiento del entorno.
Responsable del entorno de compilación: una vez que se haya elaborado una especificación detallada para la evaluación del rendimiento, a alguien se le debe asignar la responsabilidad de crear el entorno. Esto incluirá la pila de hardware y software. En muchos casos, una persona será responsable de esto (esto suele ser el propietario del entorno). Sin embargo, en una gran empresa, el propietario del entorno puede necesitar ser el enlace entre diferentes equipos, que pueden ser responsables de varios componentes de la solución. Por ejemplo, un equipo puede ser responsable de la compilación de Windows, otra para SQL Server y otro equipo para BizTalk Server.
Responsable de implementación: es necesario tener a alguien responsable de asegurarse de que la aplicación se implementa correctamente en BizTalk Server, de que se configuran los enlaces correctos y de que se aplica cualquier configuración personalizada. Este rol requerirá un conocimiento exhaustivo de la solución y requerirá el conocimiento para empaquetar una aplicación e implementar una aplicación y, a continuación, validará que está en un estado de funcionamiento dentro del entorno de laboratorio.
Especialistas en productos: es importante identificar qué especialistas de productos son necesarios para la evaluación del rendimiento. Las aptitudes exactas necesarias dependen del diseño y el propósito de la aplicación de BizTalk Server.
Una de las aptitudes especializadas en productos más comunes requeridas es un amplio conocimiento de la optimización del rendimiento SQL Server. Estas aptitudes son necesarias para dos propósitos: en primer lugar, a menudo es necesario realizar SQL Server optimizaciones para optimizar el rendimiento de las bases de datos de BizTalk y, en segundo lugar, muchas soluciones de BizTalk usan bases de datos personalizadas. El uso de bases de datos personalizadas puede convertirse en un cuello de botella en la solución si las optimizaciones correctas no se aplican al entorno de SQL Server. Para identificar y aplicar las optimizaciones de base de datos adecuadas, normalmente se requieren las siguientes aptitudes de SQL Server:
Conocimiento exhaustivo de SQL Server código de procedimiento almacenado, incluida la capacidad de optimizar los procedimientos almacenados existentes.
Capacidad de identificar y crear índices de base de datos que faltan.
Capacidad de escribir scripts para dividir bases de datos en varios archivos.
Nota
Para obtener más información sobre cómo aplicar esta optimización, consulte Optimización de grupos de archivos para las bases de datos2.
Capacidad de identificar problemas de rendimiento mediante SQL Server 2008 R2 Informes del panel de rendimiento.
Para cada tecnología especializada implicada en la evaluación del rendimiento, se debe definir una lista de requisitos tal y como se ha hecho anteriormente para SQL Server. Esto garantiza que el recurso obtenido tenga expectativas claras de lo que será necesario. Otra tecnología que con frecuencia requiere conocimientos especializados durante la evaluación del rendimiento es IBM Websphere MQ. En la lista siguiente se muestran las especificaciones de requisitos para un especialista en productos de IBM WebSphere MQ:
Experiencia en la supervisión, mantenimiento y personalización de MQSeries.
Experiencia con la instalación y migración de nuevas versiones de MQSeries.
Capacidad de analizar y optimizar el rendimiento de MQSeries.
Realice el análisis de problemas de MQSeries.
Conocimientos de los procesos y procedimientos relacionados con la seguridad, administración, recuperación y automatización de MQSeries.
Jefe de documentación : actualizar continuamente la documentación del laboratorio de un extremo a otro a lo largo de la evaluación del rendimiento es fundamentalmente importante. No se debe juzgar el éxito general de una interacción de laboratorio hasta que las optimizaciones se hayan aplicado correctamente en el entorno de producción y el sistema haya obtenido el nivel deseado de rendimiento. Para ello, es esencial que se mantenga un registro detallado de la siguiente información:
Resumen de resultados de alto nivel del laboratorio
Problemas sin resolver
Problemas resueltos
Escala de tiempo del laboratorio
Progreso del laboratorio
Optimizaciones implementadas por categoría
Optimizaciones implementadas en orden cronológico (para asegurarse de que se pueden aplicar en el mismo orden en el sistema de producción)
Diagrama de arquitectura de alto nivel
Detalles de los escenarios que se van a probar
Tecnologías de terceros implicadas
Diagrama de hardware del laboratorio
Lista de contactos
Inventario detallado de hardware
Apéndice con resultados detallados completos
Desarrollador : si se requiere un desarrollador depende mucho del ámbito de la interacción. Si la base de código se ha bloqueado y el laboratorio está allí para probar las optimizaciones de la infraestructura y la plataforma solo, los servicios de un desarrollador no deben ser necesarios. Este tipo de escenario puede producirse cuando se realizan pruebas de rendimiento justo antes de la fecha de ejecución del servidor de producción. En este momento, el código debe haberse bloqueado y las pruebas de regresión completa deben completarse o estar en curso. Cualquier cambio en el código introducido en el laboratorio podría introducir una regresión y, por lo tanto, introducir riesgos para el sistema de producción. Si se permiten cambios en el código, normalmente se necesitará un desarrollador. La lista siguiente representa las aptitudes que normalmente requiere un desarrollador que se dedica a una evaluación del rendimiento de BizTalk Server:
Capacidad de identificar y corregir problemas de rendimiento con orquestaciones
Capacidad de identificar y corregir problemas de rendimiento con canalizaciones
Conocimientos de .NET, entre los que se incluyen:
Biblioteca empresarial
Experiencia del generador de perfiles de Visual Studio F1
Microsoft Visual Studio 2010 Ultimate o Visual Studio Test Professional 2010
Cliente potencial de prueba : garantizar que se obtiene un conjunto preciso, completo y exhaustivo de resultados es fundamental. El responsable de pruebas es responsable de garantizar que la información necesaria se capture, analice correctamente y distribuya adecuadamente después de cada ejecución de pruebas. Es importante tener en cuenta cómo capturar los datos, normalmente los datos de prueba son adecuados para la presentación mediante una hoja de cálculo de Excel. En la lista siguiente se muestran los datos que se deben capturar para cada prueba que se ejecuta durante el laboratorio:
Número de ejecución de prueba
Date
Total de mensajes procesados
Mensajes procesados por segundo
Hora de inicio
Tiempo detenido
Duración de la prueba en minutos
Mensajes suspendidos/Total de mensajes procesados: se puede capturar desde la consola de administración de BizTalk o midiendo los contadores de rendimiento de BizTalk Server mediante Monitor de rendimiento.
Número de mensajes que han producido un error en el procesamiento
# o mensaje que se han procesado correctamente
Prueba de las respuestas de cliente
Promedio de duración del proceso de cliente, medido en segundos: normalmente este valor se mide al implementar una solución de mensajería sincrónica con BizTalk Server, en este caso es importante conocer el valor de duración media del cliente, ya que suele ser representativo del tiempo que un usuario final espera una respuesta de la solución.
Valor máximo de duración del proceso de cliente, medido en segundos
Valor mínimo de duración del proceso de cliente, medido en segundos
BizTalk Server latencia de solicitud/respuesta, medida en segundos
Orquestaciones completadas por segundo
% de mensajes procesados a tiempo
Valor de la variable TestResultsLocation usada por las herramientas de pruebas de Visual Studio Team System.
Valor de la variable TestResultsLocation usada por BizUnit.
Cualquier comentario o recomendación
Además de recopilar los resultados, el cliente potencial de prueba debe asegurarse de que supervisan cada ejecución de pruebas para ver si hay alguna tendencia. Las mejoras de rendimiento deben comunicarse con el resto del equipo y deben indicar cuánto rendimiento se mejoró y qué optimización se aplicó para lograr la mejora. Al final del día, es importante que el cliente potencial de prueba proporcione un resumen de las pruebas que se han realizado en el laboratorio. Esto permite a las partes interesadas mantenerse informados del progreso continuo del laboratorio. En la tabla siguiente se muestra cómo se puede reunir esta información en un correo electrónico de actualización de ejemplo:
Resumen de los resultados de las pruebas
Estado Rendimiento Latencia media %< 2 segundos Número de ejecuciones de pruebas Número de equipos de BizTalk Server Número de mensajes Tamaño medio de mensaje Duration Escalado horizontal 140 mensajes/segundo 0,777 segundos 99.3% 2 6 270 000 609 bytes 30 minutos Óptima 50 mensajes/segundo 1,12 segundos 99.12% 17 2 360,000 609 bytes 2 horas Línea base 30 mensajes/segundo 1,52 segundos 92.9 % 4 2 36 000 609 bytes 20 minutos Objetivos 5 mensajes/segundo < 2 segundos 90% - 2 - - -
Definir todas las entregas necesarias en el inicio de la evaluación del rendimiento
Es importante acordar las entregas que deben aplicarse antes de embarcarse en una evaluación de rendimiento BizTalk Server. En la sección siguiente se describen los resultados que deben aplicarse en el inicio de la evaluación del rendimiento.
Aplicación que se va a probar : la aplicación completa que se usará durante la evaluación del rendimiento debe estar disponible. Es importante que la aplicación esté en un estado de funcionamiento completo antes de comenzar la evaluación del rendimiento; de lo contrario, existe el riesgo de perder un tiempo de prueba de laboratorio valioso.
Planeación de la compilación e implementación automatizadas: antes de participar en la evaluación del rendimiento, se debe desarrollar un proceso automatizado de compilación e implementación para que se pruebe la solución BizTalk Server. La automatización del proceso de compilación de una aplicación permite realizar un proceso de compilación diario continuo, que luego puede ir acompañado de un conjunto de pruebas de validación de compilación (BVT) que prueban los flujos funcionales a través del sistema. Esto le permite detectar problemas funcionales y de compilación más rápidos y fáciles a lo largo del ciclo de vida de desarrollo. En el laboratorio, esto significa que si se requiere algún cambio de código, puede comprobar rápidamente que la solución actualizada funciona sin problemas. La creación manual, implementación y configuración de una aplicación para un laboratorio de rendimiento puede ser una tarea tediosa y propensa a errores. Por lo tanto, se recomienda usar una técnica de automatización para realizar las siguientes actividades de compilación e implementación:
Obtenga el código más reciente del control de código fuente.
Compile la solución completa.
Implemente la solución en el entorno.
Crear aplicaciones de BizTalk.
Agregue BizTalk Server recursos como .dll archivos y enlaces a aplicaciones de BizTalk.
Importe el archivo de enlace para crear puertos y enlazar a orquestaciones.
Exporte las aplicaciones de BizTalk como un paquete de Microsoft® Windows® Installer para que se pueda implementar en el entorno de prueba o producción.
Nota
Para obtener más información sobre cómo implementar un proceso de compilación automatizado, consulteAutomatización del proceso de compilación.
MSBuild se introdujo con .NET Framework 2.0 para permitir a los desarrolladores automatizar tareas como las descritas anteriormente. Varias tareas de MSBuild específicas de BizTalk Server se incluyen con la biblioteca de tareas de SDC, que está disponible para su descarga desde https://go.microsoft.com/fwlink/?LinkId=119288.
Datos de prueba que se usarán durante la evaluación del rendimiento: los datos de prueba que se usan tienen una influencia considerable en la eficacia general y el éxito de una evaluación del rendimiento. Tenga en cuenta el escenario en el que una aplicación de BizTalk Server utiliza la mensajería, la orquestación y el motor de reglas. Se llama al motor de reglas desde dentro de un componente de canalización en el lado de recepción para determinar qué orquestación se usará para procesar el mensaje; y también se llama desde dentro de la orquestación en varios puntos para determinar el flujo. El motor de reglas implementa el almacenamiento en caché para que la ejecución de directivas de reglas esté optimizada. Por lo tanto, si se usa un único mensaje como datos de prueba durante la evaluación del rendimiento, los resultados de las pruebas pueden estar sesgados (debido al almacenamiento en caché) y puede obtener resultados que no se pueden replicar en producción.
Idealmente, los datos de prueba utilizados durante la evaluación del rendimiento deben ser datos de producción reales o un subconjunto de datos de producción. Los datos de prueba también deben simular la carga y el patrón de tráfico que fluirán a través del sistema de producción. Tenga en cuenta los siguientes factores al definir los requisitos para los datos de prueba:
Número de mensajes que fluirán por el sistema en un período determinado : normalmente se expresa como mensajes por segundo o mensajes por hora.
Tipos de mensajes : ¿Son los mensajes archivos planos, XML o binarios?
Distribución de mensajes : ¿Qué porcentaje será un archivo plano, qué porcentaje de cada tipo de mensaje XML se usará?
Requisitos de procesamiento de carga máxima: en muchos escenarios, se puede procesar un intercambio grande durante horas no punta. Por ejemplo, un gran lote de pagos se puede publicar en los sistemas de un banco a medianoche. Si este es el caso, asegúrese de que puede replicarlo durante las pruebas.
Puntos de conexión usados para recibir o enviar mensajes : en muchos entornos se configuran ubicaciones de recepción independientes para recibir diferentes tipos de mensajes. Por ejemplo, se pueden recibir mensajes de archivo sin formato mediante el adaptador de archivo o el adaptador MQSeries para recibir mensajes XML. Aunque todos los mensajes pueden ser procesados por las mismas orquestaciones, tendrán puntos de entrada diferentes en el sistema. Cada una de estas diferentes ubicaciones de recepción se puede hospedar en un host independiente; de hecho, esto a menudo mejorará el rendimiento general del sistema.
En la tabla siguiente se proporciona un ejemplo de la información que se debe capturar al determinar las especificaciones de datos de prueba:
Especificación de datos de prueba de ejemplo
| Category | Descripción |
|---|---|
| Mensajes por segundo | - El rendimiento máximo es clave en este escenario. - Objetivo de 50 mensajes por segundo - La baja latencia no es un objetivo |
| Tipo de mensajes | - Mensajes XML pequeños, aproximadamente 25 KB que se ajustan al esquema XML X - Mensajes XML medianos, aproximadamente 512 KB que se ajustan al esquema XML Y |
| Distribución de mensajes | - 58% 25 KB (mensajes XML pequeños) - 25% 512 KB (mensajes XML medianos) - 11% 3 MB (datos binarios medianos – PDF) – no compresión - 4% 7,5 MB (datos binarios grandes – PDF) – no comprimible) - 2% 20 MB (datos binarios grandes – PDF) – no compresión |
| Requisitos de procesamiento de carga máxima | Los datos binarios grandes (20 MB) representarán aproximadamente el 2 % de los datos (como se especificó anteriormente) el momento en el que se procesa no es predecible. El sistema debe ser capaz de acomodar estos mensajes grandes en cualquier momento dado. |
| Puntos de conexión usados para recibir o enviar mensajes | Mensajes XML pequeños (25 KB) - Ubicación de recepción: PaymentXMLDocIn - Host: ReceiveHost - Canalización usada: XMLReceive Mensajes XML medianos (512 KB) - Ubicación de recepción: PaymentXMLDocIn - Host: ReceiveHost - Canalización usada: XMLReceive Datos binarios medianos (3 MB) – PDF – no compresión - Ubicación de recepción: BinaryDataIn - Host: ReceiveHost - Canalización usada: PassThruReceive Datos binarios grandes (7,5 MB – 20 MB) – PDF – no compresión - Ubicación de recepción: BinaryDataIn - Host: ReceiveHost - Canalización usada: PassThruReceive |
| Ubicación de los datos de prueba | Recurso compartido de archivos de datos de prueba accesible localmente, por ejemplo: \\PerformanceLabs\July\Test Data\ |
Colocar la información en una tabla logra varias cosas. En primer lugar, facilita a las partes interesadas que acepten las suposiciones realizadas sobre los datos de prueba. En segundo lugar, proporciona información que se puede usar para decidir las posibles optimizaciones para la evaluación del rendimiento. Por ejemplo, en la tabla anterior puede ver que todas las ubicaciones de recepción usadas para procesar todos los tipos de datos diferentes se hospedan en el host de BizTalk ReceiveHost. Esto significa que cada instancia de este host será responsable de procesar diferentes tipos y tamaños de datos (por ejemplo, datos XML y binarios pdf no comprimibles). Dado que cada instancia de host es una única instancia del proceso de BizTalk Server (BTSNTSVC.EXE), esto podría convertirse en un cuello de botella de procesamiento. Por lo tanto, en este escenario, una optimización inmediatamente obvia para el entorno sería probar la mejora del rendimiento de separar cada ubicación de recepción en su propio host individual. Tener acceso a la información de datos de prueba en un formato tabular de resumen facilita la medición de optimizaciones sencillas como esta.
- Planeación de pruebas de carga automatizadas y generación de carga : después de establecer el perfil de datos de prueba para la evaluación de rendimiento, es importante tener en cuenta cómo realizar pruebas de carga en el entorno. Para BizTalk Server prueba de carga de 2010, usamos la prueba de carga de Visual Studio 2010. Para obtener más información sobre cómo facilitar las pruebas de carga mediante Visual Studio 2010, consulte Uso de Visual Studio para facilitar las pruebas automatizadas.