Share via

Optimizaciones generales para BizTalk Server: parte 1

  • Artículo

Se pueden usar las siguientes recomendaciones para aumentar BizTalk Server rendimiento. Las optimizaciones enumeradas en este tema se aplican después de instalar y configurar BizTalk Server.

Configuración de MSDTC

Para facilitar las transacciones entre SQL Server y BizTalk Server, debe habilitar el Coordinador de transacciones distribuidas de Microsoft (MS DTC). Para configurar MSDTC en BizTalk Server, consulte el tema Directrices generales para mejorar el rendimiento del sistema operativo.

Recomendaciones para configurar hosts de BizTalk Server

En esta sección se proporcionan recomendaciones para configurar hosts BizTalk Server.

Creación de varios hosts BizTalk Server e instancias de host independientes por funcionalidad

Siga estas instrucciones para crear varios hosts de BizTalk Server y asignar la carga de trabajo entre esos hosts:

  • Cree hosts independientes para enviar, recibir, procesar y realizar un seguimiento de la funcionalidad. La creación de varios hosts de BizTalk proporciona flexibilidad al configurar la carga de trabajo en el grupo de BizTalk y es el medio principal de distribuir el procesamiento entre los equipos que ejecutan BizTalk Server en un grupo de BizTalk. El uso de varios hosts permite detener un host sin afectar a otros hosts. Por ejemplo, es posible que quiera dejar de enviar mensajes para permitirles poner en cola en la base de datos de cuadro de mensajes mientras se sigue permitiendo que un adaptador de recepción se ejecute en una instancia de host diferente para recibir mensajes entrantes. La separación de instancias de host por funcionalidad también proporciona las siguientes ventajas:

    • La ejecución de varios hosts de BizTalk reduce la contención en las tablas de cola del host de la base de datos messageBox porque a cada host se le asignan sus propias tablas de colas de trabajo en la base de datos messagebox.

    • La limitación se implementa en BizTalk Server en el nivel de host. Esto le permite establecer diferentes características de limitación para cada host.

    • La seguridad se implementa en el nivel de host; cada host se ejecuta bajo una identidad discreta de Windows. Esto le permite, por ejemplo, conceder a Host_A acceso a FileShare_B, a la vez que no permite que ninguno de los demás hosts acceda al recurso compartido de archivos.

  • Cada instancia de host tiene su propio conjunto de recursos, como la memoria, los identificadores y los subprocesos del grupo de subprocesos de .NET. Al asignar cargas de trabajo entre hosts, considere la posibilidad de colocar recursos que se escalan juntos en el mismo host.

  • Adaptadores y orquestaciones independientes que tienen prioridades diferentes para los recursos de diferentes hosts. Esta técnica admite la colocación de hosts que ejecutan aplicaciones de alta prioridad en equipos BizTalk Server dedicados.

Nota

Aunque hay ventajas para crear instancias de host adicionales, también hay posibles inconvenientes si se crean demasiadas instancias de host. Cada instancia de host es un servicio de Windows (BTSNTSvc.exe), que genera una carga adicional en la base de datos messagebox y consume recursos de equipo (como CPU, memoria, subprocesos).

Para obtener más información sobre cómo modificar BizTalk Server propiedades de host, vea How to Modify Host Properties (https://go.microsoft.com/fwlink/?LinkID=154359) en la Ayuda de BizTalk Server 2010.

Configuración de un host de seguimiento dedicado

BizTalk Server está optimizado para el rendimiento, por lo que los principales motores de orquestación y mensajería no mueven realmente los mensajes directamente a las bases de datos de BizTalk Tracking o BAM, ya que esto desviaría estos motores del trabajo principal de ejecutar procesos empresariales. En su lugar, BizTalk Server deja los mensajes en la base de datos de cuadro de mensajes y los marca como que requieren un traslado a la base de datos de seguimiento de BizTalk. A continuación, un proceso en segundo plano (el host de seguimiento) mueve los mensajes a las bases de datos de BizTalk Tracking y BAM. Dado que el seguimiento es una operación que consume muchos recursos, se debe crear un host independiente dedicado al seguimiento, lo que minimiza el impacto que tiene el seguimiento en los hosts dedicados al procesamiento de mensajes. Para obtener un rendimiento óptimo, debe haber al menos una instancia de host de seguimiento por base de datos de cuadro de mensajes. El número real de instancias de host de seguimiento debe ser N + 1, donde N = el número de bases de datos de cuadro de mensajes. "+ 1" es para redundancia, en caso de que se produzca un error en uno de los equipos que hospeda el seguimiento.

El uso de un host de seguimiento dedicado también le permite detener otros hosts de BizTalk sin interferir con BizTalk Server seguimiento. El movimiento de datos de seguimiento fuera de la base de datos de Cuadro de mensajes es fundamental para un sistema de BizTalk Server correcto. Si el host de BizTalk responsable de mover los datos de seguimiento en el grupo de BizTalk se detiene, el servicio Descodificación de datos de seguimiento no se ejecutará. El impacto de esto es el siguiente:

  • Los datos de seguimiento de HAT no se moverán de la base de datos messagebox a la base de datos de seguimiento de BizTalk.

  • Los datos de seguimiento de BAM no se moverán de la base de datos messagebox a la base de datos de importación principal de BAM.

  • Dado que los datos no se mueven, no se pueden eliminar de la base de datos de Cuadro de mensajes.

  • Cuando se detiene el servicio Descodificación de datos de seguimiento, los interceptores de seguimiento seguirán activando y escribiendo datos de seguimiento en la base de datos messagebox. Si los datos no se mueven, esto hará que la base de datos de Cuadro de mensajes se sobredimensione, lo que afectará al rendimiento con el tiempo. Incluso si no se realiza un seguimiento de las propiedades personalizadas o los perfiles de BAM no están configurados, de forma predeterminada se realiza un seguimiento de algunos datos (por ejemplo, eventos de recepción o envío de canalización y eventos de orquestación). Si no desea ejecutar el servicio Descodificación de datos de seguimiento, desactive todo el seguimiento para que ningún interceptor guarde los datos en la base de datos. Para deshabilitar el seguimiento global, consulte Cómo desactivar el seguimiento global (https://go.microsoft.com/fwlink/?LinkID=154193) en BizTalk Server ayuda de 2010. Use la consola de administración de BizTalk Server para deshabilitar de forma selectiva los eventos de seguimiento.

    El host de seguimiento debe ejecutarse en al menos dos equipos que ejecuten BizTalk Server (en caso de que se produzca un error en la redundancia). Para obtener un rendimiento óptimo, debe tener al menos una instancia de host de seguimiento por base de datos de cuadro de mensajes. El número real de instancias de host de seguimiento debe ser (N + 1), donde N = el número de bases de datos de cuadro de mensajes. "+ 1" es para redundancia, en caso de que se produzca un error en uno de los equipos que hospeda el seguimiento.

    Una instancia de host de seguimiento mueve los datos de seguimiento de bases de datos de cuadros de mensajes específicos, pero nunca habrá más de una instancia de host de seguimiento que mueva los datos de una base de datos de cuadro de mensajes específica. Por ejemplo, si tiene tres bases de datos messageBox y solo dos instancias de host de seguimiento, una de las instancias de host debe mover datos para dos de las bases de datos de cuadro de mensajes. Agregar una tercera instancia de host de seguimiento distribuye el trabajo del host de seguimiento a otro equipo que ejecuta BizTalk Server. En este escenario, agregar una cuarta instancia de host de seguimiento no distribuiría más trabajo de host de seguimiento, pero proporcionaría una instancia de host de seguimiento adicional para la tolerancia a errores.

    Para obtener más información sobre el servicio Bam Event Bus, consulte los temas siguientes en BizTalk Server Ayuda de 2010:

  • Administrar el servicio de Bus de eventos de BAM (https://go.microsoft.com/fwlink/?LinkID=154194).

  • Creación de instancias del servicio de bus de eventos de BAM (https://go.microsoft.com/fwlink/?LinkID=154195).

No agrupar hosts de BizTalk a menos que sea absolutamente necesario

Aunque BizTalk Server 2010 permite configurar un host de BizTalk como un recurso de clúster, solo debe considerar hacerlo si necesita proporcionar alta disponibilidad a un recurso que no se puede hospedar en varios equipos de BizTalk. Por ejemplo, los puertos que usan el adaptador FTP solo deben residir en una instancia de host, ya que el protocolo FTP no proporciona bloqueo de archivos. Sin embargo, esto introduce un único punto de error, que se beneficiaría de la agrupación en clústeres. Los hosts que contienen adaptadores, como archivos, SQL, HTTP o solo hosts de procesamiento, se pueden equilibrar internamente la carga entre equipos y no se benefician de la agrupación en clústeres.

Aumente el número de conexiones simultáneas HTTP permitidas cambiando el valor del parámetro maxconnection.

De forma predeterminada, los adaptadores HTTP (incluidos los adaptadores HTTP basados en WCF) abren solo dos conexiones HTTP simultáneas de cada equipo que ejecuta BizTalk Server a cualquier servidor de destino específico.

Esta configuración se ajusta a la RFC de IETF para la especificación HTTP 1.1 y, aunque es adecuada para escenarios de usuario, no está optimizada para un alto rendimiento. La configuración limita eficazmente las llamadas HTTP salientes a cada servidor a dos envíos simultáneos desde cada equipo que ejecuta BizTalk Server.

Para aumentar el número de conexiones simultáneas, puede modificar el valor del parámetro maxconnection en el archivo de configuración de BizTalk Server, BTSNTSvc.exe.config (o BTSNTSvc64.exe.config para hosts de 64 bits), en cada BizTalk Server. Puede aumentar esto para los servidores específicos a los que se llama. Como regla general, el valor del parámetro maxconnection debe establecerse en 12 * el número de CPU o núcleos en el equipo que hospeda la aplicación web.

Nota

No aumente el valor del parámetro maxconnection a un valor tan grande al que se llama al servidor web que se está sobrecargando con las conexiones HTTP. Después de cambiar el valor del parámetro maxconnection, realice pruebas de esfuerzo mediante el envío de solicitudes a cada servidor web de destino para determinar un valor para maxconnection que proporcionará un buen rendimiento y envíos HTTP sin sobrecargar los servidores web de destino.

El siguiente ejemplo muestra la configuración de la propiedad de número máximo de conexiones:

<configuration>
  <system.net>
    <connectionManagement>
      <add address="http://www.contoso.com" maxconnection="24" />
      <add address="*" maxconnection="48" />
    </connectionManagement>
  </system.net>
</configuration>

Al establecer la propiedad maxconnection, HTTP, HTTPS, la dirección IP del sitio web y el número de puerto se puede especificar. Otros ejemplos son:

<add address="http://www.contoso.com" maxconnection="24" />
<add address="http://www.contoso.com:8080" maxconnection="24" />
<add address="http://<IP-address>" maxconnection="24" />

Para obtener más información sobre el ajuste de IIS y la configuración de ASP.NET para servicios web, vea la sección "configuración de ASP.NET que puede afectar al rendimiento del adaptador HTTP" de Parámetros de configuración que afectan al rendimiento del adaptador (https://go.microsoft.com/fwlink/?LinkID=154200) en BizTalk Server ayuda de 2010.

Administrar ASP.NET uso de subprocesos o ejecutar simultáneamente solicitudes para aplicaciones web que pueden hospedar ubicaciones recibidas aisladas, servicios web back-end y servicios WCF

El número de subprocesos de trabajo y E/S (IIS 7.5 e IIS 7.0 en modo clásico) o el número de solicitudes que se ejecutan simultáneamente (modo integrado de IIS 7.5 y 7.0) para una aplicación web ASP.NET que hospeda ubicaciones recibidas aisladas, servicios web back-end y servicios WCF deben modificarse en las condiciones siguientes:

  • El uso de cpu no es un cuello de botella en el servidor web de hospedaje.

  • Valor de:

    • ASP.NET Apps v4.0.30319 \Request Wait Time o ASP.NET Apps v4.0.30319 \Request Execution Time performance counters is inusualmente high.

    • ASP.NET Apps v2.0.50727\Request Wait Time o ASP.NET Apps v2.0.50727\Request Execution Time performance counters is inusualmente high.

  • Se genera un error similar al siguiente en el registro de aplicación del equipo que hospeda la aplicación web.

    Event Type: Warning
Event Source: W3SVC Event Category: None
Event ID: 1013
Date: 11/4/2010
Time: 1:03:47 PM
User: N/A
Computer: <ComputerName>
Description: A process serving application pool 'DefaultAppPool' exceeded time limits during shut down. The process id was '<xxxx>'

Administrar ASP.NET uso de subprocesos para aplicaciones web que pueden hospedar ubicaciones recibidas aisladas, servicios web back-end y servicios WCF en IIS 7.5 e IIS 7.0 que se ejecutan en modo clásico

Cuando el valor autoConfig del archivo machine.config de un servidor IIS 7.5 e IIS 7.0 que se ejecuta en modo clásico se establece en true, ASP.NET 2.0 y ASP.NET 4 administra el número de subprocesos de trabajo y subprocesos de E/S asignados a cualquier proceso de trabajo de IIS asociado.

<processModel autoConfig="true" />

Para modificar manualmente el número de subprocesos de E/S y de trabajo para una aplicación web de ASP.NET 2.0 y ASP.Net 4, abra el archivo de machine.config asociado y, a continuación, escriba nuevos valores para los parámetros maxWorkerThreads y maxIoThreads .

<!-- <processModel autoConfig="true" /> -->
    <processModel maxWorkerThreads="200" maxIoThreads="200" />

Nota

Estos valores son solo para instrucciones; Asegúrese de probar los cambios en estos parámetros.

Para obtener más información sobre cómo ajustar parámetros en el archivo machine.config para una aplicación web de ASP.NET 2.0, consulte el artículo de Microsoft Knowledge Base 821268 Contención, rendimiento deficiente y interbloqueos al realizar solicitudes de servicio web desde aplicaciones de ASP.NET (https://go.microsoft.com/fwlink/?LinkID=144169).

Administrar el número de solicitudes que se ejecutan simultáneamente para aplicaciones web de ASP.NET 2.0 que pueden hospedar ubicaciones recibidas aisladas, servicios web back-end y servicios WCF en IIS 7.5 e IIS 7.0 que se ejecutan en modo integrado

Cuando ASP.NET 2.0 se hospeda en IIS 7.5 e IIS 7.0 en modo integrado, el uso de subprocesos se controla de forma diferente a en IIS 7.5 e IIS 7.0 en modo clásico. Cuando ASP.NET 2.0 se hospeda en IIS 7.5 e IIS 7.0 en modo integrado, ASP.NET 2.0 restringe el número de solicitudes que se ejecutan simultáneamente en lugar del número de subprocesos que ejecutan solicitudes simultáneamente. En escenarios sincrónicos, esto limitará indirectamente el número de subprocesos, pero en escenarios asincrónicos, es probable que el número de solicitudes y subprocesos sea muy diferente. Al ejecutar ASP.NET 2.0 en IIS 7.5 e IIS 7.0 en modo integrado, los parámetros maxWorkerThreads y maxIoThreads del archivo machine.config no se usan para controlar el número de subprocesos en ejecución. En su lugar, el número de solicitudes que se ejecutan simultáneamente se puede cambiar del valor predeterminado de 12 por CPU modificando el valor especificado para maxConcurrentRequestsPerCPU. El valor maxConcurrentRequestsPerCPU se puede especificar en el reqistry o en la sección config de un archivo aspnet.config. Siga estos pasos para cambiar el valor predeterminado de maxConcurrentRequestsPerCPU para controlar el número de solicitudes que se ejecutan simultáneamente:

Establezca el valor maxConcurrentRequestsPerCPU en el Registro.

Esta configuración es global y no se puede cambiar para grupos de aplicaciones individuales o aplicaciones.

Advertencia

Usa el Editor del Registro bajo tu propia responsabilidad. El uso incorrecto puede causar problemas que requieren que vuelva a instalar el sistema operativo. Para obtener más información sobre cómo realizar copias de seguridad, restaurar y modificar el registro, consulte el artículo de Microsoft Knowledge Base 256986: información del Registro de Windows para usuarios avanzados.

  1. En el menú Inicio , busque e inicie el símbolo del sistema Ejecutar , escriba regedit.exey, a continuación, seleccione Aceptar para iniciar el Editor del Registro.

  2. Vaya a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0

  3. Cree la clave siguiendo estos pasos:

    1. En el menú Editar , seleccione Nuevo y, a continuación, seleccione Clave.

    2. Escriba maxConcurrentRequestsPerCPU y presione ENTRAR.

    3. En la clave maxConcurrentRequestsPerCPU , cree una entrada DWORD con el nuevo valor de maxConcurrentRequestsPerCPU.

    4. Cierre el editor del registro.

Establezca el valor maxConcurrentRequestsPerCPU de un grupo de aplicaciones en la sección de configuración de un archivo aspnet.config

  1. Descargue e instale Microsoft .NET Framework 3.5 Service Pack 1, que es necesario para dar cabida a los valores siguientes en el archivo de configuración. La versión completa también está disponible.

  2. Abra el archivo aspnet.config para el grupo de aplicaciones.

  3. Escriba los nuevos valores para los parámetros maxConcurrentRequestsPerCPU y requestQueueLimit .

    <system.web>
    <applicationPool maxConcurrentRequestsPerCPU="12" requestQueueLimit="5000"/>
</system.web>

    Nota

    Este valor invalida el valor especificado para maxConcurrentRequestsPerCPU en el Registro. La configuración requestQueueLimit es la misma que processModel/requestQueueLimit, excepto la configuración del archivo aspnet.config invalidará la configuración en el archivo machine.config .

Para obtener más información sobre cómo configurar ASP.NET uso de subprocesos en IIS 7.0, consulte el blog de Thomas Marquardt sobre ASP.NET uso de subprocesos en IIS 7.0 (https://go.microsoft.com/fwlink/?LinkId=157518).

Administrar el número de solicitudes que se ejecutan simultáneamente para ASP.NET 4 aplicaciones web que pueden hospedar ubicaciones aisladas recibidas, servicios web back-end y servicios WCF en IIS 7.5 y 7.0 que se ejecutan en modo integrado

Con .NET Framework 4, la configuración predeterminada para maxConcurrentRequestsPerCPU es 5000, que es un número muy grande y, por lo tanto, permitirá que se ejecuten muchas solicitudes asincrónicas simultáneamente. Para obtener más información, vea <elemento applicationPool> (Configuración web) (https://go.microsoft.com/fwlink/?LinkID=205339).

Para el modo integrado de IIS 7.5 e IIS 7.0, un DWORD denominado MaxConcurrentRequestsPerCPU dentro de HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 determina el número de solicitudes simultáneas por CPU. De forma predeterminada, la clave del Registro no existe y el número de solicitudes por CPU se limita a 5000.

Establezca el valor maxConcurrentRequestsPerCPU en el Registro.

Esta configuración es global y no se puede cambiar para grupos de aplicaciones individuales o aplicaciones.

Advertencia

Usa el Editor del Registro bajo tu propia responsabilidad. El uso incorrecto puede causar problemas que requieren que vuelva a instalar el sistema operativo. Para obtener más información sobre cómo realizar copias de seguridad, restaurar y modificar el registro, consulte el artículo de Microsoft Knowledge Base 256986: información del Registro de Windows para usuarios avanzados.

  1. En el menú Inicio , busque e inicie el símbolo del sistema Ejecutar , escriba regedit.exey, a continuación, seleccione Aceptar para iniciar el Editor del Registro.

  2. Vaya a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0.

  3. Cree la clave siguiendo estos pasos:

    1. En el menú Editar , seleccione Nuevo y, a continuación, seleccione Clave.

    2. Escriba maxConcurrentRequestsPerCPU y presione ENTRAR.

    3. En la clave maxConcurrentRequestsPerCPU , cree una entrada DWORD con el nuevo valor de maxConcurrentRequestsPerCPU.

    4. Cierre el editor del registro.

Establezca el valor maxConcurrentRequestsPerCPU de un grupo de aplicaciones en la sección de configuración de un archivo aspnet.config

  1. Descargue e instale Microsoft .NET Framework 4, que es necesario para dar cabida a los valores siguientes en el archivo de configuración.

  2. Abra el archivo aspnet.config para el grupo de aplicaciones.

  3. Escriba nuevos valores para los parámetros maxConcurrentRequestsPerCPU y requestQueueLimit .

    Los valores del ejemplo siguiente son los valores predeterminados.

    <system.web>
    <applicationPool maxConcurrentRequestsPerCPU="5000" requestQueueLimit="5000"/>
</system.web>

    Nota

    Este valor invalida el valor especificado para maxConcurrentRequestsPerCPU en el Registro. La configuración requestQueueLimit es la misma que processModel/requestQueueLimit, excepto la configuración del archivo aspnet.config invalidará la configuración en el archivo machine.config .

Definición de valores de subproceso de hospedaje clR para instancias de host de BizTalk

Dado que un subproceso de Windows es la unidad más básica ejecutable disponible para un proceso de Windows, es importante asignar suficientes subprocesos al grupo de subprocesos .NET asociado a una instancia de host de BizTalk de para impedir la falta de subprocesos. Cuando se produce el colapso de subprocesos, no hay suficientes subprocesos disponibles para realizar el trabajo solicitado que afecta negativamente al rendimiento. Asimismo, se debe tener cuidado para evitar la asignación de más subprocesos en el grupo de subprocesos .NET asociado a un host que ya no es necesario. La asignación de demasiados subprocesos al grupo de subprocesos .NET asociado a un host puede aumentar el cambio de contexto. El cambio de contexto se produce cuando el kernel de Windows cambia de ejecutar un subproceso a otro, lo que supone un costo de rendimiento. La asignación excesiva de subprocesos puede provocar un cambio excesivo de contexto, lo que afectará negativamente al rendimiento general. El número predeterminado de subprocesos asignados a un grupo de subprocesos de .NET de una instancia de host de BizTalk depende de la versión de .NET Framework instalada. .NET Framework 4 y .NET Framework 3.5 SP1 aumentaron considerablemente los valores predeterminados, lo que puede provocar una asignación excesiva de subprocesos en los equipos de BizTalk Server y la contención excesiva de bloqueo en la base de datos de Cuadro de mensajes.

Con el panel de configuración de BizTalk, puede modificar el valor predeterminado del número de subprocesos de Windows disponibles en el grupo de subprocesos de .NET asociado a una instancia de un host de BizTalk. Para obtener más información sobre cómo modificar la configuración de .NET CLR, consulte Modificación de la configuración de .NET CLR (https://go.microsoft.com/fwlink/?LinkID=205344). La configuración de .NET CLR se realiza por CPU principal.

Nota

Los subprocesos de trabajo se usan para controlar los elementos de trabajo en cola y los subprocesos de E/S son subprocesos de devolución de llamada dedicados asociados a un puerto de finalización de E/S para controlar una solicitud de E/S asincrónica completada.

Configuración de subprocesos Valor predeterminado Valor recomendado
Máximo de subprocesos de E/S 250 250
Máximo de subprocesos de trabajo 25 100 Importante: Aumentar este valor más allá de 100 puede tener un efecto adverso en el rendimiento del equipo de SQL Server que hospeda la base de datos BizTalk Server Cuadro de mensajes. Cuando se produce este problema, el servidor SQL Server puede encontrar una condición de interbloqueo. Se recomienda no aumentar este parámetro más allá de un valor de 100.
Subprocesos de E/S mínimos 25 25
Subprocesos de trabajo mínimos 5 25

Nota

Los valores recomendados no son absolutos y es posible que deban ajustarse en función de la aplicación de BizTalk. Cambie un parámetro a la vez y, a continuación, mida el impacto en el rendimiento y la estabilidad de la plataforma de BizTalk antes de realizar cambios adicionales.

Nota

Estos valores se multiplican implícitamente por el número de procesadores del servidor. Por ejemplo, establecer la entrada MaxWorkerThreads en un valor de 100 establecería eficazmente un valor de 400 en un servidor de CPU 4.

Deshabilitación del seguimiento de nivel de grupo de BizTalk Server

El seguimiento incurre en una sobrecarga de rendimiento dentro de BizTalk Server, ya que los datos deben escribirse en la base de datos cuadro de mensajes y, a continuación, moverse de forma asincrónica a la base de datos de seguimiento de BizTalk. Las consideraciones siguientes se aplican al configurar el seguimiento en un entorno de BizTalk Server de producción:

  • Como regla general, si el seguimiento no es un requisito empresarial, deshabilite el seguimiento de nivel de grupo para reducir la sobrecarga y aumentar el rendimiento.

    Para deshabilitar BizTalk Server seguimiento de nivel de grupo, realice los pasos siguientes:

    1. En la consola de administración de BizTalk Server, expanda BizTalk Server Administración, haga clic con el botón derecho en Grupo de BizTalk y, a continuación, haga clic en Configuración.

    2. En el cuadro de diálogo Panel de configuración de BizTalk, en la página Grupo, desactive la casilla Habilitar seguimiento de nivel de grupo .

    3. Haga clic en Aceptar para aplicar las modificaciones y salir del panel de configuración.

  • Use solo el seguimiento del cuerpo del mensaje si es necesario. Según el rendimiento del mensaje y el tamaño del mensaje, el seguimiento del cuerpo del mensaje puede provocar una sobrecarga significativa. Aunque el seguimiento de la actividad de BizTalk tiene ventajas obvias para la depuración y la auditoría, también tiene implicaciones considerables de rendimiento y escalabilidad. Por lo tanto, solo debe realizar un seguimiento de los datos que sean estrictamente necesarios para la depuración y los motivos de seguridad, y evitar el seguimiento de la información redundante.

  • De forma predeterminada, las siguientes opciones de seguimiento están habilitadas para orquestaciones:

    • Inicio y finalización de la orquestación

    • Envío y recepción de mensajes

    • Inicio y fin de la forma

      La opción de seguimiento de orquestación "Inicio y finalización de formas" incurre en una sobrecarga significativa y no debe habilitarse en un entorno de producción en el que sea necesario un alto rendimiento. Las opciones de seguimiento de orquestación son accesibles en la consola de administración de BizTalk en la página Seguimiento del cuadro de diálogo Propiedades de orquestación.

    Para obtener más información sobre cómo configurar el seguimiento, vea Configuring Tracking Using the BizTalk Server Administration Console (https://go.microsoft.com/fwlink/?LinkId=158021).

Disminuir el período de purga del trabajo de purga y archivo de DTA de 7 a 2 días en escenarios de alto rendimiento

De forma predeterminada, el intervalo de purga de los datos de seguimiento en BizTalk Server se establece en 7 días. En un escenario de alto rendimiento, esto puede provocar una acumulación excesiva de datos en la base de datos de seguimiento, lo que finalmente afectará al rendimiento del cuadro de mensajes y, a su vez, afectará negativamente al rendimiento del procesamiento de mensajes.

En escenarios de alto rendimiento, reduzca el intervalo de purga dura y temporal del valor predeterminado de 7 días a 2 días. Para obtener más información sobre cómo configurar el intervalo de purga, vea How to Configure the DTA Purge and Archive Job (https://go.microsoft.com/fwlink/?LinkID=153814) en la Ayuda de BizTalk Server 2010.

Configurar la ruta de acceso %temp% de la cuenta de servicio de BizTalk para que apunte a un disco o LUN independiente

Esto debe hacerse porque BizTalk usa la ubicación temporal para transmitir archivos al disco al realizar operaciones de asignación complejas.

Instalación de los Service Pack más recientes

Se deben instalar los Service Packs más recientes para BizTalk Server y .NET Framework, ya que contienen correcciones que pueden corregir los problemas de rendimiento que puede encontrar.

Optimizaciones de rendimiento en la documentación de BizTalk Server

Aplique las siguientes recomendaciones de la documentación de BizTalk Server según corresponda:

Consulte también

Optimización del rendimiento de BizTalk Server