Optimisation des performances de l’adaptateur WCF de BizTalk Server
Cette rubrique fournit des recommandations pour sélectionner l’adaptateur WCF ou le type de liaison approprié, ainsi que des conseils pour l’application de différentes options de configuration de l’adaptateur WCF.
Considérations lors du choix de l’adaptateur WCF à utiliser ou du type de liaison WCF-Custom/WCF-CustomIsolated à utiliser
N’utilisez pas la sécurité au niveau du message si cela n’est pas strictement nécessaire, car cela augmente la taille des messages. Cela peut à son tour réduire le débit global de la solution.
Lorsque vous choisissez l’adaptateur WCF à utiliser ou le type de liaison WCF-Custom/WCF-CustomIs isolé à utiliser, examinez soigneusement les exigences d’application telles que la compatibilité, les performances, la plateforme d’hébergement, la sécurité et les transports pris en charge. Les instructions ci-dessous s’appliquent à WCF en général et ne sont pas spécifiques à BizTalk Server :
BasicHttpBinding doit être utilisé si le service WCF doit prendre en charge des clients hérités tels que les services WebSphere ou les applications .NET 1.1 qui attendent un service Web ASMX. Comme BasicHttpBinding n’implémente aucune sécurité par défaut, si vous avez besoin d’une sécurité de message ou de transport, vous devez le configurer explicitement sur cette liaison. Utilisez BasicHttpBinding pour exposer des points de terminaison capables de communiquer avec les clients et les services web basés sur ASMX et d’autres services conformes au profil de base WS-I 1.1. Lors de la configuration de la sécurité du transport, BasicHttpBinding n’utilise par défaut aucune information d’identification comme un service web ASMX classique. BasicHttpBinding vous permet d’héberger le service WCF dans IIS 7.5 ou IIS 7.0.
WsHttpBinding doit être utilisé si le service WCF est appelé par les clients WCF via Internet. WsHttpBinding est un bon choix pour les scénarios Internet dans lesquels vous n’avez pas besoin de prendre en charge les clients hérités qui attendent un service web ASMX et WsHttpBinding vous permet d’héberger le service WCF dans IIS 7.5 ou IIS 7.0. Si vous avez besoin de prendre en charge les clients hérités, envisagez d’utiliser BasicHttpBinding à la place. WsHttpBinding doit être utilisé lorsque vous devez exposer des emplacements de réception WCF ou adopter des ports d’envoi qui prennent en charge les protocoles WS-* tels que WS-Security ou WS-AtomicTransactions.
NetTcpBinding est un excellent choix si vous avez besoin de prendre en charge les clients au sein de votre intranet. NetTcpBinding est un bon choix pour les scénarios intranet si les performances de transport sont importantes pour vous et s’il est acceptable d’héberger le service dans un service Windows plutôt que dans IIS. Utilisez cette liaison lorsque vous souhaitez fournir un environnement de liaison sécurisé et fiable pour la communication entre ordinateurs .NET-to-.NET. Notez que NetTcpBinding doit être hébergé dans un service Windows ou dans IIS 7.5/7.0.
NetNamedPipeBinding doit être utilisé si vous devez prendre en charge les clients WCF sur le même ordinateur que votre service. Cette liaison fournit un environnement de liaison sécurisé et fiable pour la communication inter-processus sur un même ordinateur. Utilisez cette liaison lorsque vous souhaitez utiliser le protocole NamedPipe. Notez que netNamedPipeBinding doit être hébergé dans un service Windows ou dans IIS 7.5/7.0.
NetMsmqBinding doit être utilisé si vous devez prendre en charge la mise en file d’attente déconnectée. La mise en file d’attente est fournie en utilisant Message Queuing (également appelé MSMQ) comme transport, ce qui permet de prendre en charge les opérations déconnectées, l’isolation des défaillances et le nivellement de charge. Vous pouvez utiliser NetMsmqBinding lorsque le client et le service n’ont pas besoin d’être en ligne en même temps. Vous pouvez également gérer n’importe quel nombre de messages entrants à l’aide du nivellement de charge. Message Queuing prend en charge l’isolation des échecs, où les messages peuvent échouer sans affecter le traitement d’autres messages. Notez que netMsmqBinding doit être hébergé dans un service Windows ou dans IIS 7.5/7.0.
WsDualHttpBinding doit être utilisé si vous devez prendre en charge un service duplex. Un service duplex est un service qui utilise des modèles de message duplex, ce qui permet à un service de communiquer avec le client via un rappel. Notez que WsDualHttpBinding doit être hébergé dans un service Windows ou dans IIS 7.5/7.0.
Comparaison de liaison WCF
Les liaisons fournissent un mécanisme de configuration des piles de canaux. Une liaison crée un processus pour créer une pile de canaux à l’aide d’un canal de transport, d’un encodeur de message et d’un ensemble de canaux de protocole. Windows Communication Foundation est fourni avec de nombreuses liaisons intégrées qui sont préconfigurées pour répondre aux scénarios de communication les plus courants.
| Nom de classe de liaison | Transport | Encodage de message | Mode de sécurité | Messagerie fiable | Flux de transaction (désactivé par défaut) |
|---|---|---|---|---|---|
| BasicHttpBinding | HTTP | Texte | Aucun | Non prise en charge | Non prise en charge |
| WSHttpBinding | HTTP | Texte | Message | Désactivé | WS-AtomicTransactions |
| NetTcpBinding | TCP | Binary | Transport | Désactivé | OleTransactions |
| NetNamedPipesBinding | Canaux nommés | Binary | Transport | Non prise en charge | OleTransactions |
| NetMsmqBinding | MSMQ | Binary | Message | Non prise en charge | Non prise en charge |
| CustomBinding | Vous décidez | Vous décidez | Vous décidez | Vous décidez | Vous décidez |
Vous pouvez sélectionner une liaison particulière en fonction de vos besoins de communication. Par exemple :
BasicHttpBinding est conçu pour l’interopérabilité avec des services Web simples. BasicHttpBinding utilise HTTP pour le transport et le texte pour l’encodage du message.
WSHttpBinding est conçu pour l’interopérabilité avec des services Web plus avancés qui peuvent tirer parti de différents protocoles WS-*. WSHttpBinding utilise également HTTP pour le transport et le texte pour l’encodage du message.
NetTcpBinding et NetNamedPipeBinding sont conçus pour une communication efficace et efficace avec d’autres applications WCF sur les machines ou sur le même ordinateur.
Si vous avez besoin d’une flexibilité maximale en utilisant un ou plusieurs canaux de protocole personnalisés au moment de l’exécution, vous pouvez utiliser customBinding qui vous donne la possibilité de décider quels éléments de liaison composent votre liaison.
Notes
Les liaisons ont des caractéristiques différentes en termes de temps de réponse et de débit. Par conséquent, les conseils généraux pour augmenter les performances sont d’utiliser NetTcpBindind et NetNamesPipeBinding lorsque cela est possible.
Utiliser le transport TCP et l’encodage des messages binaires pour optimiser le débit de l’adaptateur WCF et réduire la latence de l’adaptateur WCF
Utilisez l’adaptateur WCF-NetTcp lorsque cela est possible pour optimiser le débit. L’adaptateur WCF-NetTcp utilise le protocole de transport TCP/IP et l’encodage de messages binaires qui fournissent ensemble des performances améliorées par rapport aux autres cartes WCF-*.
Vous pouvez également configurer le WCF-Custom (ou l’adaptateur WCF-CustomIsolated pour les emplacements de réception) avec un type de liaison customBinding . Ensuite, ajoutez l’extension de liaison binaryMessageEncoding pour implémenter l’encodage de message binaire et l’extension de liaison tcpTransport pour implémenter TCP/IP comme protocole de transport de messages. Cette approche est très flexible, car elle vous permet de sélectionner et de configurer uniquement les éléments de liaison dont vous avez besoin et de créer des canaux personnalisés pour étendre le comportement par défaut du moteur de messagerie BizTalk. Si vous implémentez l’adaptateur WCF-Custom avec le type de liaison customBinding , spécifiez ces valeurs pour les paramètres configuration de l’extension de liaison afin d’optimiser le débit et de réduire la latence.
Valeurs de configuration de port d’envoi :
| Paramètre | Valeur par défaut | Valeur recommandée |
|---|---|---|
| TcpTransportBindingElement.ConnectionPoolSettings.maxOutboundConnectionsPerEndpoint : obtient ou définit le nombre maximal de connexions sortantes pour chaque point de terminaison mis en cache dans le pool de connexions. Cela limite le nombre de connexions qui sont mises en cache pour chaque point de terminaison distant unique. Si cette valeur est dépassée par des connexions client plus actives, le service peut sembler ne pas répondre au client, et cette valeur doit être ajustée pour prendre en charge le nombre maximal de connexions attendues mises en cache pour chaque point de terminaison distant unique. Pour plus d’informations sur cette propriété, consultez TcpConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint, propriété (https://go.microsoft.com/fwlink/?LinkId=157737) sur MSDN. | 10 | Essayer >= 20 |
Valeurs de configuration du port de réception :
| Paramètre | Valeur par défaut pour .NET Framework 4 | Valeur recommandée pour .NET Framework 4 | Valeur par défaut pour .NET Framework 3.5 | Valeur recommandée pour .NET Framework 3.5 |
|---|---|---|---|---|
| TcpTransportBindingElement.MaxPendingAccepts : obtient ou définit le nombre maximal d’opérations d’acceptation asynchrones en attente disponibles pour le traitement des connexions entrantes au service. Pour les scénarios avec des niveaux élevés d’initiations de connexion simultanée, cette valeur peut être inadéquate et doit être ajustée avec la propriété MaxPendingConnections pour gérer des niveaux plus élevés de tentatives de connexion client simultanées. Il ne doit pas être nécessaire d'affecter à cette propriété une valeur supérieure au nombre de processeurs présents dans l'ordinateur hébergeant le service. Pour plus d’informations sur cette propriété, consultez ConnectionOrientedTransportBindingElement.MaxPendingAccepts, propriété (https://go.microsoft.com/fwlink/?LinkId=157738) sur MSDN. | 1 | 2*ProcessorCount | 1 | Essayer >= 20 |
| TcpTransportBindingElement.MaxPendingConnections : obtient ou définit le nombre maximal de connexions en attente de répartition sur le service. Ceci limite le nombre de connexions simultanées de clients en attente de distribution. Si cette valeur est trop basse, les tentatives de connexions de clients peuvent être rejetées par le service. Si elle est trop élevée, le service peut apparaître lent ou insensible aux clients pendant les périodes de grande sollicitation. Cette propriété doit avoir une valeur qui permet au service de s'exécuter à pleine capacité, et pas au-delà. Lorsqu’une couche supérieure de la pile appelle AcceptDispatch, cette connexion est supprimée de la file d’attente des connexions en attente de distribution. Pour plus d’informations sur cette propriété, consultez ConnectionOrientedTransportBindingElement.MaxPendingConnections, propriété (https://go.microsoft.com/fwlink/?LinkId=157735) sur MSDN. | 10 | 16*ProcessorCount | 10 | Essayer >= 20 |
| TcpTransportBindingElement.ListenBacklog : obtient ou définit le nombre maximal de demandes de connexion mises en file d’attente qui peuvent être en attente. ListenBacklog est une propriété au niveau du socket qui décrit le nombre de demandes « en attente d’acceptation » à mettre en file d’attente. Assurez-vous que la file d'attente sous-jacente du socket n'est pas dépassée par le nombre maximal de connexions simultanées. Pour plus d’informations sur cette propriété, consultez TcpTransportBindingElement.ListenBacklog, propriété (https://go.microsoft.com/fwlink/?LinkId=157734) sur MSDN. | 10 | 16*ProcessorCount | 10 | Essayer >= 20 |
Ajoutez le comportement du service ServiceThrottlingBehavior à un emplacement de réception WCF-Custom ou WCF-CustomIsolated et utilisez les paramètres suivants :
Notes
Avant de modifier des éléments du comportement du service ServiceThrottlingBehavior, vous devez d’abord ajouter l’extension de comportement serviceThrottling à l’onglet Comportements de la boîte de dialogue Propriétés de transport WCF-Custom* . Pour ajouter serviceThrottling à la liste des comportements, sélectionnez l’onglet Comportements de la boîte de dialogue Propriétés de transport WCF-Custom* , cliquez avec le bouton droit sur ServiceBehavior sous Comportement, cliquez sur Ajouter une extension, sélectionnez serviceThrottling, puis cliquez sur OK. Cliquez ensuite pour sélectionner les propriétés disponibles sous ServiceThrottlingElement et modifiez la valeur des propriétés si nécessaire.
| Paramètre | Valeur par défaut pour .NET Framework 4 | Valeur recommandée pour .NET Framework 4 | Valeur par défaut pour .NET Framework 3.5 | Valeur recommandée pour .Net Framework 3.5 |
|---|---|---|---|---|
| ServiceThrottlingBehavior.MaxConcurrentCalls : obtient ou définit une valeur qui spécifie le nombre maximal de messages traités activement dans un ServiceHost. La propriété MaxConcurrentCalls spécifie le nombre maximal de messages traités activement dans un objet ServiceHost . Chaque canal peut avoir un message en attente qui ne compte pas sur la valeur de MaxConcurrentCalls tant que WCF n’a pas commencé à le traiter. Pour plus d’informations sur cette propriété, consultez ServiceThrottlingBehavior.MaxConcurrentCalls (https://go.microsoft.com/fwlink/?LinkId=157838) sur MSDN. La valeur par défaut pour la propriété MaxConcurrentCalls des adaptateurs de réception BizTalk WCF-Custom et WCF-CustomIsolated est 16 par processeur. Remarque : BizTalk Server adaptateurs de réception WCF autres que l’adaptateur WCF-Custom et WCF-CustomIsolated exposent une propriété Nombre maximal d’appels simultanés sous l’onglet Liaison de la boîte de dialogue Propriétés de transport WCF-* pour configurer ce comportement. La valeur par défaut du comportement Nombre maximal d’appels simultanés est 200. | 16*ProcessorCount | 16*ProcessorCount | - 16 pour les adaptateurs de réception bizTalk WCF-Custom et WCF-CustomIsolated. - 200 pour les autres adaptateurs de réception WCF. |
- Essayez >= 200 pour les adaptateurs de réception WCF-Custom et WCF-CustomIsolated. - Essayez > 200 pour la propriété Nombre maximal d’appels simultanés sous l’onglet Liaison de la boîte de dialogue Propriétés de transport WCF-* pour BizTalk Server adaptateurs de réception WCF autres que l’adaptateur WCF-Custom et WCF-CustomIsolated. |
| ServiceThrottlingBehavior.maxConcurrentInstances : obtient ou définit une valeur qui spécifie le nombre maximal d’objets InstanceContext dans le service qui peuvent s’exécuter simultanément. La propriété MaxConcurrentInstances spécifie le nombre maximal d’objets InstanceContext dans le service. Il est important de garder à l’esprit la relation entre la propriété MaxConcurrentInstances et la propriété InstanceContextMode . Si InstanceContextMode est PerSession, la valeur résultante est le nombre total de sessions. Si InstanceContextMode est PerCall, la valeur résultante est le nombre d’appels simultanés. Si un message arrive alors que le nombre maximal d’objets InstanceContext existe déjà, le message est conservé jusqu’à ce qu’un objet InstanceContext se ferme. Pour plus d’informations sur cette propriété, consultez ServiceThrottlingBehavior.MaxConcurrentInstances, propriété (https://go.microsoft.com/fwlink/?LinkId=157897) sur MSDN. La valeur par défaut pour la propriété MaxConcurrentInstances de l’adaptateur de réception WCF-Custom et WCF-CustomIsolated est 116 par processeur. Note: Étant donné que les emplacements de réception WCF sont implémentés en tant qu’instances de la classe BizTalkServiceInstance contenue dans l’assembly Microsoft.BizTalk.Adapter.Wcf.Runtime.dll et que cette classe est marquée comme ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple). toutes les requêtes entrantes sont gérées par le même objet singleton et ce paramètre est ignoré. Par conséquent, la définition de la propriété maxConcurrentInstances sur certains emplacements de réception WCF-Custom n’a aucun effet, car le nombre d’instances actives est toujours égal à 1. | 116*ProcessorCount | 116*ProcessorCount | 26 | Essayer >= 200 |
| ServiceThrottlingBehavior.MaxConcurrentSessions : la propriété MaxConcurrentSessions obtient ou définit le nombre maximal de sessions qu’un objet ServiceHost peut accepter à la fois. Il est important de comprendre que les sessions dans ce cas ne se limitent pas aux canaux qui prennent en charge des sessions fiables. Chaque objet écouteur peut avoir une session de canal en attente qui ne compte pas sur la valeur de MaxConcurrentSessions tant que WCF n’accepte pas la session de canal et commence à traiter les messages de session de canal. Cette propriété est surtout utile dans les scénarios qui utilisent des sessions. Lorsque cette propriété est affectée à une valeur inférieure au nombre de threads clients, les demandes de plusieurs clients peuvent être mises en file d'attente dans la même connexion de socket. Les demandes du client qui n’a pas créé de session avec le service seront bloquées. Ils restent bloqués jusqu’à ce que le service ferme sa session avec les autres clients, si le nombre de sessions ouvertes sur le service a atteint la valeur spécifiée pour MaxConcurrentSessions. Les demandes clientes qui ne sont pas traitées sont alors expirées et le service ferme la session. Pour éviter cette situation, envisagez d’exécuter les threads clients à partir de différents domaines d’application afin que les messages de demande soient acceptés par différentes connexions de socket. Pour plus d’informations sur cette propriété, consultez ServiceThrottlingBehavior.MaxConcurrentSessions, propriété (https://go.microsoft.com/fwlink/?LinkId=157864) sur MSDN. | 100*ProcessorCount | 100*ProcessorCount | 10 | Essayer >= 200 |
Lors de la modification des paramètres de configuration de port, appliquez les modifications méthodiquement ; modifiez chaque paramètre individuellement et testez les effets de la modification sur les performances et la stabilité globale. Comme toujours, la valeur appropriée à appliquer dépend du scénario particulier : si une valeur est définie trop faible, la scalabilité peut être réduite ; tandis que si une valeur est définie trop haut, les exigences de l’application peuvent dépasser la capacité des ressources physiques sur l’ordinateur. En outre, étant donné que ces propriétés sont liées, elles doivent être définies de manière cohérente et cohérente. Pour plus d’informations sur l’utilisation de ServiceThrottlingBehavior pour contrôler les performances du service WCF, consultez Utilisation de ServiceThrottlingBehavior pour contrôler les performances du service WCF (https://go.microsoft.com/fwlink/?LinkId=157908) sur MSDN.