Optimisations générales pour BizTalk Server - Partie 1
Les recommandations suivantes peuvent être utilisées pour augmenter les performances BizTalk Server. Les optimisations répertoriées dans cette rubrique sont appliquées après l’installation et la configuration de BizTalk Server.
Configurer MSDTC
Pour faciliter les transactions entre SQL Server et BizTalk Server, vous devez activer Microsoft Distributed Transaction Coordinator (MS DTC). Pour configurer MSDTC sur BizTalk Server, consultez la rubrique Instructions générales pour l’amélioration des performances du système d’exploitation.
Recommandations pour la configuration des hôtes BizTalk Server
Cette section fournit des recommandations pour la configuration des hôtes BizTalk Server.
Créer plusieurs hôtes BizTalk Server et des instances d’hôte distinctes par fonctionnalité
Suivez ces instructions pour créer plusieurs hôtes BizTalk Server et allouer la charge de travail entre ces hôtes :
Créez des hôtes distincts pour les fonctionnalités d’envoi, de réception, de traitement et de suivi. La création de plusieurs hôtes BizTalk offre de la flexibilité lors de la configuration de la charge de travail dans votre groupe BizTalk et est le principal moyen de distribuer le traitement sur les ordinateurs exécutant BizTalk Server dans un groupe BizTalk. L’utilisation de plusieurs hôtes vous permet d’arrêter un hôte sans affecter les autres hôtes. Par exemple, vous pouvez arrêter d’envoyer des messages pour les laisser mettre en file d’attente dans la base de données MessageBox tout en permettant à un adaptateur de réception s’exécutant dans un autre hôte instance de recevoir des messages entrants. La séparation des instances d’hôte par fonctionnalité offre également les avantages suivants :
L’exécution de plusieurs hôtes BizTalk réduit les conflits sur les tables de file d’attente des hôtes de base de données MessageBox, car chaque hôte se voit attribuer ses propres tables de file d’attente de travail dans la base de données MessageBox.
La limitation est implémentée dans BizTalk Server au niveau de l’hôte. Cela vous permet de définir différentes caractéristiques de limitation pour chaque hôte.
La sécurité est implémentée au niveau de l’hôte ; chaque hôte s’exécute sous une identité Windows discrète. Cela vous permet, par exemple, d’accorder Host_A accès à FileShare_B, tout en n’autorisant aucun des autres hôtes à accéder au partage de fichiers.
Chaque instance hôte a son propre ensemble de ressources, telles que la mémoire, les handles et les threads dans le pool de threads .NET. Lors de l’allocation de la charge de travail entre les hôtes, envisagez de placer les ressources qui sont mises à l’échelle dans le même hôte.
Séparez les adaptateurs et les orchestrations qui ont des priorités différentes pour les ressources dans différents hôtes. Cette technique permet de placer des hôtes exécutant des applications hautement prioritaires sur des ordinateurs BizTalk Server dédiés.
Notes
Bien qu’il y ait des avantages à créer des instances d’hôte supplémentaires, il existe également des inconvénients potentiels si un trop grand nombre d’instances d’hôte sont créées. Chaque instance hôte est un service Windows (BTSNTSvc.exe), qui génère une charge supplémentaire sur la base de données MessageBox et consomme des ressources d’ordinateur (telles que le processeur, la mémoire, les threads).
Pour plus d’informations sur la modification BizTalk Server propriétés de l’hôte, consultez How to Modify Host Properties (https://go.microsoft.com/fwlink/?LinkID=154359) dans l’aide de BizTalk Server 2010.
Configurer un hôte de suivi dédié
BizTalk Server est optimisé pour le débit, de sorte que les moteurs d’orchestration et de messagerie main ne déplacent pas les messages directement vers les bases de données BizTalk Tracking ou BAM, car cela détournerait ces moteurs de leur travail principal d’exécution des processus métier. Au lieu de cela, BizTalk Server laisse les messages dans la base de données MessageBox et les marque comme nécessitant un déplacement vers la base de données bizTalk Tracking. Un processus en arrière-plan (l’hôte de suivi) déplace ensuite les messages vers les bases de données BizTalk Tracking et BAM. Le suivi étant une opération gourmande en ressources, un hôte distinct dédié au suivi doit être créé, ce qui réduit l’impact du suivi sur les hôtes dédiés au traitement des messages. Pour des performances optimales, il doit y avoir au moins un hôte de suivi instance par base de données MessageBox. Le nombre réel d’instances d’hôte de suivi doit être N + 1, où N = le nombre de bases de données MessageBox. Le « + 1 » est destiné à la redondance, au cas où l’un des ordinateurs hébergeant le suivi échoue.
L’utilisation d’un hôte de suivi dédié vous permet également d’arrêter d’autres hôtes BizTalk sans interférer avec BizTalk Server suivi. Le déplacement des données de suivi en dehors de la base de données MessageBox est essentiel pour un système de BizTalk Server sain. Si l’hôte BizTalk responsable du déplacement des données de suivi dans le groupe BizTalk est arrêté, le service Decode des données de suivi ne s’exécute pas. L’impact est le suivant :
Les données de suivi HAT ne seront pas déplacées de la base de données MessageBox vers la base de données BizTalk Tracking.
Les données de suivi BAM ne seront pas déplacées de la base de données MessageBox vers la base de données d’importation principale BAM.
Étant donné que les données ne sont pas déplacées, elles ne peuvent pas être supprimées de la base de données MessageBox.
Lorsque le service Decode des données de suivi est arrêté, les intercepteurs de suivi se déclenchent et écrivent les données de suivi dans la base de données MessageBox. Si les données ne sont pas déplacées, la base de données MessageBox devient gonflée, ce qui aura un impact sur les performances au fil du temps. Même si les propriétés personnalisées ne sont pas suivies ou si les profils BAM ne sont pas configurés, par défaut, certaines données sont suivies (comme les événements de réception/d’envoi de pipeline et les événements d’orchestration). Si vous ne souhaitez pas exécuter le service Decode des données de suivi, désactivez tout le suivi afin qu’aucun intercepteur n’enregistre les données dans la base de données. Pour désactiver le suivi global, consultez Comment désactiver le suivi global (https://go.microsoft.com/fwlink/?LinkID=154193) dans BizTalk Server l’aide de 2010. Utilisez la console d’administration BizTalk Server pour désactiver de manière sélective les événements de suivi.
L’hôte de suivi doit être exécuté sur au moins deux ordinateurs exécutant BizTalk Server (pour la redondance en cas d’échec). Pour des performances optimales, vous devez disposer d’au moins un hôte de suivi instance par base de données MessageBox. Le nombre réel d’instances d’hôte de suivi doit être (N + 1), où N = le nombre de bases de données MessageBox. Le « + 1 » est destiné à la redondance, au cas où l’un des ordinateurs hébergeant le suivi échoue.
Un hôte de suivi instance déplace les données de suivi pour des bases de données MessageBox spécifiques, mais il n’y aura jamais plus d’un hôte de suivi instance déplacement de données pour une base de données MessageBox spécifique. Par exemple, si vous avez trois bases de données MessageBox et seulement deux instances d’hôte de suivi, l’une des instances d’hôte doit déplacer les données de deux des bases de données MessageBox. L’ajout d’un troisième hôte de suivi instance distribue le travail de l’hôte de suivi à un autre ordinateur exécutant BizTalk Server. Dans ce scénario, l’ajout d’un quatrième hôte de suivi instance ne distribuerait plus de travail de l’hôte de suivi, mais fournirait un hôte de suivi supplémentaire instance pour la tolérance de panne.
Pour plus d’informations sur le service BAM Event Bus, consultez les rubriques suivantes dans l’aide de BizTalk Server 2010 :
Gestion du service Bam Event Bus (https://go.microsoft.com/fwlink/?LinkID=154194).
Création d’instances du service Bus d’événements BAM (https://go.microsoft.com/fwlink/?LinkID=154195).
Ne pas mettre en cluster les hôtes BizTalk, sauf si cela est absolument nécessaire
Bien que BizTalk Server 2010 vous permette de configurer un hôte BizTalk en tant que ressource de cluster, vous ne devez envisager de le faire que si vous devez fournir une haute disponibilité à une ressource qui ne peut pas être hébergée sur plusieurs ordinateurs BizTalk. Par exemple, les ports utilisant l’adaptateur FTP ne doivent résider que sur un seul instance hôte, car le protocole FTP ne fournit pas de verrouillage de fichier. Toutefois, cela introduit un point de défaillance unique, qui bénéficierait de clustering. Les hôtes qui contiennent des adaptateurs, tels que des hôtes de fichier, SQL, HTTP ou de traitement uniquement, peuvent être équilibrés en interne entre les ordinateurs et ne bénéficient pas de clustering.
Augmenter le nombre de connexions HTTP simultanées autorisées en modifiant la valeur du paramètre maxconnection
Par défaut, les adaptateurs HTTP (y compris les adaptateurs HTTP basés sur WCF) n’ouvrent que deux connexions HTTP simultanées à partir de chaque ordinateur exécutant BizTalk Server à un serveur de destination spécifique.
Ce paramètre est conforme à la RFC IETF pour la spécification HTTP 1.1, et bien qu’il soit adapté aux scénarios utilisateur, il n’est pas optimisé pour un débit élevé. Le paramètre limite efficacement les appels HTTP sortants vers chaque serveur à deux envois simultanés à partir de chaque ordinateur exécutant BizTalk Server.
Pour augmenter le nombre de connexions simultanées, vous pouvez modifier la valeur du paramètre maxconnection dans le fichier de configuration BizTalk Server, BTSNTSvc.exe.config (ou BTSNTSvc64.exe.config pour les hôtes 64 bits), sur chaque BizTalk Server. Vous pouvez augmenter ce nombre pour les serveurs spécifiques appelés. En règle générale, la valeur du paramètre maxconnection doit être définie sur 12 * le nombre de processeurs ou de cœurs sur l’ordinateur hébergeant l’application web.
Notes
N’augmentez pas la valeur du paramètre maxconnection à une valeur telle que le serveur Web appelé est saturé de connexions HTTP. Après avoir modifié la valeur du paramètre maxconnection, effectuez des tests de contrainte en envoyant des requêtes à chaque serveur Web de destination afin de déterminer une valeur pour maxconnection qui fournira de bonnes performances et des envois HTTP sans surcharger les serveurs Web cibles.
Voici un exemple de configuration de la propriété du nombre maximal de connexions :
<configuration>
<system.net>
<connectionManagement>
<add address="http://www.contoso.com" maxconnection="24" />
<add address="*" maxconnection="48" />
</connectionManagement>
</system.net>
</configuration>
Lors de la définition de la propriété maxconnection, HTTP, HTTPS, l’adresse IP du site web et le numéro de port peuvent être spécifiés. Autres exemples :
<add address="http://www.contoso.com" maxconnection="24" />
<add address="http://www.contoso.com:8080" maxconnection="24" />
<add address="http://<IP-address>" maxconnection="24" />
Pour plus d’informations sur le réglage des paramètres IIS et ASP.NET pour les services Web, consultez la section « paramètres de ASP.NET qui peuvent avoir un impact sur les performances de l’adaptateur HTTP » de Paramètres de configuration affectant les performances de l’adaptateur (https://go.microsoft.com/fwlink/?LinkID=154200) dans BizTalk Server 2010 Aide.
Gérer ASP.NET l’utilisation des threads ou l’exécution simultanée de requêtes pour des applications web qui peuvent héberger des emplacements reçus isolés, des services Web principaux et des services WCF
Le nombre de threads de travail et d’E/S (IIS 7.5 et IIS 7.0 en mode classique) ou le nombre de demandes exécutées simultanément (mode intégré IIS 7.5 et 7.0) pour une application web ASP.NET qui héberge des emplacements reçus isolés, les services Web principaux et les services WCF doivent être modifiés dans les conditions suivantes :
L’utilisation du processeur n’est pas un goulot d’étranglement sur le serveur Web d’hébergement.
Valeur de :
ASP.NET Apps v4.0.30319 \Request Wait Time or ASP.NET Apps v4.0.30319 \Request Execution Time est exceptionnellement élevé.
ASP.NET Apps v2.0.50727\Request Wait Time ou ASP.NET Apps v2.0.50727\Request Execution Time est exceptionnellement élevé.
Une erreur similaire à ce qui suit est générée dans le journal des applications de l’ordinateur qui héberge l’application 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>'
Gérer l’utilisation des threads ASP.NET pour les applications web qui peuvent héberger des emplacements reçus isolés, des services Web principaux et des services WCF sur IIS 7.5 et IIS 7.0 s’exécutant en mode classique
Lorsque la valeur autoConfig dans le fichier machine.config d’un serveur IIS 7.5 et IIS 7.0 s’exécutant en mode classique est définie sur true, ASP.NET 2.0 et ASP.NET 4 gère le nombre de threads de travail et de threads d’E/S alloués à tous les processus de travail IIS associés.
<processModel autoConfig="true" />
Pour modifier manuellement le nombre de threads de travail et d’E/S pour une application web ASP.NET 2.0 et ASP.Net 4, ouvrez le fichier machine.config associé, puis entrez de nouvelles valeurs pour les paramètres maxWorkerThreads et maxIoThreads .
<!-- <processModel autoConfig="true" /> -->
<processModel maxWorkerThreads="200" maxIoThreads="200" />
Notes
Ces valeurs sont fournies à titre indicatif uniquement . vérifiez que vous testez les modifications apportées à ces paramètres.
Pour plus d’informations sur le paramétrage des paramètres dans le fichier machine.config pour une application web ASP.NET 2.0, consultez l’article de la Base de connaissances Microsoft 821268 contention, les performances médiocres et les interblocages lorsque vous effectuez des demandes de service Web à partir d’applications ASP.NET (https://go.microsoft.com/fwlink/?LinkID=144169).
Gérer le nombre de demandes en cours d’exécution simultanée pour des applications web ASP.NET 2.0 pouvant héberger des emplacements reçus isolés, des services Web principaux et des services WCF sur IIS 7.5 et IIS 7.0 s’exécutant en mode intégré
Quand ASP.NET 2.0 est hébergé sur IIS 7.5 et IIS 7.0 en mode intégré, l’utilisation des threads est gérée différemment de celle d’IIS 7.5 et IIS 7.0 en mode classique. Lorsque ASP.NET 2.0 est hébergé sur IIS 7.5 et IIS 7.0 en mode intégré, ASP.NET 2.0 limite le nombre de requêtes exécutées simultanément plutôt que le nombre de threads exécutant des demandes simultanément. Pour les scénarios synchrones, cela limite indirectement le nombre de threads, mais pour les scénarios asynchrones, le nombre de demandes et de threads sera probablement très différent. Lors de l’exécution de ASP.NET 2.0 sur IIS 7.5 et IIS 7.0 en mode intégré, les paramètres maxWorkerThreads et maxIoThreads dans le fichier machine.config ne sont pas utilisés pour régir le nombre de threads en cours d’exécution. Au lieu de cela, le nombre de demandes en cours d’exécution simultanée peut être modifié par rapport à la valeur par défaut de 12 par processeur en modifiant la valeur spécifiée pour maxConcurrentRequestsPerCPU. La valeur maxConcurrentRequestsPerCPU peut être spécifiée dans la nouvelle tentative ou dans la section config d’un fichier aspnet.config. Procédez comme suit pour modifier la valeur par défaut de maxConcurrentRequestsPerCPU afin de régir le nombre de requêtes exécutées simultanément :
Définir la valeur maxConcurrentRequestsPerCPU dans le Registre
Ce paramètre est global et ne peut pas être modifié pour des pools d’applications individuels ou des applications.
Avertissement
Utilisez l’Éditeur du Registre à vos propres risques. Une utilisation incorrecte peut entraîner des problèmes qui vous obligent à réinstaller votre système d’exploitation. Pour plus d’informations sur la sauvegarde, la restauration et la modification du Registre, consultez l’article de la Base de connaissances Microsoft 256986 - Informations du Registre Windows pour les utilisateurs avancés.
Dans le menu Démarrer , recherchez et lancez l’invite Exécuter , entrez regedit.exe, puis sélectionnez OK pour démarrer l’Éditeur du Registre.
Accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0
Créez la clé en procédant comme suit :
Dans le menu Modifier , sélectionnez Nouveau, puis Clé.
Tapez maxConcurrentRequestsPerCPU, puis appuyez sur ENTRÉE.
Sous la clé maxConcurrentRequestsPerCPU , créez une entrée DWORD avec la nouvelle valeur pour maxConcurrentRequestsPerCPU.
Fermez l’Éditeur du Registre.
Définir la valeur maxConcurrentRequestsPerCPU pour un pool d’applications dans la section config d’un fichier aspnet.config
Téléchargez et installez Microsoft .NET Framework 3.5 Service Pack 1, qui est requis pour prendre en charge la définition des valeurs suivantes dans le fichier de configuration. La version complète est également disponible.
Ouvrez le fichier aspnet.config pour le pool d’applications.
Entrez les nouvelles valeurs pour les paramètres maxConcurrentRequestsPerCPU et requestQueueLimit .
<system.web> <applicationPool maxConcurrentRequestsPerCPU="12" requestQueueLimit="5000"/> </system.web>Notes
Cette valeur remplace la valeur spécifiée pour maxConcurrentRequestsPerCPU dans le Registre. Le paramètre requestQueueLimit est identique à processModel/requestQueueLimit, sauf que le paramètre du fichier aspnet.config remplace le paramètre dans le fichier machine.config .
Pour plus d’informations sur la configuration de l’utilisation des threads ASP.NET sur IIS 7.0, consultez blog de Thomas Marquardt sur ASP.NET’utilisation des threads sur IIS 7.0 (https://go.microsoft.com/fwlink/?LinkId=157518).
Gérer le nombre de demandes exécutées simultanément pour ASP.NET 4 applications web qui peuvent héberger des emplacements reçus isolés, des services Web principaux et des services WCF sur IIS 7.5 et 7.0 s’exécutant en mode intégré
Avec .NET Framework 4, le paramètre par défaut pour maxConcurrentRequestsPerCPU est 5000, ce qui est un très grand nombre et permet donc à de nombreuses requêtes asynchrones de s’exécuter simultanément. Pour plus d’informations, consultez <applicationPool> , élément (paramètres web) (https://go.microsoft.com/fwlink/?LinkID=205339).
Pour LE mode intégré IIS 7.5 et IIS 7.0, un DWORD nommé MaxConcurrentRequestsPerCPU dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 détermine le nombre de demandes simultanées par processeur. Par défaut, la clé de Registre n’existe pas et le nombre de demandes par processeur est limité à 5 000.
Définir la valeur maxConcurrentRequestsPerCPU dans le Registre
Ce paramètre est global et ne peut pas être modifié pour des pools d’applications individuels ou des applications.
Avertissement
Utilisez l’Éditeur du Registre à vos propres risques. Une utilisation incorrecte peut entraîner des problèmes qui vous obligent à réinstaller votre système d’exploitation. Pour plus d’informations sur la sauvegarde, la restauration et la modification du Registre, consultez l’article de la Base de connaissances Microsoft 256986 - Informations du Registre Windows pour les utilisateurs avancés.
Dans le menu Démarrer , recherchez et lancez l’invite Exécuter , entrez regedit.exe, puis sélectionnez OK pour démarrer l’Éditeur du Registre.
Accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0.
Créez la clé en procédant comme suit :
Dans le menu Modifier , sélectionnez Nouveau, puis Clé.
Tapez maxConcurrentRequestsPerCPU, puis appuyez sur ENTRÉE.
Sous la clé maxConcurrentRequestsPerCPU , créez une entrée DWORD avec la nouvelle valeur pour maxConcurrentRequestsPerCPU.
Fermez l’Éditeur du Registre.
Définir la valeur maxConcurrentRequestsPerCPU pour un pool d’applications dans la section config d’un fichier aspnet.config
Téléchargez et installez Microsoft .NET Framework 4, qui est requis pour prendre en charge la définition des valeurs suivantes dans le fichier de configuration.
Ouvrez le fichier aspnet.config pour le pool d’applications.
Entrez de nouvelles valeurs pour les paramètres maxConcurrentRequestsPerCPU et requestQueueLimit .
Les valeurs de l’exemple suivant sont les valeurs par défaut.
<system.web> <applicationPool maxConcurrentRequestsPerCPU="5000" requestQueueLimit="5000"/> </system.web>Notes
Cette valeur remplace la valeur spécifiée pour maxConcurrentRequestsPerCPU dans le Registre. Le paramètre requestQueueLimit est identique à processModel/requestQueueLimit, sauf que le paramètre du fichier aspnet.config remplace le paramètre dans le fichier machine.config .
Définir les valeurs de thread d’hébergement CLR pour les instances d’hôte BizTalk
Un thread Windows étant l'unité exécutable la plus basique disponible pour un processus Windows, il est important d'en allouer suffisamment au pool de threads .NET associé à une instance d'un hôte BizTalk pour prévenir la pénurie de threads. Lorsque la pénurie de thread se produit, il n’y a pas suffisamment de threads disponibles pour effectuer le travail demandé, ce qui a un impact négatif sur les performances. En même temps, vous devez veiller à éviter d’allouer plus de threads à the.NET pool de threads associé à un hôte que nécessaire. L'allocation d'un nombre trop important de threads au pool de threads .NET associé à un hôte peut favoriser le basculement de contexte. Le changement de contexte se produit lorsque le noyau Windows passe de l’exécution d’un thread à un autre thread, ce qui entraîne un coût de performances. L’allocation excessive de threads peut entraîner un changement de contexte excessif, ce qui aura un impact négatif sur les performances globales. Le nombre par défaut de threads alloués à un pool de threads .NET d’un hôte BizTalk instance dépend de la version du .NET Framework installée. .NET Framework 4 et .NET Framework 3.5 SP1 ont considérablement augmenté les valeurs par défaut, ce qui peut entraîner une allocation excessive de threads sur les ordinateurs BizTalk Server et une contention excessive de verrouillage sur la base de données MessageBox.
À l’aide du tableau de bord paramètres BizTalk, vous pouvez modifier la valeur par défaut du nombre de threads Windows disponibles dans le pool de threads .NET associé à un instance d’un hôte BizTalk. Pour plus d’informations sur la modification des paramètres CLR .NET, consultez How to Modify .NET CLR Settings (https://go.microsoft.com/fwlink/?LinkID=205344). Les paramètres de CLR .NET sont par noyau de processeur.
Notes
Les threads worker sont utilisés pour gérer les éléments de travail mis en file d’attente et les threads d’E/S sont des threads de rappel dédiés associés à un port d’achèvement d’E/S pour gérer une demande d’E/S asynchrone terminée.
| Paramètres de threading | Valeur par défaut | Valeur recommandée |
|---|---|---|
| Nombre maximal de threads d’E/S | 250 | 250 |
| Nombre maximal de threads de travail | 25 | 100 Important : l’augmentation de cette valeur au-delà de 100 peut avoir un effet négatif sur les performances de l’ordinateur SQL Server hébergeant la base de données MessageBox BizTalk Server. Lorsque ce problème se produit, SQL Server peut rencontrer une situation de blocage. Nous vous recommandons de ne pas augmenter ce paramètre au-delà d’une valeur 100. |
| Threads d’E/S minimum | 25 | 25 |
| Threads de travail minimum | 5 | 25 |
Notes
Les valeurs recommandées ne sont pas des absolus et peuvent devoir être ajustées en fonction de l’application BizTalk. Modifiez un paramètre à la fois, puis mesurez l’impact sur les performances et la stabilité de la plateforme BizTalk avant d’apporter des modifications supplémentaires.
Notes
Ces valeurs sont implicitement multipliées par le nombre de processeurs sur le serveur. Par exemple, définir l’entrée MaxWorkerThreads sur une valeur de 100 définirait effectivement la valeur 400 sur un serveur à 4 processeurs.
Désactiver BizTalk Server suivi au niveau du groupe
Le suivi entraîne une surcharge de performances dans BizTalk Server, car les données doivent être écrites dans la base de données MessageBox, puis déplacées de manière asynchrone vers la base de données BizTalk Tracking. Les considérations suivantes s’appliquent lors de la configuration du suivi dans un environnement de production BizTalk Server :
En règle générale, si le suivi n’est pas une exigence métier, désactivez le suivi au niveau du groupe pour réduire la surcharge et augmenter les performances.
Pour désactiver BizTalk Server suivi au niveau du groupe, procédez comme suit :
Dans la console d’administration BizTalk Server, développez BizTalk Server Administration, cliquez avec le bouton droit sur BizTalk Group, puis cliquez sur Paramètres.
Dans la boîte de dialogue Tableau de bord des paramètres BizTalk, dans la page Groupe, désactivez la zone Activer le suivi au niveau du groupe case activée.
Cliquez sur OK pour appliquer les modifications et quitter le tableau de bord Paramètres.
Utilisez uniquement le suivi du corps des messages si nécessaire. Selon le débit et la taille des messages, le suivi du corps des messages peut entraîner une surcharge importante. Bien que le suivi des activités BizTalk présente des avantages évidents pour le débogage et l’audit, il a également des implications considérables en termes de performances et d’extensibilité. Par conséquent, vous devez suivre uniquement les données strictement nécessaires pour des raisons de débogage et de sécurité, et éviter le suivi des informations redondantes.
Par défaut, les options de suivi suivantes sont activées pour les orchestrations :
Début et fin de l’orchestration
Envoi et réception de messages
Début et fin de la forme
L’option de suivi de l’orchestration « Début et fin de la forme » entraîne une surcharge importante et ne doit pas être activée dans un environnement de production où un débit élevé est nécessaire. Les options de suivi de l’orchestration sont accessibles dans la console Administration BizTalk dans la page Suivi de la boîte de dialogue Propriétés de l’orchestration.
Pour plus d’informations sur la configuration du suivi, consultez Configuration du suivi à l’aide de la console d’administration BizTalk Server (https://go.microsoft.com/fwlink/?LinkId=158021).
Réduire la période de vidage pour le travail de vidage et d’archivage DTA de 7 jours à 2 jours dans les scénarios de débit élevé
Par défaut, l’intervalle de vidage des données de suivi dans BizTalk Server est défini sur 7 jours. Dans un scénario à débit élevé, cela peut entraîner une accumulation excessive de données dans la base de données de suivi, ce qui aura un impact sur les performances de MessageBox et, à son tour, sur le débit de traitement des messages.
Dans les scénarios à débit élevé, réduisez l’intervalle de purge dur et souple de 7 jours à 2 jours par défaut. Pour plus d’informations sur la configuration de l’intervalle de vidage, consultez How to Configure the DTA Purge and Archive Job (https://go.microsoft.com/fwlink/?LinkID=153814) dans l’aide BizTalk Server 2010.
Configurer le chemin %temp% pour le compte de service BizTalk pour qu’il pointe vers un disque ou un numéro d’unité logique distinct
Cette opération doit être effectuée, car BizTalk utilise l’emplacement temporaire pour diffuser en continu des fichiers sur le disque lors de l’exécution d’opérations de mappage complexes.
Installer les derniers Service Packs
Les Derniers Service Packs pour BizTalk Server et le .NET Framework doivent être installés, car ils contiennent des correctifs qui peuvent corriger les problèmes de performances que vous pouvez rencontrer.
Optimisations des performances dans la documentation BizTalk Server
Appliquez les recommandations suivantes de la documentation BizTalk Server en fonction des besoins :
Résolution des problèmes de latence de MessageBox (https://go.microsoft.com/fwlink/?LinkId=158019)
Identification des goulots d’étranglement des performances (https://go.microsoft.com/fwlink/?LinkID=154238)
Éviter les exceptions DBNETLIB (https://go.microsoft.com/fwlink/?LinkID=155308)
Éviter l’épuisement des ports TCP/IP (https://go.microsoft.com/fwlink/?LinkID=153240)
Définition de la taille du pool de threads EPM (https://go.microsoft.com/fwlink/?LinkId=158020)