Test des scénarios de mesure du débit maximal acceptable du moteur
Cette section décrit un scénario de test qui a été implémenté pour mesurer l'effet produit par le fait de porter un système BizTalk à trois niveaux de charge différents :
Test de charge durable. Aux fins de ces tests, la charge durable est décrite dans la rubrique Qu’est-ce que les performances durables ?.
Test de charge overdrive. Une surcharge se définie comme une charge homogène supérieure au débit maximal acceptable.
Test de charge du canal d’inondation. Un état de saturation se définit comme une charge faible avec des pics de charge intermittents supérieurs au débit maximal acceptable.
Cette rubrique décrit la configuration matérielle de test, les scénarios de test, et présente les découvertes effectuées au cours de chaque test.
Important
Les lecteurs doivent savoir que les informations contenues dans cette section 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.
Configuration système de test
Le matériel suivant a été utilisé pour ce scénario de test :
Six serveurs BizTalk. Chacun est équipé de doubles processeurs de 3 GHz et de 2 Go de RAM. Chaque serveur utilise des disques locaux. Deux des serveurs BizTalk Server sont configurés avec une instance de l'hôte de réception, deux sont configurés avec une instance de l'hôte émetteur, et deux autres encore sont configurés avec une instance de l'hôte utilisé pour traiter les orchestrations.
Un SQL Server pour la base de données MessageBox master et les bases de données non MessageBox. Équipé de huit processeurs de 2 GHz et de 4 Go de RAM. Ce serveur est connecté à un sous-système de disque SAN rapide par une fibre. La publication des messages est désactivée.
Trois serveurs SQL pour les bases de données Messagebox qui sont publiées sur. Équipés de quatre processeurs de 2 GHz et de 4 Go de RAM. Ces serveurs sont connectés à un sous-système de disque SAN rapide par une fibre. Les fichiers journaux de données et de transactions des bases de données MessageBox se trouvent sur des numéros d'unité logique (LUN) réseau SAN.
Charger l’ordinateur client du pilote. Équipé de doubles processeurs de 3 GHz et de 2 Go de RAM. Ce serveur a été utilisé pour générer la charge de test du système BizTalk.
La topologie utilisée pour les tests de charge est illustrée ci-dessous.
Topologie utilisée pour les tests de charge
Scénario de test
Le scénario de test est très simple. L'outil de génération de charge, LoadGen 2007, a été installé sur le serveur du gestionnaire de charge et a été utilisé pour envoyer des copies d'un fichier aux partages surveillés par l'adaptateur FILE. L'outil de génération de charge répartit équitablement des copies de l'instance du fichier d'entrée entre les partages de fichiers.
Notes
Téléchargez LoadGen. Pour plus d’informations sur l’utilisation de LoadGen avec l’adaptateur MSMQ, consultez Utilisation de LoadGen 2007 avec MSMQ.
L'adaptateur BizTalk FILE est configuré pour contrôler les partages de fichiers et pour publier les messages dans le MessageBox. Une orchestration simple qui contient seulement une forme Réception et une forme Envoi souscrit au message publié. Les messages qui sont republiés par l'orchestration dans le MessageBox sont récupérés par un port d'envoi de fichier, puis envoyés à un partage commun, défini sur le SAN. Les fichiers arrivant à la sortie du SAN sont supprimés immédiatement pour éviter l'accumulation de fichiers sur le partage pendant des tests longs.
Quatre hôtes ont été définis pour le scénario : pour l'emplacement de réception, les orchestrations, le port d'envoi et le suivi. Afin d'observer le comportement de journalisation du moteur, le suivi est complètement arrêté pendant les tests. Par défaut, le suivi est activé uniquement pour les pipelines et les orchestrations ; le suivi a donc été désactivé explicitement dans l'Administrateur BizTalk pour l'orchestration et le pipeline utilisés.
Aucune instance de l'hôte de suivi n'a été créée depuis que le suivi a été désactivé afin d'isoler le comportement principal MessageBox pour ces tests.
Un schéma simple a été utilisé et les fichiers d'instance utilisés pour le test étaient tous de 10 Ko. Le pipeline XMLReceive a été utilisé pour les documents entrants et aucun composant de mappage ou sortant n'a été utilisé pour conserver le scénario de test simple et pour orienter les observations sur le comportement de MessageBox.
Paramètres mesurés dans le test
Les paramètres suivants ont été mesurés au cours de ce test :
Principaux paramètres mesurés au cours du test
Les paramètres suivants sont les principaux indicateurs servant à mesurer le débit maximal acceptable :
Backlog MessageBox mesuré par le compteur Spool Size disponible avec l’objet de performance BizTalk :MessageBox :General Counters . Il s'agit d'un indicateur clé de durabilité. Le nombre de messages accumulés dans le MessageBox ne peut pas augmenter indéfiniment sans que cela entraîne le moindre problème. Le développement de cette accumulation dans la base de données MessageBox, contrôlé en permanence, sert à évaluer la durabilité.
La table MessageBox nommée spool contient un enregistrement pour chaque message dans le système (actif ou en attente d’être récupéré par la mémoire). L'analyse du nombre de lignes de cette table et du nombre de messages reçus par seconde, bien qu'entraînant une hausse de la charge système, fournit un moyen facile pour mesurer le débit durable maximal. Cette mesure est également appelée profondeur de la table de spoule ou profondeur de la bobine.
Nombre de documents reçus par seconde, mesuré par le compteur Documents reçus/s disponible avec l’objet de performances BizTalk :Messaging .
Paramètres secondaires mesurés au cours du test
Les paramètres suivants sont des indicateurs secondaires qui peuvent être évalués pour mesurer le débit maximal acceptable. Ces paramètres peuvent avoir un impact sur les indicateurs principaux que sont la profondeur du spouleur et le nombre de documents reçus par seconde.
Temps d’inactivité du disque physique pour le disque de données messageBox et le disque de fichier de transaction mesuré par le compteur %Temps d’inactivité disponible avec l’objet de performances LogicalDisk .
Utilisation du processeur (%) pour le serveur MessageBox, telle que mesurée par le compteur %Temps processeur disponible avec l’objet de performances processeur .
Délai d’expiration des verrous par seconde sur la base de données MessageBox, mesuré par le compteur Lock Timeouts/s disponible avec l’objet de performance SQLServer :Locks .
Durée (en secondes) de la dernière exécution du travail d'Agent SQL qui nettoie les tables de zone de message associées aux messages supprimés. Cela est mesuré par le compteur MsgBox Nettoyage Msg(Purger les travaux) disponible avec l’objet de performance BizTalk :MessageBox :General Counters .
Durée (en secondes) de la dernière exécution du travail d'Agent SQL qui nettoie les tables de zone de message associées aux parties de messages supprimées. Cela est mesuré par le compteur MsgBox Parts Cleanup(Purgez les travaux) disponible avec l’objet de performance BizTalk :MessageBox :General Counters .
Lors du test effectué pour déterminer le débit maximal acceptable, la charge en entrée a été augmentée jusqu'au point à partir duquel la table de mise en file d'attente a commencé à croître indéfiniment.
Notes
Si vous ne parvenez pas à générer assez de charge pour provoquer un tel accroissement, cela signifie simplement que la partie la plus lente de votre système se trouve sur le côté de réception et non sur le côté de traitement/d'envoi.