Escenarios de prueba para medir MST del motor
En esta sección se describe el escenario de prueba que se ha implementado para medir el efecto de exponer un sistema de BizTalk a tres niveles distintos de carga:
Prueba de carga sostenible. Con fines de estas pruebas, la carga sostenible se describe en el tema ¿Qué es el rendimiento sostenible?.
Prueba de carga de overdrive. La carga de overdrive se define como una carga coherente que supera MST.
Prueba de carga de Floodgate. La carga de floodgate se define como carga baja con picos intermitentes de carga que superan el MST.
En este tema se describe la configuración del hardware de prueba, los escenarios de prueba, y aborda los resultados de cada una de estas pruebas.
Importante
El lector debería tener en cuenta que la información contenida en esta sección representa la visión actual de Microsoft acerca de los asuntos tratados hasta la fecha de su publicación. Puesto que debemos responder a condiciones de mercado y tecnologías variables, no debe interpretarse como un compromiso por parte de Microsoft, y Microsoft no puede garantizar la precisión de la información que se presenta después de la fecha de publicación.
Configuración del sistema de prueba
En este escenario de prueba se ha utilizado el hardware siguiente:
Seis servidores de BizTalk Server. Cada uno equipado con procesadores duales de 3 GHz y 2 GB de RAM. Cada servidor utiliza discos locales. Dos de los servidores BizTalk Server están configurados con una instancia del host de recepción, otros dos con una instancia del host de envío y otros dos con una instancia del host utilizada para procesar orquestaciones.
Una SQL Server para la base de datos maestra messageBox y las bases de datos que no son messagebox. Equipado con ocho procesadores de 2GHz y 4 GB de memoria RAM. Este servidor está conectado a un rápido subsistema de discos SAN a través de fibra. La publicación de mensajes está deshabilitada.
Tres servidores SQL Server para las bases de datos de cuadro de mensajes en las que se están publicando. Equipado con cuatro procesadores de 2GHz y 4 GB de memoria RAM. Cada uno de estos servidores está conectado a un subsistema de discos SAN a través de fibra. Los archivos de registro de datos y de transacción de la base de datos de cuadro de mensajes se encuentran en números distintos de unidad lógica (LUN) de la red de área de almacenamiento (SAN).
Carga del equipo cliente del controlador. Equipado con 3 procesadores duales de 3GHz y 2GB de memoria RAM. Este servidor se ha utilizado para generar la carga de la prueba del sistema BizTalk.
La topología utilizada en las pruebas de carga se ilustra a continuación.
Topología utilizada en pruebas de carga
El escenario de prueba
El escenario de prueba es muy sencillo. La herramienta para la generación de cargas, LoadGen 2007, se ha instalado en el servidor para el control de carga y se ha usado para enviar copias de un archivo a recursos compartidos supervisados por el adaptador de archivo. La herramienta para la generación de cargas distribuye copias de la instancia del archivo entrante de modo uniforme a los recursos compartidos.
Nota
Descargue LoadGen. Para obtener información sobre el uso de LoadGen con el adaptador de MSMQ, consulte Uso de LoadGen 2007 con MSMQ.
El adaptador de archivo de BizTalk se configura para supervisar los recursos compartidos de archivo y publicar los mensajes en el cuadro de mensajes. Una orquestación sencilla que contiene únicamente una forma de recepción y una forma de envío se suscribe a un mensaje publicado. Los mensajes que la orquestación vuelve a publicar en el cuadro de mensajes son recogidos por un puerto de envío de archivos y enviados a un recurso compartido que se define en la SAN. Los archivos que llegan al recurso compartido de SAN de salida se eliminan de forma automática, a fin de evitar que se amontonen en el recurso durante pruebas de larga ejecución.
En este escenario se han definido cuatro hosts: uno para la ubicación de recepción, otro para las orquestaciones, un tercero para el puerto de envío y el último para el seguimiento. Con el objetivo de observar el comportamiento del trabajo acumulado del motor, el seguimiento se desactiva por completo durante la prueba. El seguimiento solo se activa de forma predeterminada para las canalizaciones y orquestaciones, por lo que se ha desactivado de forma expresa en el administrador de BizTalk para la orquestación y la canalización de este escenario de prueba.
No se han creado instancias del host de seguimiento, ya que se ha desactivado el seguimiento para aislar el comportamiento del cuadro de mensajes en estas pruebas.
Se ha utilizado un esquema simple, y el tamaño de los archivos de instancia empleados para la prueba era de 10KB. Se ha utilizado la canalización XMLReceive en los documentos entrantes, pero no se han realizado asignaciones de componentes ni de componentes salientes con el objetivo de no complicar demasiado el escenario de prueba y centrar las observaciones en el comportamiento del cuadro de mensajes.
Parámetros medidos en la prueba
Los parámetros medidos en esta prueba son los siguientes:
Parámetros principales de la prueba
Los parámetros siguientes son los indicadores principales de la medición de MST:
Trabajo pendiente de cuadro de mensajes medido por el contador Tamaño de cola que está disponible con el objeto de rendimiento BizTalk:MessageBox:General Counters . El trabajo acumulado del cuadro de mensajes es un indicador de la sostenibilidad. La prueba es que el aumento indefinido del trabajo acumulado del cuadro de mensajes puede generar problemas. De ahí que se supervise la profundidad del trabajo acumulado de la base de datos de cuadro de mensajes para evaluar la sostenibilidad.
La tabla MessageBox denominada spool contiene un registro para cada mensaje del sistema (activo o esperando a que se recopilen elementos no utilizados). La supervisión del número de filas de esta tabla y del número de mensajes que se reciben por segundo mientras aumenta la carga del sistema resulta una forma sencilla de medir el rendimiento máximo sostenible. Esta medida también se conoce como profundidad de la tabla de cola o profundidad de cola.
El número de documentos recibidos por segundo medidos por el contador Documentos recibidos por segundo que está disponible con el objeto de rendimiento BizTalk:Messaging .
Parámetros secundarios de la prueba
Los parámetros siguientes son indicadores secundarios que se pueden evaluar al medir MST. Estos parámetros pueden afectar a los indicadores principales, es decir, a la profundidad de la cola de impresión y al número de documentos recibidos por segundo.
El tiempo de inactividad del disco físico para los datos del cuadro de mensajes y el disco del archivo de transacción medido por el contador %Tiempo de inactividad disponible con el objeto de rendimiento LogicalDisk .
El uso de CPU (%) para el servidor MessageBox medido por el contador %Processor Time disponible con el objeto de rendimiento Processor .
Los tiempos de espera de bloqueo por segundo en la base de datos de cuadro de mensajes medidos por el contador Tiempos de espera de bloqueo por segundo disponibles con el objeto de rendimiento SQLServer:Locks .
El tiempo en segundos de la ejecución más reciente del trabajo del agente de SQL que consiste en limpiar las tablas de cuadro de mensajes asociadas a los mensajes eliminados. Esto se mide mediante el contador MsgBox Msg Cleanup(Purge Jobs) disponible con el objeto de rendimiento BizTalk:MessageBox:General Counters .
El tiempo en segundos de la ejecución más reciente del trabajo del agente de SQL que consiste en limpiar las tablas de cuadro de mensajes asociadas con las partes eliminadas de los mensajes. Esto se mide mediante el contador MsgBox Parts Cleanup(Purge Jobs) disponible con el objeto de rendimiento BizTalk:MessageBox:General Counters .
Cuando se realiza una prueba para determinar el rendimiento máximo sostenible, la carga de entrada se incrementó hasta que la tabla de la cola de impresión comenzó a crecer de forma indefinida.
Nota
Si no puede generar la carga necesaria para que la tabla de la cola de impresión crezca de esa forma, es porque la parte más lenta del sistema se encuentra en el extremo de recepción, en lugar de en el extremo de envío o procesamiento.