Goulots d’étranglement dans le niveau BizTalk Server

Le niveau BizTalk peut être divisé en plusieurs zones fonctionnelles :

• Réception

• Traitement

• Transmission

• Suivi

• Autres

  Pour ces zones, si les ressources système (processeur, mémoire et disque) semblent saturées, mettez à niveau le serveur en mettant à l’échelle la plateforme en fonction des caractéristiques de votre application. Si les ressources système ne sont pas saturées, suivez les procédures décrites dans cette section.

Goulots d’étranglement dans l’emplacement de réception

Si les messages s’accumulent à l’emplacement de réception (par exemple, le dossier de réception de fichiers devient volumineux), cela indique que le système ne peut pas absorber les données suffisamment rapidement pour suivre la charge entrante. Cela est dû à une limitation interne. Autrement dit, BizTalk Server réduit le taux de réception si les abonnés ne parviennent pas à traiter les données suffisamment rapidement, ce qui entraîne l’accumulation du backlog dans les tables de base de données. Si le goulot d’étranglement est dû à des limitations matérielles, essayez d’effectuer un scale-up. Pour plus d’informations sur le scale-up, consultez les rubriques suivantes dans la documentation BizTalk Server 2010 :

• Montée en puissance du niveau BizTalk Server (https://go.microsoft.com/fwlink/?LinkId=158073).

• Montée en puissance du niveau SQL Server (https://go.microsoft.com/fwlink/?LinkId=158077).

  Il est également possible d’effectuer un scale-out en ajoutant un instance hôte (serveur) à l’hôte mappé au gestionnaire de réception. Pour plus d’informations sur le scale-out, consultez les rubriques suivantes dans la documentation BizTalk Server 2010 :

• Scale-out du niveau BizTalk Server (https://go.microsoft.com/fwlink/?LinkId=158076).

• Scale-out du niveau SQL Server (https://go.microsoft.com/fwlink/?LinkId=158075).

  Utilisez Perfmon pour surveiller l’utilisation des ressources sur le système. Il est important de confirmer que l'emplacement de réception externe n'est pas à l'origine du goulot d'étranglement. Par exemple, vérifiez si le partage de fichiers distant est saturé en raison d’E/S disque élevées, si le serveur hébergeant la file d’attente sortante distante n’est pas saturé ou si le client utilisé pour générer la charge HTTP n’est pas affamé sur les threads.

Traitement des goulots d’étranglement

Si le compteur de performances File d’attente de l’hôte – Longueur augmente, cela indique que les orchestrations ne se terminent pas assez rapidement. Pour plus d’informations, consultez la table de compteurs Perfmon dans cette rubrique. Ce problème peut être dû à un conflit de mémoire ou à une saturation de l'UC.

Si les serveurs d'orchestration constituent le goulot d'étranglement, utilisez l'utilitaire Perfmon pour en identifier la source.

Si le serveur est lié à l'UC, prenez en compte les éléments suivants :

• Si le flux de travail est complexe, envisagez de fractionner l’orchestration en plusieurs orchestrations plus petites

  Notes

  Le fractionnement d'une orchestration en plusieurs workflows peut engendrer une latence supplémentaire et une plus grande complexité. Plusieurs workflows peuvent également entraîner une augmentation du nombre de messages publiés et consommés à partir de BizTalkMsgBoxDb, ce qui exerce une pression supplémentaire sur la base de données.

• Si vous utilisez des cartes complexes, déterminez si elles peuvent être déplacées vers les ports de réception/d’envoi. Veillez à vérifier quels ports ont une bande passante supplémentaire.

• Envisagez d’effectuer un scale-up du matériel ou d’effectuer un scale-out en configurant un serveur de traitement supplémentaire.

Transmission des goulots d’étranglement

Si le serveur hébergeant les adaptateurs d’envoi est saturé sur les ressources (par exemple, disque, mémoire ou processeur), envisagez de monter en puissance le serveur ou de procéder à un scale-out vers des serveurs hôtes d’envoi supplémentaires. Le niveau d'envoi peut devenir le goulot d'étranglement si la destination (externe à BizTalk) ne parvient pas à recevoir les données assez rapidement. Les messages s'accumulent alors dans la base de données MessageBox (application SendHostQ).

Si tous les points de terminaison se trouvent dans l’étendue de la topologie, isolez la cause à la destination. Par exemple, déterminez si l’emplacement HTTP est configuré de manière optimale pour recevoir la charge. Si ce n’est pas le cas, envisagez d’effectuer un scale-out. Déterminez également si la destination augmente en raison de messages de sortie excessifs remis par BizTalk. Si oui, vous aurez peut-être besoin d’un plan de maintenance pour archiver et vider les messages de destination. Un grand nombre de fichiers dans un dossier de destination peut avoir un impact grave sur la capacité du service BizTalk à valider des données sur le lecteur de disque.

Suivi des goulots d’étranglement

L’hôte de suivi instance est chargé de déplacer les données de surveillance de l’activité métier (BAM) et de suivi d’intégrité et d’activité (HAT) de la base de données MessageBox (table TrackingData) vers les tables de base de données BizTalk Tracking et/ou BAM Primary Import. Si plusieurs bases de données MessageBox sont configurées, l’hôte de suivi instance utilise quatre threads par base de données MessageBox.

Il est possible que l’hôte de suivi instance soit lié au processeur. Si c’est le cas, envisagez d’effectuer un scale-up du serveur ou d’effectuer un scale-out en configurant un serveur supplémentaire avec le suivi de l’hôte activé. Les instances de plusieurs hôtes équilibrent automatiquement la charge pour les plusieurs bases de données MessageBox configurées. Pour plus d’informations sur la mise à l’échelle, consultez la rubrique Mise à l’échelle de vos solutions (https://go.microsoft.com/fwlink/?LinkId=158078).

Si la table TrackingData de la base de données MessageBox devient volumineuse, c’est généralement parce que les travaux de maintenance des données sur la base de données BizTalk Tracking et/ou la base de données d’importation principale BAM ne s’exécutent pas comme configuré, ce qui entraîne la croissance des bases de données BizTalk Tracking et/ou BAM Primary Import. Une fois ces bases de données trop volumineuses, cela peut avoir un impact négatif sur la capacité de l’hôte de suivi à insérer des données dans la table TrackingData. Cela entraîne la sauvegarde des données suivies dans les tables de base de données MessageBox. La croissance de la table TrackingData entraîne le démarrage de la limitation.

Vous ne devez activer que le suivi minimal requis pour votre application, car cela réduira la quantité de données enregistrées et réduira le risque de suivi des goulots d’étranglement. Pour plus d’informations sur la désactivation des paramètres de suivi pour des éléments individuels tels que les orchestrations et les ports d’envoi/réception, consultez Comment désactiver le suivi (https://go.microsoft.com/fwlink/?LinkId=160064).

Autres

Configurez la topologie de déploiement de telle façon que les différentes fonctionnalités s'exécutent sur des instances d'hôte dédiées isolées. De cette façon, chaque instance hôte obtient son propre ensemble de ressources (par exemple, sur un système 32 bits, un espace d’adressage de mémoire virtuelle de 2 Go, des handles, des threads). Si le serveur dispose d’une marge de stockage et d’une mémoire suffisantes pour héberger plusieurs instances d’hôte, elles peuvent être configurées pour s’exécuter sur le même ordinateur physique. Si ce n’est pas le cas, envisagez d’effectuer un scale-out en déplaçant la fonctionnalité vers des serveurs dédiés. Le fait d'exécuter une même fonctionnalité sur plusieurs serveurs permet également de disposer d'une configuration hautement disponible.

Compteurs de performances système BizTalk

Contention du processeur

Si le processeur est saturé, vous pouvez fragmenter l’application en séparant la réception de l’expéditeur et l’orchestration. Pour ce faire, créez des hôtes distincts, mappez les hôtes à des fonctionnalités spécifiques (réception/envoi/orchestrations/suivi) et ajoutez des serveurs dédiés à ces hôtes distincts. La fonctionnalité d’orchestration est souvent gourmande en ressources processeur. Si vous configurez le système pour que les orchestrations s’exécutent sur un serveur dédié distinct, cela peut contribuer à améliorer le débit global du système.

Si plusieurs orchestrations sont déployées, vous pouvez les inscrire auprès de différents hôtes d’orchestration dédiés. Le mappage de différents serveurs physiques aux hôtes d’orchestration dédiés garantit que les différentes orchestrations sont isolées et ne se disputent pas pour les ressources partagées dans le même espace d’adressage physique ou sur le même serveur.

Arrêtez les instances d’hôte inutilisées. Les instances d’hôte inutilisées peuvent entrer en concurrence pour les ressources de processeur et de mémoire en vérifiant régulièrement le MessageBox pour les messages à traiter. En outre, arrêtez les emplacements de réception inutilisés, les ports d’envoi et les orchestrations.

Croissance de la table de pool

Les goulots d’étranglement en aval et/ou la contention de ressources peuvent entraîner une croissance excessive du pool et réduire les performances globales. Pour plus d’informations, consultez « Spool Table Growth » dans Comment identifier les goulots d’étranglement dans la base de données MessageBox1.

Insuffisance de mémoire

Des scénarios de débits élevés ont pu augmenter la demande au niveau de la mémoire du système. Étant donné qu’un processus 32 bits est limité par la quantité de mémoire qu’il peut consommer, il est recommandé de séparer la fonctionnalité de réception/processus/envoi en instances d’hôte distinctes, de sorte que chaque hôte reçoive son propre espace d’adressage de 2 Go. En outre, si plusieurs instances d’hôte s’exécutent sur le même serveur physique, vous pouvez effectuer une mise à niveau vers 4/8 Go de mémoire pour éviter d’échanger des données sur le disque à partir de la mémoire réelle. Les orchestrations de longue durée peuvent conserver la mémoire allouée plus longtemps. Cela peut entraîner un ballonnement de la mémoire et une limitation de démarrage. Les messages volumineux peuvent également entraîner une consommation élevée de mémoire.

Vous pouvez atténuer le problème de surcharge de mémoire qui se produit lorsque des messages volumineux sont traités en réduisant la taille de la file d’attente de messages interne et les messages in-process par processeur pour l’hôte spécifique.

Contention de disque

Si les disques sont saturés (par exemple, avec un grand nombre de transports FILE/MSMQ), envisagez de mettre à niveau vers plusieurs broches et d’enlever les disques avec RAID 10. En outre, chaque fois que vous utilisez le transport FILE, il est important de s’assurer que les dossiers de réception et d’envoi ne dépassent pas 50 000 fichiers.

Le dossier de réception peut devenir volumineux si BizTalk Server limite les données entrantes dans le système. Il est important de déplacer des données à partir du dossier d’envoi afin que la croissance de ce dossier n’affecte pas la capacité des BizTalk Server à écrire des données supplémentaires. Pour les files d’attente MSMQ non transactionnelles, il est recommandé de créer à distance les files d’attente de réception afin de réduire la contention de disque sur le BizTalk Server.

La configuration de file d’attente non transactionnelle distante offre également une haute disponibilité, car le serveur distant hébergeant la file d’attente peut être en cluster.

Autre conflit de ressources système

Selon le type de transport, il peut être nécessaire de configurer des ressources système comme IIS pour HTTP (par exemple, MaxIOThreads, MaxWorkerThreads).

Avec ASP.NET 2.0 et ASP.Net 4, le <paramètre processModel autoConfig="true »> dans le fichier machine.config configure automatiquement les paramètres suivants pour des performances optimales :

• Nombre maximal de threads de travail

• Nombre maximal de threads d’E/S

• Attribut minFreeThreads de l’élément httpRuntime

• attribut minLocalRequestFreeThreads de l’élément httpRuntime

• Attribut maxConnection de l’élément <connectionManagement> Element (Network Settings)

  Pour plus d’informations sur la configuration des paramètres qui affectent les performances de l’adaptateur, consultez paramètres de configuration ASP.NET pour l’élément processModel (https://go.microsoft.com/fwlink/?LinkId=158080).

  Pour plus d’informations sur les paramètres de configuration qui peuvent affecter BizTalk Server adaptateurs, consultez Paramètres de configuration qui affectent les performances de l’adaptateur (https://go.microsoft.com/fwlink/?LinkID=154200).

  En plus d’optimiser vos applications BizTalk Server, d’autres applications ASP.NET s’exécutant sur le même serveur peuvent avoir une incidence sur les performances globales. Il est important d’optimiser toutes vos applications ASP.NET pour réduire la demande sur les ressources système. Pour plus d’informations, consultez Performances ASP.NET (https://go.microsoft.com/fwlink/?LinkId=158081).

  Lors de la configuration pour des performances maximales, envisagez d’optimiser d’autres systèmes externes tels que les moteurs de messagerie (Message Queuing, MQSeries), les applications, les bases de données, Active Directory, etc. qui font partie de votre solution BizTalk globale. Les goulots d’étranglement des performances dans l’un de ces autres systèmes externes peuvent avoir un effet négatif sur votre solution BizTalk.

Goulots d’étranglement en aval

Si le système en aval ne parvient pas à recevoir des données suffisamment rapidement de BizTalk, ces données de sortie sont sauvegardées dans les bases de données BizTalk. Cela entraîne un ballonnement, entraîne le démarrage d’une limitation, réduit le canal de réception et a un impact sur le débit global du système BizTalk. Une indication directe de cela est la croissance de la table Spool. Pour plus d’informations sur les goulots d’étranglement et la table Spool, consultez Comment identifier les goulots d’étranglement dans la base de données MessageBox1.

Impact des limitations

La limitation va finalement commencer à protéger le système d’atteindre un état irrécupérable. Ainsi, vous pouvez utiliser la limitation pour vérifier si le système fonctionne normalement et découvrir la source du problème. Après avoir identifié la cause du goulot d’étranglement à partir de l’état de limitation, analysez les autres compteurs de performances pour déterminer la source du problème. Par exemple, une contention élevée sur la base de données MessageBox peut être due à une utilisation élevée du processeur, due à une pagination excessive sur le disque qui est due à des conditions de mémoire insuffisantes. Une contention élevée sur la base de données MessageBox peut également être due à une contention de verrouillage élevée due à des lecteurs de disque saturés. Bien que la limitation occasionnelle ne soit pas une menace importante pour les performances, la limitation persistante peut indiquer un problème sous-jacent plus important. Pour plus d’informations sur les conditions dans lesquelles BizTalk Server utiliseront la limitation, consultez How BizTalk Server Implements Host Throttling (https://go.microsoft.com/fwlink/?LinkID=155286).

Pour plus d’informations sur la façon dont BizTalk Server limitation peut aider à gérer l’utilisation des ressources disponibles et à réduire les conflits de ressources, consultez Optimisation de l’utilisation des ressources via la limitation de l’hôte (https://go.microsoft.com/fwlink/?LinkID=155770).

Compteurs d’application BizTalk

Par où commencer ?

La surveillance de l’état de limitation de la remise de messages et de l’état de limitation de publication des messages pour chaque instance hôte est un bon point de départ. Si la valeur de ces compteurs n’est pas zéro, cela indique une limitation dans le système BizTalk et vous pouvez analyser plus en détail la cause du goulot d’étranglement. Pour obtenir des descriptions sur les autres compteurs de performances, consultez Goulots d’étranglement dans la couche base de données.

Compteurs de performances du moteur d’orchestration

Nous vous recommandons vivement d’affiner les paramètres du runtime d’orchestration, car la déshydratation,la réhydratation et les points de persistance de l’orchestration continue peuvent avoir un impact grave sur les performances globales. Vous devez utiliser les compteurs suivants lors du test d’orchestrations complexes qui peuvent contenir plusieurs points de persistance et étendues transactionnelles.

Buildup du backlog

Pour un scénario de déploiement 1-1 où 1 message reçu entraîne 1 message traité et transmis, si le taux de sortie n’est pas égal au débit entrant, il existe un backlog dans le système. Dans ce cas, vous pouvez surveiller la taille du spouleur. Lorsque vous déterminez la cause des goulots d’étranglement dans le taux de sortie, exécutez un scénario de cas d’usage unique à la fois. Isolez les orchestrations, les emplacements de réception et envoyez des emplacements à des hôtes distincts.

Ajoutez les compteurs BizTalk :Message Box :Host à votre journal Analyseur de performances pour surveiller un hôte. Le compteur File d’attente hôte - Longueur : suit le nombre total de messages dans une file d’attente hôte particulière. Si un ou plusieurs de ces compteurs continuent de croître au fil du temps, accordez une attention particulière aux artefacts exécutés par ces hôtes.

Si le Spool augmente de manière linéaire, déterminez quelle file d’attente d’application est responsable de la croissance du Spool.

Si aucune des files d’attente d’applications ne croît et que le Spool continue de croître, cela peut signifier que les travaux de purge ne peuvent pas suivre le temps. Cela se produit si l’agent n’est pas en cours d’exécution ou s’il existe d’autres conflits de ressources système sur le SQL Server.

Si l’une des files d’attente d’applications augmente, diagnostiquez la cause de cette croissance. Surveillez les ressources système sur le système qui ne peuvent pas vider la file d’attente d’application spécifique (par exemple, l’orchestration Host-Q augmente en raison d’une insuffisance de processeur sur le serveur). En outre, vérifiez les valeurs du compteur de limitation pour le instance hôte spécifique.

Si les compteurs de performances de limitation de la remise de messages de l’agent bizTalk :Message et d’état de limitation de publication de messages ne sont pas zéro, case activée la valeur pour confirmer la raison de la limitation (par exemple, le seuil de mémoire dépassé, le nombre de messages en cours d’exécution trop élevé, etc.).

Stand-Alone Profiler

Vous pouvez utiliser des compteurs de performances pour détecter l’emplacement du goulot d’étranglement à un niveau élevé. Toutefois, une fois le code restreint, vous devrez peut-être examiner le code de plus près pour vous aider à résoudre le problème. Le profileur Stand-Alone fourni avec Visual Studio 2010 peut être un outil très utile pour vous aider à diagnostiquer où le code passe la plupart de ses cycles. Pour plus d'informations, consultez la rubrique

Cache L2/L3

Du point de vue du matériel, vous pouvez bénéficier des avantages les plus importants en utilisant le cache du processeur intégré. L'augmentation de cette mémoire cache permet d'accroître le taux d'accès au cache et de réduire ainsi la nécessité pour le système de paginer les données en dehors et à l'intérieur de la mémoire sur le disque.

Goulots d’étranglement des performances 64 bits

Les performances des systèmes 64 bits peuvent paraître inférieures à celles qu'il est possible d'atteindre sur les systèmes 32 bits. Cela est possible pour plusieurs raisons, la plus importante étant la mémoire.

Mesurer les performances sur un système 32 bits avec 2 Go de mémoire et comparer les résultats à un système 64 bits similaire avec 2 Go de mémoire ne compare pas la même chose. Le système 64 bits semble être lié aux E/S disque (faible % de temps d’inactivité du disque & longueur de file d’attente de disque élevée) et au processeur (nombre maximal de processeurs et basculement de contexte élevé). Toutefois, cela n’est pas dû au fait que l’exécution d’E/S de fichier sur un système 64 bits est plus coûteuse.

Le système 64 bits est plus gourmand en mémoire (adressage 64 bits), ce qui permet au système d’exploitation de consommer la majeure partie de la mémoire disponible de 2 Go. Dans ce cas, la plupart des autres opérations entraînent la pagination sur le disque, ce qui stresse le sous-système de fichier. Par conséquent, le système dépense des cycles d’UC pour paginer/extraire de la mémoire à la fois les données et le code, et est affecté par le coût élevé de latence du disque. Cela se traduit par un plus grand nombre de conflits sur le disque et par une plus grande utilisation de l'UC.

Le moyen d’atténuer ce problème consiste à effectuer un scale-up du serveur en mettant à niveau la mémoire. La mise à l’échelle jusqu’à 8 Go est une idée, cependant, l’ajout de mémoire supplémentaire ne permet pas d’améliorer le débit, sauf si la source du problème est la pénurie de processeur en raison de conditions de mémoire insuffisantes.

Utilisation de BAM pour identifier les goulots d’étranglement et les problèmes de latence élevée

Lorsque la faible latence est importante, vous pouvez utiliser BAM pour mesurer le temps nécessaire au système pour effectuer chaque étape au sein du système BizTalk Server. Bien que vous puissiez utiliser HAT pour déboguer l’état des messages et diagnostiquer la source des problèmes de routage des messages, vous pouvez utiliser BAM pour suivre différents points dans le flux de messages. En créant un profil de suivi BAM qui définit une activité avec des continuations, vous pouvez mesurer la latence entre les différentes parties du système pour vous aider à suivre les étapes les plus coûteuses du processus de flux de travail.

Vous pouvez utiliser le débogueur d’orchestration dans HAT pour interroger un instance suspendu, reprendre la instance en mode débogage et ajouter les points d’arrêt appropriés à l’aide de la vue Détails techniques. Ceci vous permettra de suivre vos activités et les messages de débogage pas à pas.

Vous pouvez définir des points d'arrêt pour suivre les événements suivants :

• Début/fin d'une orchestration

• Début/fin d'une forme

• Envoi ou réception d'un message

• Exceptions

  À chaque point d'arrêt, vous pouvez examiner les informations sur les variables locales, les messages et leurs propriétés, les ports et les liens-rôles.

Voir aussi

Recherche et suppression des goulots d’étranglement