Optimización del rendimiento del adaptador de WCF de BizTalk Server
En este tema se proporcionan recomendaciones para seleccionar el tipo de enlace o el adaptador WCF adecuado y las instrucciones para aplicar diversas opciones de configuración del adaptador wcF.
Consideraciones al elegir qué adaptador de WCF usar o qué tipo de enlace WCF-Custom/WCF-CustomIsolated usar
No use la seguridad de nivel de mensaje si no es estrictamente necesaria porque aumenta el tamaño de los mensajes. Esto a su vez puede minimizar el rendimiento general de la solución.
Al elegir qué adaptador de WCF usar o qué tipo de enlace WCF-Custom/WCF-CustomIsolated usar, tenga en cuenta cuidadosamente los requisitos de la aplicación, como compatibilidad, rendimiento, plataforma de hospedaje, seguridad y transportes admitidos. Las directrices que se enumeran a continuación son aplicables a WCF en general y no son específicas de BizTalk Server:
BasicHttpBinding debe usarse si el servicio WCF necesita admitir clientes heredados, como servicios web de WebSphere o aplicaciones de .NET 1.1 que esperan un servicio web ASMX. Dado que BasicHttpBinding no implementa ninguna seguridad de forma predeterminada, si necesita seguridad de transporte o mensaje, debe configurarla explícitamente en este enlace. Use BasicHttpBinding para exponer puntos de conexión que pueden comunicarse con clientes y servicios web basados en ASMX y otros servicios que cumplan con el perfil básico de WS-I 1.1. Al configurar la seguridad de transporte, BasicHttpBinding no usa credenciales como un servicio web ASMX clásico. BasicHttpBinding permite hospedar el servicio WCF en IIS 7.5 o IIS 7.0.
WsHttpBinding debe usarse si los clientes WCF llamarán al servicio WCF a través de Internet. WsHttpBinding es una buena opción para escenarios de Internet en los que no es necesario admitir clientes heredados que esperan un servicio web ASMX y WsHttpBinding le permite hospedar el servicio WCF en IIS 7.5 o IIS 7.0. Si necesita admitir clientes heredados, considere la posibilidad de usar BasicHttpBinding en su lugar. WsHttpBinding debe usarse cuando necesite exponer ubicaciones de recepción de WCF o adoptar puertos de envío que admitan protocolos WS-* como WS-Security o WS-AtomicTransactions.
NetTcpBinding es una opción excelente si necesita admitir clientes dentro de la intranet. NetTcpBinding es una buena opción para escenarios de intranet si el rendimiento del transporte es importante para usted y si es aceptable hospedar el servicio en un servicio de Windows en lugar de en IIS. Use este enlace cuando desee proporcionar un entorno de enlace seguro y confiable para la comunicación entre máquinas .NET-to-.NET. Tenga en cuenta que NetTcpBinding debe hospedarse en un servicio de Windows o en IIS 7.5/7.0.
NetNamedPipeBinding debe usarse si necesita admitir clientes WCF en el mismo equipo que el servicio. Este enlace proporciona un entorno de enlace seguro y confiable para la comunicación entre procesos y el mismo equipo. Use este enlace cuando desee usar el protocolo NamedPipe. Tenga en cuenta que NetNamedPipeBinding debe hospedarse en un servicio de Windows o en IIS 7.5/7.0.
NetMsmqBinding debe usarse si necesita admitir la puesta en cola desconectada. La puesta en cola se proporciona mediante Message Queuing (también conocido como MSMQ) como transporte, lo que permite la compatibilidad con operaciones desconectadas, aislamiento de errores y nivelación de carga. Puede usar NetMsmqBinding cuando el cliente y el servicio no tienen que estar en línea al mismo tiempo. También puede administrar cualquier número de mensajes entrantes mediante la ordenación de la carga. Message Queuing admite el aislamiento de errores, donde los mensajes pueden producir errores sin afectar al procesamiento de otros mensajes. Tenga en cuenta que NetMsmqBinding debe hospedarse en un servicio de Windows o en IIS 7.5/7.0.
WsDualHttpBinding debe usarse si necesita admitir un servicio dúplex. Un servicio dúplex es un servicio que usa patrones de mensajes dúplex, lo que proporciona la capacidad de que un servicio se comunique con el cliente a través de una devolución de llamada. Tenga en cuenta que WsDualHttpBinding debe hospedarse en un servicio de Windows o en IIS 7.5/7.0.
Comparación de enlaces WCF
Los enlaces proporcionan un mecanismo para configurar pilas de canales. Un enlace crea un proceso para crear una pila de canales mediante un canal de transporte, un codificador de mensajes y un conjunto de canales de protocolo. Windows Communication Foundation incluye numerosos enlaces integrados que vienen preconfigurados para abordar los escenarios de comunicación más comunes.
| Nombre de clase de enlace | Transporte | Codificación de mensajes | Modo de seguridad | Mensajería de confianza | Flujo de transacción (deshabilitado de forma predeterminada) |
|---|---|---|---|---|---|
| BasicHttpBinding | HTTP | Texto | None | No compatible | No compatible |
| WSHttpBinding | HTTP | Texto | Message | Disabled | WS-AtomicTransactions |
| NetTcpBinding | TCP | Binary | Transporte | Disabled | OleTransactions |
| NetNamedPipesBinding | Canalizaciones con nombre | Binary | Transporte | No compatible | OleTransactions |
| NetMsmqBinding | MSMQ | Binary | Message | No compatible | No compatible |
| CustomBinding | Decide | Decide | Decide | Decide | Decide |
Puede seleccionar un enlace determinado en función de sus necesidades de comunicación. Por ejemplo:
BasicHttpBinding está diseñado para la interoperabilidad con servicios web simples. BasicHttpBinding usa HTTP para el transporte y el texto de la codificación del mensaje.
WSHttpBinding está diseñado para la interoperabilidad con servicios web más avanzados que podrían aprovechar diferentes protocolos WS-*. WSHttpBinding también usa HTTP para el transporte y el texto de la codificación del mensaje.
NetTcpBinding y NetNamedPipeBinding están diseñados para una comunicación eficaz y eficaz con otras aplicaciones wcF entre máquinas o en la misma máquina, respectivamente.
Si necesita la máxima flexibilidad mediante uno o varios canales de protocolo personalizados en tiempo de ejecución, puede usar CustomBinding que le ofrece la posibilidad de decidir qué elementos de enlace componen el enlace.
Nota
Los enlaces tienen características diferentes en términos de tiempo de respuesta y rendimiento. Por lo tanto, el consejo general para aumentar el rendimiento es usar NetTcpBindind y NetNamesPipeBinding siempre que sea posible.
Use la codificación de mensajes binarios y de transporte TCP para maximizar el rendimiento del adaptador wcF y minimizar la latencia del adaptador WCF.
Use el adaptador de WCF-NetTcp cuando sea posible para maximizar el rendimiento. El adaptador de WCF-NetTcp usa el protocolo de transporte TCP/IP y la codificación de mensajes binarios que proporcionan un rendimiento mejorado en comparación con otros adaptadores WCF-*.
Como alternativa, puede configurar el WCF-Custom (o WCF-CustomIsolated adaptador para ubicaciones de recepción) con un tipo de enlace customBinding . A continuación, agregue la extensión de enlace binaryMessageEncoding para implementar la codificación de mensajes binarios y la extensión de enlace tcpTransport para implementar TCP/IP como protocolo de transporte de mensajes. Este enfoque es muy flexible porque permite seleccionar y configurar solo los elementos de enlace que necesita y crear canales personalizados para ampliar el comportamiento predeterminado del motor de mensajería de BizTalk. Si implementa el adaptador de WCF-Custom con el tipo de enlace customBinding , especifique estos valores para los parámetros de configuración de la extensión de enlace para maximizar el rendimiento y minimizar la latencia.
Valores de configuración de puerto de envío:
| Configuración | Valor predeterminado | Valor recomendado |
|---|---|---|
| TcpTransportBindingElement.ConnectionPoolSettings.maxOutboundConnectionsPerEndpoint : obtiene o establece el número máximo de conexiones salientes para cada punto de conexión almacenado en caché en el grupo de conexiones. Esto limita el número de conexiones almacenadas en memoria caché para cada punto de conexión remoto único. Si este valor se supera al tener más conexiones de cliente activas, el servicio puede aparecer sin responder al cliente y este valor debe ajustarse para dar cabida al número máximo de conexiones esperadas almacenadas en caché para cada punto de conexión remoto único. Para obtener más información sobre esta propiedad, vea TcpConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint (https://go.microsoft.com/fwlink/?LinkId=157737) en MSDN. | 10 | Try >= 20 |
Valores de configuración de puerto de recepción:
| Configuración | Valor predeterminado para .NET Framework 4 | Valor recomendado para .NET Framework 4 | Valor predeterminado para .NET Framework 3.5 | Valor recomendado para .NET Framework 3.5 |
|---|---|---|---|---|
| TcpTransportBindingElement.MaxPendingAccepts : obtiene o establece el número máximo de operaciones de aceptación asincrónicas pendientes que están disponibles para procesar las conexiones entrantes al servicio. En escenarios con altos niveles de iniciaciones de conexión simultáneas, este valor puede ser inadecuado y debe ajustarse junto con la propiedad MaxPendingConnections para controlar niveles superiores de intentos de conexión de cliente simultáneos. No debería ser necesario establecer esta propiedad en un valor mayor que el número de procesadores presentes en el equipo que hospeda el servicio. Para obtener más información sobre esta propiedad, vea Propiedad ConnectionOrientedTransportBindingElement.MaxPendingAccepts (https://go.microsoft.com/fwlink/?LinkId=157738) en MSDN. | 1 | 2*ProcessorCount | 1 | Try >= 20 |
| TcpTransportBindingElement.MaxPendingConnections : obtiene o establece el número máximo de conexiones que esperan el envío en el servicio. Esta propiedad limita el número de conexiones de cliente simultáneas pendientes de distribución. Si este valor es demasiado bajo, el servicio puede rechazar los intentos de la conexión de cliente. Si es demasiado alto, el servicio puede parecer lento o sin respuesta a los clientes durante los períodos de carga pesados. Esta propiedad debería estar establecida en un valor que permita al servicio ejecutarse a plena capacidad y no más alto. Cuando una capa superior de la pila llama a AcceptDispatch, esa conexión se quita de la cola de conexiones en espera de envío. Para obtener más información sobre esta propiedad, vea Propiedad ConnectionOrientedTransportBindingElement.MaxPendingConnections (https://go.microsoft.com/fwlink/?LinkId=157735) en MSDN. | 10 | 16*ProcessorCount | 10 | Try >= 20 |
| TcpTransportBindingElement.ListenBacklog : obtiene o establece el número máximo de solicitudes de conexión en cola que pueden estar pendientes. ListenBacklog es una propiedad de nivel de socket que describe el número de solicitudes de "aceptación pendiente" que se van a poner en cola. Asegúrese de que el número máximo de conexiones simultáneas no supera la cola del socket subyacente. Para obtener más información sobre esta propiedad, vea Propiedad TcpTransportBindingElement.ListenBacklog (https://go.microsoft.com/fwlink/?LinkId=157734) en MSDN. | 10 | 16*ProcessorCount | 10 | Try >= 20 |
Agregue el comportamiento del servicio ServiceThrottlingBehavior a un WCF-Custom o WCF-CustomIsolated Ubicación de recepción y use la siguiente configuración:
Nota
Antes de que se puedan modificar los elementos del comportamiento del servicio ServiceThrottlingBehavior, primero debe agregar la extensión de comportamiento serviceThrottling a la pestaña Comportamientos del cuadro de diálogo Propiedades de transporte WCF-Custom* . Para agregar serviceThrottling a la lista de comportamientos, seleccione la pestaña Comportamientos del cuadro de diálogo Propiedades de transporte WCF-Custom* , haga clic con el botón derecho en ServiceBehavior en Comportamiento, haga clic en Agregar extensión, seleccione serviceThrottlingy, a continuación, haga clic en Aceptar. A continuación, haga clic para seleccionar las propiedades disponibles en ServiceThrottlingElement y cambie el valor de las propiedades según sea necesario.
| Configuración | Valor predeterminado para .NET Framework 4 | Valor recomendado para .NET Framework 4 | Valor predeterminado para .NET Framework 3.5 | Valor recomendado para .Net Framework 3.5 |
|---|---|---|---|---|
| ServiceThrottlingBehavior.MaxConcurrentCalls : obtiene o establece un valor que especifica el número máximo de mensajes que se procesan activamente en un ServiceHost. La propiedad MaxConcurrentCalls especifica el número máximo de mensajes que se procesan activamente en un objeto ServiceHost . Cada canal puede tener un mensaje pendiente que no cuente con el valor de MaxConcurrentCalls hasta que WCF comience a procesarlo. Para obtener más información sobre esta propiedad, vea ServiceThrottlingBehavior.MaxConcurrentCalls (https://go.microsoft.com/fwlink/?LinkId=157838) en MSDN. El valor predeterminado para el WCF-Custom de BizTalk y WCF-CustomIsolated la propiedad MaxConcurrentCalls es de 16 por CPU. Nota: BizTalk Server adaptadores de recepción de WCF distintos del WCF-Custom y WCF-CustomIsolated adaptador exponen una propiedad Llamadas simultáneas máximas en la pestaña Enlace del cuadro de diálogo Propiedades de transporte WCF-* para configurar este comportamiento. El valor predeterminado del comportamiento máximo de llamadas simultáneas es 200. | 16*ProcessorCount | 16*ProcessorCount | - 16 para el WCF-Custom de BizTalk y WCF-CustomIsolated adaptadores de recepción. - 200 para los otros adaptadores de recepción WCF. |
- Pruebe >= 200 para el WCF-Custom y WCF-CustomIsolated adaptadores de recepción. - Pruebe > 200 para la propiedad Maximum Concurrent Calls (Número máximo de llamadas simultáneas) en la pestaña Enlace del cuadro de diálogo Propiedades de transporte WCF-* para BizTalk Server adaptadores de recepción de WCF distintos del adaptador de WCF-Custom y WCF-CustomIsolated. |
| ServiceThrottlingBehavior.maxConcurrentInstances : obtiene o establece un valor que especifica el número máximo de objetos InstanceContext en el servicio que se pueden ejecutar a la vez. La propiedad MaxConcurrentInstances especifica el número máximo de objetos InstanceContext en el servicio. Es importante tener en cuenta la relación entre la propiedad MaxConcurrentInstances y la propiedad InstanceContextMode . Si InstanceContextMode es PerSession, el valor resultante es el número total de sesiones. Si InstanceContextMode es PerCall, el valor resultante es el número de llamadas simultáneas. Si un mensaje llega mientras ya existe el número máximo de objetos InstanceContext , el mensaje se mantiene hasta que se cierra un objeto InstanceContext . Para obtener más información sobre esta propiedad, vea Propiedad ServiceThrottlingBehavior.MaxConcurrentInstances (https://go.microsoft.com/fwlink/?LinkId=157897) en MSDN. El valor predeterminado de la propiedad WCF-Custom y WCF-CustomIsolated adaptador de recepción MaxConcurrentInstances es de 116 por CPU. Nota: Dado que las ubicaciones de recepción de WCF se implementan como instancias de la clase BizTalkServiceInstance contenida en el ensamblado Microsoft.BizTalk.Adapter.Wcf.Runtime.dll y, dado que esta clase está marcada como ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple). todas las solicitudes entrantes se administran mediante el mismo objeto singleton y se omite este parámetro. Por lo tanto, establecer la propiedad maxConcurrentInstances en determinadas ubicaciones de recepción de WCF-Custom no tiene ningún efecto, ya que el número de instancias activas siempre es igual a 1. | 116*ProcessorCount | 116*ProcessorCount | 26 | Try >= 200 |
| ServiceThrottlingBehavior.MaxConcurrentSessions : la propiedad MaxConcurrentSessions obtiene o establece el número máximo de sesiones que un objeto ServiceHost puede aceptar al mismo tiempo. Es importante comprender que las sesiones en este caso no se limitan solo a los canales que admiten sesiones confiables. Cada objeto de agente de escucha puede tener una sesión de canal pendiente que no cuente con el valor de MaxConcurrentSessions hasta que WCF acepte la sesión del canal y comience a procesar los mensajes de sesión del canal. Esta propiedad resulta muy útil en situaciones que utilizan sesiones. Cuando esta propiedad está establecida con un valor menor que el número de subprocesos del cliente, las solicitudes de varios clientes se pueden poner en la cola en la misma conexión de socket. Se bloquearán las solicitudes del cliente que no ha creado una sesión con el servicio. Permanecerán bloqueados hasta que el servicio cierre su sesión con los demás clientes, si el número de sesiones abiertas en el servicio ha alcanzado el valor especificado para MaxConcurrentSessions. A continuación, se agota el tiempo de espera de las solicitudes de cliente que no se sirven y el servicio cierra la sesión. Para evitar esta situación, considere la posibilidad de ejecutar los subprocesos de cliente de diferentes dominios de aplicación para que las conexiones de socket diferentes acepten los mensajes de solicitud. Para obtener más información sobre esta propiedad, vea Propiedad ServiceThrottlingBehavior.MaxConcurrentSessions (https://go.microsoft.com/fwlink/?LinkId=157864) en MSDN. | 100*ProcessorCount | 100*ProcessorCount | 10 | Try >= 200 |
Al modificar las opciones de configuración de puerto, se aplican los cambios métodos; modifique cada parámetro individualmente y, pruebe los efectos del cambio en el rendimiento y la estabilidad general. Como siempre, el valor adecuado que se va a aplicar depende del escenario concreto: si se establece un valor demasiado bajo, se puede reducir la escalabilidad; mientras que si un valor se establece demasiado alto, el requisito de aplicación puede superar la capacidad de los recursos físicos en el equipo. Además, dado que estas propiedades están relacionadas, deben establecerse de forma coherente y coherente. Para obtener más información sobre el uso de ServiceThrottlingBehavior para controlar el rendimiento del servicio WCF, vea Using ServiceThrottlingBehavior to Control WCF Service Performance (https://go.microsoft.com/fwlink/?LinkId=157908) en MSDN.