Partager via

Optimisations générales pour BizTalk Server - Partie 2

  • Article

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.

Créer plusieurs hôtes BizTalk Server et des instances d’hôte distinctes par fonctionnalité

Des hôtes distincts doivent être créés 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 constitue le principal moyen de distribuer le traitement entre les serveurs BizTalk d’un groupe BizTalk. Plusieurs hôtes vous permettent également 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 autorisant la réception entrante des messages. La séparation des instances d’hôte par fonctionnalité offre également les avantages suivants :

  • 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.

  • Plusieurs hôtes BizTalk réduisent également les conflits sur les tables de file d’attente de l’hôte 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, de donner à Host_A accès à FileShare_B, tout en n’autorisant aucun autre hôte à accéder au partage de fichiers.

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 des propriétés de l’hôte BizTalk Server, consultez « How to Modify Host Properties » dans l’aide BizTalk Server à l’adresse https://go.microsoft.com/fwlink/?LinkId=101588.

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. Étant donné que le suivi est 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.

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 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 de suivi BizTalk.

  • 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 primaire 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 » dans l’aide BizTalk Server à l’adresse https://go.microsoft.com/fwlink/?LinkId=101589. 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 BizTalk Server :

  • « Gestion du service Bus d’événements BAM » à l’adresse https://go.microsoft.com/fwlink/?LinkId=101590.

  • « Création d’instances du service BAM Event Bus » à l’adresse https://go.microsoft.com/fwlink/?LinkId=101591.

Gérer ASP.NET l’utilisation des threads ou exécuter simultanément des requêtes pour des applications web qui hébergent des orchestrations publiées en tant que service Web ou WCF

Le nombre de threads de travail et d’E/S (IIS 6.0 et IIS 7.0 en mode classique) ou le nombre de demandes exécutées simultanément (mode intégré IIS 7.0) pour une application web ASP.NET qui héberge une orchestration publiée en tant que service Web doit être modifié dans les conditions suivantes :

  • L’utilisation du processeur n’est pas un goulot d’étranglement sur le serveur Web d’hébergement.

  • La valeur des compteurs de performances ASP.NET Apps v2.0.50727\Request Wait Time ou ASP.NET Apps v2.0.50727\Request Execution Time est exceptionnellement élevée.

  • Une erreur similaire à la suivante 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: 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>'

Gérer ASP.NET’utilisation des threads pour les applications web qui hébergent des orchestrations sur IIS 6.0 et IIS 7.0 s’exécutant en mode classique

Lorsque la valeur autoConfig dans le fichier machine.config d’un serveur IIS 6.0 ou d’un serveur IIS 7.0 s’exécutant en mode classique est définie sur true, ASP.NET 2.0 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, 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, performances médiocres et interblocages lorsque vous effectuez des demandes de service Web à partir d’applications ASP.NET » (https://go.microsoft.com/fwlink/?LinkID=66483).

Gérer le nombre de demandes en cours d’exécution simultanée pour les applications web qui hébergent des orchestrations sur IIS 7.0 exécutées en mode intégré

Lorsque ASP.NET 2.0 est hébergé sur IIS 7.0 en mode intégré, l’utilisation des threads est gérée différemment de celle d’IIS 6.0 ou d’IIS 7.0 en mode classique. Lorsque ASP.NET 2.0 est hébergé sur IIS 7.0 en mode intégré, ASP.NET 2.0 limite le nombre de demandes exécutées simultanément plutôt que le nombre de threads exécutant des requêtes 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.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é à partir de la valeur par défaut de 12 par processeur en modifiant la valeur spécifiée pour maxConcurrentThreadsPerCPU. La valeur maxConcurrentThreadsPerCPU 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 maxConcurrentThreadsPerCPU afin de régir le nombre de demandes en cours d’exécution simultanée :

Définir la valeur maxConcurrentThreadsPerCPU dans le Registre

Ce paramètre est global et ne peut pas être modifié pour des pools d’applications ou des applications individuels.

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.

  1. 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.

  2. Accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0

  3. Créez la clé en procédant comme suit :

    1. Dans le menu Modifier , sélectionnez Nouveau, puis clé.

    2. Tapez maxConcurrentThreadsPerCPU, puis appuyez sur Entrée.

    3. Sous la clé maxConcurrentThreadsPerCPU , créez une entrée DWORD avec la nouvelle valeur pour maxConcurrentThreadsPerCPU.

    4. Fermez l’Éditeur du Registre.

Définir la valeur maxConcurrentThreadsPerCPU pour un pool d’applications dans la section config d’un fichier aspnet.config

  1. Téléchargez et installez Microsoft .NET Framework 3.5 Service Pack 1, qui est nécessaire pour prendre en charge la définition des valeurs suivantes dans le fichier de configuration. La version complète est également disponible.

  2. Ouvrez le fichier aspnet.config pour le pool d’applications.

  3. 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 maxConcurrentThreadsPerCPU dans le Registre. Le paramètre requestQueueLimit est identique à processModel/requestQueueLimit, sauf que le paramètre dans le 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 des threads sont affamés, il n’y a pas suffisamment de threads disponibles pour effectuer le travail demandé 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 basculement de contexte se produit lorsque le noyau Windows passe d’un thread à un thread différent, ce qui entraîne un coût de performances. Une allocation excessive de threads peut entraîner un basculement de contexte excessif, ce qui aura un impact négatif sur les performances globales.

Modifiez le nombre de threads Windows disponibles dans le pool de threads .NET associé à une instance d'un hôte BizTalk en créant les valeurs CLR Hosting appropriées dans le Registre de BizTalk Server.

Avertissement

Une utilisation incorrecte de l'Éditeur du Registre peut causer des problèmes vous obligeant à réinstaller votre système d'exploitation. Son utilisation est sous votre entière responsabilité. Pour plus d’informations sur la sauvegarde, la restauration et la modification du Registre, consultez l’article de la Base de connaissances Microsoft « Description du registre Microsoft Windows » à l’adresse https://go.microsoft.com/fwlink/?LinkId=62729.

Notes

Les threads de travail 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.

Pour modifier le nombre de threads disponibles dans le pool de threads .NET associé à chaque instance d’un hôte BizTalk, procédez comme suit :

  1. Arrêtez le instance hôte BizTalk.

  2. Cliquez sur Démarrer, Exécuter, tapez regedit.exe, puis cliquez sur OK pour démarrer l'Éditeur du Registre. Accédez à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$hostname où hostname est le nom de l’hôte associé à l’hôte instance.

    Notes

    Si vous avez mis à niveau votre installation BizTalk Server 2006 à partir de BizTalk Server 2004, cette clé de Registre peut être représentée en tant que GUIDHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc où GUID est un GUID unique à chaque instance d’un hôte BizTalk Server.

  3. Recherchez la clé d’hébergement CLR . Si cette clé n’existe pas, créez la clé en procédant comme suit :

    1. Dans le menu Edition, cliquez sur Nouveau, puis sur Clé.

    2. Tapez HÉBERGEMENT CLR, puis appuyez sur ENTRÉE.

  4. Sous la clé d’hébergement CLR , créez les entrées DWORD suivantes avec les valeurs indiquées.

    Entrée DWORD Valeur par défaut Valeur recommandée
    MaxIOThreads 20 100
    Threadsde travailmax 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. Il est recommandé de ne pas augmenter ce paramètre au-delà d’une valeur de 100.
    MinIOThreads 1 25
    MinWorkerThreads 1 25

    Notes

    Ces valeurs recommandées seront suffisantes pour la plupart des scénarios, mais il peut être nécessaire d’augmenter en fonction du nombre de gestionnaires d’adaptateurs ou d’orchestrations en cours d’exécution dans chaque instance hôte.

    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 une valeur de 400 sur un serveur à 4 processeurs.

  5. Fermez l’Éditeur du Registre.

  6. Redémarrez le instance hôte BizTalk.

Désactiver le suivi pour les orchestrations, les ports d’envoi, les ports de réception et les pipelines lorsque le suivi n’est pas nécessaire

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. Si le suivi n’est pas une exigence métier, désactivez le suivi pour réduire la surcharge et augmenter les performances. Pour plus d’informations sur la configuration du suivi, consultez « Configuration du suivi à l’aide de la console d’administration BizTalk Server » dans l’aide BizTalk Server à l’adresse https://go.microsoft.com/fwlink/?LinkID=106742.

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 » dans l’aide BizTalk Server à l’adresse https://go.microsoft.com/fwlink/?LinkID=104908.

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.

Ne pas mettre en cluster les hôtes BizTalk, sauf si cela est absolument nécessaire

Bien que BizTalk Server 2006 et les versions ultérieures de BizTalk Server vous permettent de configurer un hôte BizTalk en tant que ressource de cluster, vous devez envisager de le faire uniquement 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 machines et ne bénéficient pas de clustering.

Optimisations des performances dans la documentation BizTalk Server

Appliquez les recommandations suivantes de la documentation BizTalk Server en fonction des besoins :