Scénarios de test pour mesurer le débit maximal acceptable du suivi DTA

Pour montrer comment tout ceci fonctionne en pratique et présenter une technique simple de mesure du débit maximal acceptable pour le suivi, nous présentons maintenant un scénario de test pour lequel le suivi du débit maximal acceptable a été mesuré. Non seulement nous fournissons les techniques impliquées, mais vous pouvez utiliser les données présentées comme point de départ d’estimation du suivi des performances d’autres systèmes.

Important

Les lecteurs doivent savoir que les informations contenues dans cette rubrique représentent l'opinion actuelle de Microsoft sur les points cités à la date de publication. Étant donné que l'entreprise doit s'adapter aux conditions fluctuantes du marché et aux nouvelles technologies, Microsoft ne peut pas garantir la véracité de toute information présentée après la date de publication.

Topologie et configuration du scénario de test

L'illustration suivante représente la topologie et la configuration du scénario de test. Il s’agit d’une build de taille avec quatre serveurs de base de données MessageBox, un serveur de base de données BizTalkDTADb dédié et un total de sept serveurs exécutant BizTalk Server. Notez que le serveur BAM figurant dans l'illustration n'est pas utilisé pour ce scénario de test.

Débit acceptable BizTalkDTADb

Spécifications matérielles (BizTalk Server)

• PROCESSEUR : Double 3 GHz (Cache : L2 : 512 Ko/L3 : 1 Mo)

• Mémoire : 2 Go de RAM

• HDD : 2 X 32 Go/15 K

  Spécifications matérielles (SQL Server)

• PROCESSEUR : Quad 2 GHz (L2 : 512 Ko/L3 : 1 Mo)

• Mémoire : 4 Go de RAM

• HDD : 2 x 32 Go/15 K + SAN

  L'illustration suivante fournit une vue d'ensemble de l'architecture du scénario de test, où

• TP = Point de suivi, point auquel certains éléments sont suivis, tels que les événements ou les propriétés de message.

• Mo = Corps du message, point auquel le corps d’un message est suivi.

  L’architecture de solution suivante présente une configuration de suivi contenant trois principaux composants de configuration :

• Suivi DTA par défaut. Tous les points de suivi des événements de la figure sont activés par défaut lorsque BizTalk Server est installé.

• Propriétés du message. Le point de suivi associé au composant désassembleur (DA) dans le pipeline entrant représente le suivi de 10 propriétés à partir du message entrant. Pour plus d’informations sur la promotion des propriétés à des fins de suivi, consultez Promotion des propriétés.

• Corps du message. Les deux points de corps de message (MB) de l’illustration représentent les points auxquels les corps de message font l’objet d’un suivi. Pour plus d’informations sur la configuration du suivi du corps des messages, consultez Gérer et suivre les artefacts BizTalk.

  Architecture du test du scénario

  

Techniques de test

L’adaptateur de fichier a été utilisé à la fois pour l’envoi et pour la réception. Nous avons utilisé l'outil de génération de charge, LoadGen 2007, pour transmettre les messages à l'emplacement de partage de fichiers entrant. L’outil LoadGen a été configuré pour transmettre les fichiers à un rythme spécifique, de sorte qu'il a été possible de varier la charge pendant la recherche de notre niveau de débit maximal de suivi. Pour plus d’informations sur l’outil LoadGen, consultez Utilisation de l’outil Microsoft BizTalk LoadGen 2007.

Pour nos tests, nous sommes partis d’une obligation de conserver 24 heures les éléments dans la base de données BizTalkDTADb. C'est-à-dire que tout ce qui a plus de 24 heures est effacé de la base de données. Le travail d'archivage et de purge SQL est conçu de telle sorte que seules les données ayant été archivées sont purgées. Il ne se produit ainsi aucune perte de données au cours du processus.

Pour tester entièrement le système en fonction de cette condition, il nous a fallu exécuter la charge pendant au moins 25 heures, afin d’inclure au moins un cycle d'archivage et de purge. Nous avons choisi d'exécuter le processus pendant 48 heures afin de surveiller le système pendant les 24 heures suivant le premier archivage afin d'en vérifier la stabilité. Les premières 24 heures étaient nécessaires pour réunir des données suffisamment anciennes pour être archivées (toutes les 24 heures) afin de simuler un état d'équilibre. Le système était surveillé pendant les 24 heures suivantes pour déterminer que tous les processus (par exemple, TDDS, archivage et purge) ont été en mesure de suivre le débit.

Après avoir observé le comportement de suivi, nous avons pu dégager quelques indicateurs clés de performance (KPI) qui doivent généralement être surveillées pour en déterminer la stabilité :

• Temps d’inactivité du disque physique pour le fichier de données de base de données BizTalkDTADb. Si la durée d’inactivité du disque physique est proche de 0, cela indique certainement que la base de données BizTalkDTADb est saturée par les entrées de données suivies, l’activité d’archivage et/ou de purge.

• Profondeur de la table trackingdata. Si la table Trackingdata commence à croître automatiquement, c'est-à-dire à augmenter sans limite, il est évident que TDDS n’est pas en mesure, au débit actuel, d’insérer des données dans la base de données BizTalkDTADb assez vite pour suivre le rythme.

• Profondeur du pool. Plusieurs raisons peuvent être à l’origine de cette croissance du spooleur. Cela peut venir par exemple du retard d'une tâche SQL chargée de copier les corps de message suivis depuis la base de données MessageBox vers la base de données BizTalkDTADb. Etant donné que les messages qui doivent être suivis ne peuvent pas être supprimés de la base de données MessageBox (par les fonctions de nettoyage de MessageBox) tant qu'ils n'ont pas été correctement copiés dans la base de données BizTalkDTADb, si la tâche de copie prend du retard, il en résulte une accumulation dans le spooleur.

  Pour la majorité des systèmes, les informations fournies par ces trois indicateurs clés de performance de la charge suffisent pour déterminer si la charge est stable ou non.

  Indicateurs clés de performance de charge en dessous des limites acceptables

  

  À l’aide de cet exemple de scénario, avec une charge de 20 messages reçus par seconde, nous avons réuni 48 heures d'informations au niveau des indicateurs clés de performance, comme l'indique le graphique Perfmon ainsi généré. Remarquez dans ce graphique les tendances suivantes, signes d'une stabilité :

• Profondeur des données BizTalkDTADb (lignes noires). Avec nos trois bases de données acceptant la publication, nous constatons que, même après le premier archivage des 24 heures, la profondeur de la table trackingdata se stabilise et arrête d’augmenter.

• Profondeur du pool (lignes bleues). La profondeur du spooleur est très stable tout au long de l’exécution, ce qui indique que, même lorsque l'archivage et la purge consomment des ressources, les messages suivis, qui ont tous une taille de 10 kilooctets, sont copiés dans la base de données BizTalkDTADb sans provoquer de retard.

• Temps d’inactivité du disque physique du fichier de base de données BizTalkDTADb (ligne rouge). Durant les 24 premières heures précédant l’archivage et la purge, des activités ont lieu, par conséquent la base de données BizTalkDTADb accumule de plus en plus de données, ce qui se traduit par un nombre croissant d’E/S sur le disque à mesure que les données sont insérées par TDDS. Cela se traduit clairement par une baisse constante de la durée d'inactivité du disque physique.

  À 24 heures de l’exécution, une baisse nette du temps d’inactivité des E/S est observée, ce qui coïncide avec la première fois que l’archivage et le vidage ont du travail à effectuer. Après la première archive, le vidage doit être effectué toutes les minutes pour vider les données de plus de 24 heures (n’oubliez pas qu’il y a toujours une charge sur le système), ce qui entraîne un temps d’inactivité proche de zéro.

  A ce stade, l’élément clé réside dans le fait que, une fois le premier archivage effectué, le système affiche la première fenêtre "de conservation des données de la base de données BizTalkDTADb", la durée d’inactivité du disque est très proche de zéro lorsque le système se trouve proche du débit maximal acceptable. Cela vient du fait que le goulot d’étranglement de la base de données BizTalkDTADb est presque toujours lié à la vitesse du sous-système d’E/S du disque.

  Dans de nombreux cas, il peut être judicieux de mesurer le débit maximal acceptable avec le suivi désactivé comme base pour le système. Dans notre cas, par exemple, le débit maximal acceptable avec le suivi désactivé était de 290 messages par secondes, ce qui correspond à plusieurs fois le débit maximal acceptable du système avec le suivi activé avec les fonctions et la fenêtre de conservation des données DTA mentionnés précédemment. La preuve est ainsi faite de la sous utilisation du système lorsque le suivi est activé. Ainsi, il n'est pas nécessaire de créer un système capable de traiter 290 messages par seconde lorsque les éléments qui feront l'objet du suivi ne peuvent accepter qu'un débit maximal de 20 messages par seconde. En d'autres termes, si la configuration matérielle de la base de données BizTalkDTADb ne change pas, le nombre de serveurs de base de données BizTalk et MessageBox nécessaires pour maintenir le débit de 20 messages par seconde serait bien inférieur à ce que nous avons dans notre scénario.

Recherche du débit maximal acceptable

Maintenant que nous avons vu à quoi ressemblent les indicateurs clés de performance pour un système en cours d'exécution à un débit maximal acceptable, revenons en arrière et expliquons comment nous sommes parvenus à un débit de 20 messages par seconde pour le scénario exemple. Il s’agit d’une approche de «recherche binaire », itérative simple, comme suit :

• Choisissez un point de départ. Sauf si vous avez déjà de l’expérience avec les tests de performances sur BizTalk Server, vous devez vous prévaloir des informations disponibles sur ce qui a été réalisé sur d’autres systèmes.

  Par exemple, dans cette rubrique nous avons fourni toute les informations nécessaires concernant le matériel, la configuration et l'architecture de la solution nécessaires à ce scénario exemple. Avec ces informations, le type de suivi que nous avons activé (valeur par défaut + 10 propriétés + corps de messages de 10Ko) et le débit maximal acceptable obtenu (20 msg/sec) avec une fenêtre de conservation des données DTA de 24 heures, comparez le tout à votre installation et à vos besoins.

  Vous devez être en mesure d’estimer si le débit maximal acceptable de votre solution sera supérieur ou inférieur à ce que nous avons obtenu. Diverses études de cas techniques peuvent également être disponibles, auxquelles vous pouvez comparer votre système.

• Exécutez le système sous la charge MST estimée et surveillez l’indicateur de performance clé. Généralement, pour trouver plus rapidement le débit maximal acceptable, commencez avec la partie élevé du débit maximal acceptable attendu. En commençant par la partie élevée, vous conduisez les indicateurs clés de performance à saturation (en particulier les E/S du disque) plus rapidement que si vous faites la recherche à partir d’une partie inférieure au débit maximal acceptable (c'est-à-dire, au moins une fenêtre de conservation de données).

• Affinez l’estimation et la répétition MST. Observez les résultats que vous avez obtenus dans le test, affinez votre estimation du débit maximal acceptable et recommencez le test à l'aide de la nouvelle estimation.

Voir aussi

Mesure du débit de suivi maximal acceptable
Présentation du comportement des performances de suivi DTA
Conseils et astuces pour trouver le débit maximal acceptable du suivi DTA
Instructions pour le dimensionnement de la base de données des suivis