Vue d’ensemble du scénario

Cette rubrique fournit une vue d’ensemble des tests de charge effectués par le groupe de produits BizTalk Server afin d’évaluer la scalabilité des BizTalk Server lors de l’exécution sur du matériel d’entreprise moderne.

Tous les tests ont été effectués dans un environnement isolé à l’aide de matériel dédié. Plus de 200 séries de tests ont été effectuées et tous les résultats ont été validés par le groupe de produits BizTalk Server.

Les tests ont été effectués à l’aide d’un scénario de messagerie et d’un scénario d’orchestration ; les deux scénarios utilisaient l’adaptateur de WCF-NetTcp BizTalk.

Pour évaluer les performances maximales possibles du moteur BizTalk Server, aucun composant de pipeline personnalisé n’a été utilisé, et une seule orchestration très simple a été utilisée pour le scénario d’orchestration. Les optimisations des performances décrites dans Optimisation des performances ont été appliquées à l’environnement et sont entièrement documentées dans Observations et recommandations.

Objectifs de test

Les objectifs du test de charge effectué étaient les suivants :

1. Fournissez des conseils généraux de dimensionnement et de mise à l’échelle pour BizTalk Server :

   1. Quantifier l’impact de l’ajout d’ordinateurs supplémentaires au groupe BizTalk Server. Pour ce test, les performances d’une solution BizTalk Server ont été mesurées lorsque le groupe BizTalk Server exécutait un, deux, trois et quatre ordinateurs exécutant BizTalk Server.

   2. Quantifier l’impact de l’ajout de bases de données BizTalk MessageBox supplémentaires à un groupe BizTalk Server. Pour ce test, les performances d’une solution BizTalk Server ont été mesurées lorsque le groupe a été configuré pour utiliser une base de données MessageBox unique ou quatre bases de données MessageBox.

      Notes

      Le test avec deux bases de données MessageBox n’a pas été effectué, car il y a peu ou pas d’avantages en matière de performances lors de la mise à l’échelle d’une à deux bases de données MessageBox. En fait, la mise à l’échelle d’une à deux bases de données MessageBox peut nuire aux performances. Pour plus d’informations sur le scale-out de MessageBox, consultez Scale-Out du niveau SQL Server.

2. Fournissez des conseils de dimensionnement et de mise à l’échelle pour les scénarios suivants :

   1. WCF-NetTcp scénario de messagerie unidirectionnelle

   2. WCF-NetTcp scénario d’orchestration unidirectionnel

Mesures de test utilisées

BizTalk Server performances ont été mesurées à l’aide des critères suivants :

1. Débit global : mesuré avec les compteurs de performances BizTalk :Messaging(nom d’hôte)\Documents reçus/s et BizTalk :Messaging(nom d’hôte)\Documents traités/s pour les hôtes de réception et de traitement BizTalk Server.

2. Utilisation du processeur : mesurée à l’aide des compteurs de performances \Processor(_Total)\%Processor Time sur les ordinateurs BizTalk Server] et SQL Server. Tous les résultats des tests ont été examinés de manière approfondie et tous les goulots d’étranglement des performances sont décrits dans Observations et recommandations.

Scale-out du niveau de traitement et du niveau base de données

BizTalk Server peut facilement prendre en charge des fonctionnalités de niveau de traitement accrues en ajoutant un ou plusieurs ordinateurs BizTalk Server à un groupe de BizTalk Server existant. BizTalk Server offre des fonctionnalités accrues de niveau base de données grâce à l’ajout de bases de données MessageBox.

Pour fournir des métriques de scale-out pour BizTalk Server, des tests ont été effectués avec un, deux, trois et quatre ordinateursBizTalk Server. Pour illustrer l’impact du scale-out du niveau base de données, ces tests ont été effectués sur des systèmes MessageBox uniques et multi-MessageBox.

Scénarios de test

Le flux de messages à travers l’environnement BizTalk Server pour ces scénarios est décrit en détail ci-dessous.

Scénario de test de messagerie

1. La fonctionnalité de test de charge de Visual Studio 2010 Édition Ultimate génère un message XML et l’envoie à l’ordinateur exécutant BizTalk Server avec le transport NetTcp.

   Notes

   Pour plus d’informations sur le test de charge de Visual Studio 2010 Édition Ultimate, consultez LIEN HYPERTEXTE « » Test de l’application (https://go.microsoft.com/fwlink/?LinkID=208247).

   Pour plus d’informations sur la façon dont nous avons utilisé la fonctionnalité de test de charge de Visual Studio 2010 Édition Ultimate dans notre environnement de test, consultez Utilisation de Visual Studio pour faciliter les tests automatisés.

2. Le message XML est reçu par un emplacement de réception BizTalk Server qui utilise l’adaptateur de réception WCF-NetTcp. L’emplacement de réception est configuré pour utiliser le pipeline PassThruReceive, qui n’effectue aucun traitement du message.

3. Le BizTalk Server gestionnaire de points de terminaison (EPM) publie le message dans la base de données BizTalk MessageBox.

4. Un port d’envoi BizTalk Server qui utilise l’adaptateur d’envoi WCF-NetTcp s’abonne aux messages publiés par l’emplacement de réception et récupère le message à partir de BizTalk MessageBox. Le port d’envoi utilise le pipeline PassThruTransmit, qui n’effectue aucun traitement du message.

5. Le message est remis au service WCF principal par l’adaptateur d’envoi WCF-NetTcp.

Scénario de test d’orchestration

1. La fonctionnalité de test de charge de Visual Studio 2010 Édition Ultimate génère un message XML et l’envoie à l’ordinateur exécutant BizTalk Server à l’aide du transport NetTcp.

2. Le message XML est reçu par un port de réception BizTalk Server qui utilise l’adaptateur de réception WCF-NetTcp. Le port de réception est configuré pour utiliser le pipeline PassThruReceive, qui n’effectue aucun traitement du message.

3. Le message est remis à une orchestration simple, qui se compose uniquement d’un port de réception (lié au port de réception WCF à l’étape 2) et d’un port d’envoi (lié au port d’envoi WCF de l’étape 4). Les variables de message sont « non typées », ce qui signifie qu’elles utilisent un « type de message » de « System.XML . XmlDocument ». L’orchestration reçoit simplement le message via son port de réception et envoie le message via son port d’envoi. Aucun traitement des messages n’est effectué.

4. Un port d’envoi unidirectionnel BizTalk Server qui utilise l’adaptateur d’envoi WCF-NetTcp s’abonne aux messages publiés par l’orchestration et récupère le message à partir de BizTalk MessageBox. Le port d’envoi utilise le pipeline PassThruTransmit, qui n’effectue aucun traitement du message.

5. Le message est remis au service WCF principal par l’adaptateur d’envoi WCF-NetTcp.

Configuration matérielle

Diagramme et spécifications du matériel de laboratoire

La configuration matérielle utilisée pour le labo est illustrée ci-dessous. Pour prendre en charge facilement le scale-out des niveaux de traitement et de base de données, le matériel de laboratoire suivant a été utilisé :

• Deux ordinateurs Hewlett Packard DL-380 de classe Entreprise et deux ordinateurs Dell R710 de classe Entreprise pour le niveau de traitement BizTalk Server.

• Quatre ordinateurs Dell R900 de classe Entreprise pour la couche base de données, afin de fournir une fonctionnalité multi-MessageBox.

  Un diagramme du matériel utilisé dans le labo est fourni ci-dessous :

  

  Le tableau suivant fournit des informations plus spécifiques sur le matériel utilisé dans le labo.

Configuration réseau de la zone de stockage

Le diagramme suivant illustre la configuration du réseau de zone de stockage (SAN) utilisée pour l’environnement lab.

Configuration SAN d’EMC CLARiiON CX4-960

Il est important de déterminer le débit maximal accessible d’un SAN et de comparer cette valeur à la charge attendue par rapport au SAN en production. Cela permet d’éviter des dépenses imprévues pour le matériel SAN lors du déplacement de votre application d’un environnement de test/assurance qualité (QA) vers un environnement de production. Par exemple, le débit maximal disponible pour le SAN peut être plus que suffisant pour votre application dans un environnement de test bac à sable (sandbox). Toutefois, si d’autres applications serveur utilisent le SAN en production, le débit SAN disponible peut être insuffisant et peut devenir un goulot d’étranglement.

Lorsque vous évaluez les performances de votre SAN, tenez compte des éléments suivants :

1. Quel est le débit maximal accessible du SAN ? : cela est mesuré à l’aide du plus petit dénominateur commun, en termes de débit, de l’adaptateur de bus hôte (HBA) du serveur, du débit switch-SAN et de la vitesse des cartes contrôleur SAN.

2. Quelles autres applications utiliseront le SAN en production ? – Déterminez quelles autres applications utiliseront le SAN dans l’environnement de production. Si d’autres applications de base de données ou d’E/S intensives telles que Exchange Server utiliseront le SAN en production, la quantité de débit SAN disponible pour votre ordinateur exécutant BizTalk Server sera réduite en conséquence.

   Pour l’environnement lab, un SAN dédié a été utilisé. Chacun des quatre ordinateurs SQL Server était connecté au commutateur SAN avec deux adaptateurs de bus hôte (HBA) de 4 Gbits/s, offrant un débit potentiel total de 8 Gbits/s par serveur. Le SAN avait deux processeurs de service, et chaque processeur de service avait deux ports front-end attachés au commutateur fibre, fournissant un débit potentiel total de 16 Gbits/s entre le SAN et le commutateur.

   La configuration lun suivante a été utilisée pour chacun des quatre ordinateurs exécutant SQL Server dans l’environnement de test.

Résultats des tests SQLIO

Nous avons utilisé l’outil SQLIO pour évaluer et mesurer la capacité d’entrée/sortie de la configuration du réseau de zone de stockage (SAN) utilisée dans notre environnement lab. Comme le nom de l’outil l’indique, SQLIO est un outil précieux pour mesurer l’impact des E/S du système de fichiers sur les performances de SQL Server.

Pour mesurer la capacité d’entrée/sortie de la configuration du réseau de zone de stockage (SAN) pour les applications de base de données SQL Server, consultez Analyse des caractéristiques d’E/S et dimensionnement des systèmes de stockage pour SQL Server applications de base de données.

Pour notre test SQLIO, l’utilitaire sqlio.exe émet des demandes de lecture 8K à partir de 8 threads et maintient une profondeur de file d’attente d’E/S de 8. Nous avons utilisé les paramètres suivants :

• Tous les tests ont utilisé 8 threads de traitement, chacun s’exécutant pendant 60 secondes.

• 8 Ko d’écritures aléatoires dans les fichiers de données.

• 8 Ko de lectures aléatoires dans les fichiers de données.

• Tous les fichiers sont dimensionnés à 25 Go.

• Les lecteurs de disque à évaluer sont les lecteurs H :, I :, J :et K.

Les lignes de commande SQLIO utilisées sont les suivantes :

• Pour les lectures : sqlio -kR -s60 -frandom -o8 -t8 -b8 -LS -FParam.txt

• Pour les écritures : sqlio -kW -s60 -frandom -o8 -t8 -b8 -LS -FParam.txt

Le fichier Param.txt contient les éléments suivants :

• Nombre de lecteurs : H :,I :,J :, et K

• Emplacement physique des fichiers de test :

  • H :\testfile.dat 2 0x0 25000

  • I :\testfile.dat 2 0x0 25000

  • J :\testfile.dat 2 0x0 25000

  • K :\testfile.dat 2 0x0 25000

Le tableau suivant répertorie les résultats des tests :

• 8 Ko de lectures aléatoires à partir de fichiers de test de 25 Go simultanément sur les LUN H :, I :, J :, K : (les LUN utilisés pour tous nos fichiers de base de données)

  Opérations d’entrée/sortie par seconde (IE/s)	Mégaoctets par seconde (Mo/s)	Latence moyenne
  10662.67	83.30	5 ms

• Écritures aléatoires de 8 Ko dans des fichiers de test de 25 Go simultanément sur les LUN H :, I :, J :, K : (les LUN utilisés pour tous nos fichiers de base de données)

  Opérations d’entrée/sortie par seconde (IE/s)	Mégaoctets par seconde (Mo/s)	Latence moyenne
  31527.95	246.31	1 ms

Voir aussi

Mise à l’échelle d’un environnement BizTalk Server de production