Compartir a través de

Optimizaciones generales para BizTalk Server: parte 2

  • Artículo

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

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

Se deben crear hosts independientes para la funcionalidad de envío, recepción, procesamiento y seguimiento. 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 en los servidores de BizTalk en un grupo de BizTalk. Varios hosts también permiten detener un host sin afectar a otros hosts. Por ejemplo, puede que quiera dejar de enviar mensajes para permitirles poner en cola en la base de datos cuadro de mensajes, al tiempo que permite que se produzca la recepción entrante de mensajes. La separación de instancias de host por funcionalidad también proporciona las siguientes ventajas:

  • Cada instancia de host tiene su propio conjunto de recursos, como memoria, identificadores y subprocesos en el grupo de subprocesos de .NET.

  • Varios hosts de BizTalk también reducirán la contención en las tablas de cola del host de base de datos de cuadro de mensajes porque a cada host se le asignan sus propias tablas de cola de trabajo en la base de datos cuadro de mensajes.

  • 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 permitiría, 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.

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 "Cómo modificar propiedades de host" en la ayuda de BizTalk Server en https://go.microsoft.com/fwlink/?LinkId=101588.

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 Seguimiento de BizTalk o BAM, ya que esto desviaría estos motores del trabajo principal de ejecución de procesos empresariales. En su lugar, BizTalk Server deja los mensajes en la base de datos cuadro de mensajes y los marca como que requieren un traslado a la base de datos de seguimiento de BizTalk. Un proceso en segundo plano (el host de seguimiento) mueve los mensajes a las bases de datos de Seguimiento de BizTalk 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 el seguimiento tiene en los hosts dedicados al procesamiento de mensajes.

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 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 cuadro de mensajes a la base de datos de seguimiento de BizTalk.

  • Los datos de seguimiento de BAM no se moverán de la base de datos cuadro de mensajes 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 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 del cuadro de mensajes. Si los datos no se mueven, esto hará que la base de datos de cuadro de mensajes se vuelva inflada, 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" en la ayuda de BizTalk Server en https://go.microsoft.com/fwlink/?LinkId=101589. Use la consola de administración de BizTalk Server para deshabilitar selectivamente los eventos de seguimiento.

    El host de seguimiento debe ejecutarse en al menos dos equipos que ejecutan BizTalk Server (para la redundancia en caso de que se produzca un error). 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 del 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 para bases de datos de cuadro de mensajes específicas, pero nunca habrá más de una instancia de host de seguimiento que mueva datos para una base de datos de cuadro de mensajes específica. Por ejemplo, si tiene tres bases de datos de cuadro de mensajes 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. Al agregar una tercera instancia de host de seguimiento, se 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 la ayuda de BizTalk Server:

  • "Administración del servicio de Bus de eventos de BAM" en https://go.microsoft.com/fwlink/?LinkId=101590.

  • "Creación de instancias del servicio de Bus de eventos de BAM" en https://go.microsoft.com/fwlink/?LinkId=101591.

Administrar ASP.NET uso de subprocesos o ejecutar simultáneamente solicitudes para aplicaciones web que hospedan orquestaciones publicadas como un servicio Web o WCF

El número de subprocesos de trabajo e E/S (IIS 6.0 e IIS 7.0 en modo clásico) o el número de solicitudes que se ejecutan simultáneamente (modo integrado de IIS 7.0) para una aplicación web de ASP.NET que hospeda una orquestación publicada como servicio web debe modificarse en las condiciones siguientes:

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

  • El valor de ASP.NET Apps v2.0.50727\Request Wait Time o ASP.NET Apps v2.0.50727\Request Execution Time performance counters es inusualmente alto.

  • Error similar al siguiente generado 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: 6/4/2009
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 hospedan orquestaciones en IIS 6.0 y en IIS 7.0 que se ejecutan en modo clásico

Cuando el valor autoConfig del archivo machine.config de un servidor IIS 6.0 o del servidor IIS 7.0 que se ejecuta en modo clásico se establece en true, ASP.NET 2.0 administra el número de subprocesos de trabajo y subprocesos de E/S que se asignan a los procesos de trabajo de IIS asociados:

<processModel autoConfig="true" />

Para modificar manualmente el número de subprocesos de trabajo e E/S de una aplicación web de ASP.NET 2.0, abra el archivo de machine.config asociado y 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 el ajuste de 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 ASP.NET aplicaciones" (https://go.microsoft.com/fwlink/?LinkID=66483).

Administrar el número de solicitudes que se ejecutan simultáneamente para las aplicaciones web que hospedan orquestaciones en IIS 7.0 que se ejecutan en modo integrado

Cuando ASP.NET 2.0 se hospeda en IIS 7.0 en modo integrado, el uso de subprocesos se controla de forma diferente a en IIS 6.0 o en IIS 7.0 en modo clásico. Cuando ASP.NET 2.0 se hospeda en 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 simultáneamente las solicitudes. 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.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 maxConcurrentThreadsPerCPU. El valor maxConcurrentThreadsPerCPU 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 maxConcurrentThreadsPerCPU para controlar el número de solicitudes que se ejecutan simultáneamente:

Establezca el valor maxConcurrentThreadsPerCPU 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 maxConcurrentThreadsPerCPU y presione ENTRAR.

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

    4. Cierre el editor del registro.

Establezca el valor maxConcurrentThreadsPerCPU 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 maxConcurrentThreadsPerCPU 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.

Modifique el número de subprocesos de Windows que están disponibles en el grupo de subprocesos .NET asociado al host de BizTalk al crear los valores CLR Hosting apropiados en el registro de BizTalk Server.

Advertencia

El uso incorrecto del Editor del Registro podría ocasionar problemas que hicieran necesaria una reinstalación del sistema operativo. Use el Editor del Registro bajo su propia responsabilidad. Para obtener más información sobre cómo realizar copias de seguridad, restaurar y modificar el registro, vea el artículo de Microsoft Knowledge Base "Descripción del Registro de Microsoft Windows" en https://go.microsoft.com/fwlink/?LinkId=62729.

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.

Para modificar el número de subprocesos disponibles en el grupo de subprocesos de .NET asociado a cada instancia de un host de BizTalk, siga estos pasos:

  1. Detenga la instancia de host de BizTalk.

  2. Haga clic en Inicio, haga clic en Ejecutar, escriba regedit.exey, a continuación, haga clic en Aceptar para iniciar el Editor del Registro. Vaya a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$hostname donde hostname es el nombre del host asociado a la instancia de host.

    Nota

    Si ha actualizado la instalación de BizTalk Server 2006 desde BizTalk Server 2004, esta clave del Registro se puede representar como HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvcguid donde guid es un GUID único para cada instancia de un host de BizTalk Server.

  3. Busque la clave de hospedaje clR . Si esta clave no existe, cree la clave siguiendo estos pasos:

    1. En el menú Edición, haga clic en Nuevo y, después, en Clave.

    2. Escriba CLR Hosting y presione ENTRAR.

  4. En la clave de hospedaje CLR , cree las siguientes entradas DWORD con los valores indicados.

    Entrada DWORD Valor predeterminado Valor recomendado
    MaxIOThreads 20 100
    MaxWorkerThreads 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 de cuadro de mensajes de BizTalk Server. Cuando se produce este problema, el servidor SQL Server puede encontrar una condición de interbloqueo. Se recomienda que este parámetro no aumente más allá de un valor de 100.
    MinIOThreads 1 25
    MinWorkerThreads 1 25

    Nota

    Estos valores recomendados serán suficientes para la mayoría de los escenarios, pero es posible que deban aumentarse en función del número de controladores o orquestaciones del adaptador que se ejecutan en cada instancia de host.

    Nota

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

  5. Cierre el Editor del Registro.

  6. Reinicie la instancia de host de BizTalk.

Deshabilitar el seguimiento de orquestaciones, puertos de envío, puertos de recepción y canalizaciones cuando no es necesario realizar el seguimiento

El seguimiento incurre en una sobrecarga de rendimiento dentro de BizTalk Server, ya que los datos se deben escribir en la base de datos de cuadro de mensajes y, a continuación, mover de forma asincrónica a la base de datos de seguimiento de BizTalk. Si el seguimiento no es un requisito empresarial, deshabilite el seguimiento para reducir la sobrecarga y aumentar el rendimiento. Para obtener más información sobre cómo configurar el seguimiento, vea "Configuring Tracking Using the BizTalk Server Administration Console" (Configuración del seguimiento mediante la consola de administración de BizTalk Server) en la ayuda de BizTalk Server en https://go.microsoft.com/fwlink/?LinkID=106742.

Reducir 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 dar lugar a 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" (Cómo configurar el trabajo de purga y archivo de DTA) en la ayuda de BizTalk Server en https://go.microsoft.com/fwlink/?LinkID=104908.

Instalación de los Service Pack más recientes

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

No agrupar hosts de BizTalk a menos que sea absolutamente necesario

Aunque BizTalk Server 2006 y versiones posteriores de BizTalk Server le permiten 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, pueden equilibrarse internamente la carga entre las máquinas y no se benefician de la agrupación en clústeres.

Optimizaciones de rendimiento en la documentación de BizTalk Server

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