Vue d’ensemble du scénario de test
Cette rubrique fournit une vue d’ensemble de l’application de test . une description de la méthodologie de test utilisée et répertorie les indicateurs de performance clés (KPI) capturés pendant le test de charge.
Tester l’application
Une application de demande-réponse synchrone a été utilisée pour comparer les performances de BizTalk Server s’exécutant sur Hyper-V à BizTalk Server exécutées sur du matériel physique. Cette application a été utilisée pour illustrer les performances d’une solution BizTalk Server qui a été réglée pour une faible latence. La messagerie à faible latence est essentielle pour certains scénarios, tels que les services bancaires en ligne où un client envoie une demande et attend un message de réponse dans un intervalle très court (par exemple < , 3 secondes).
La figure ci-dessous illustre l’architecture de haut niveau utilisée. Visual Studio Team System (VSTS) 2008 Test Load Agent a appelé une classe de test personnalisée, qui a utilisé le transport WCF pour générer la charge sur BizTalk Server. L’application BizTalk Server dans ce scénario a été exposée via un emplacement de réception WCF-BasicHttp demande-réponse. L’agent de charge de test VSTS 2008 a été utilisé comme client de test en raison de la grande flexibilité qu’il offre, notamment la possibilité de configurer le nombre total de messages envoyés, le nombre de threads simultanés et l’intervalle de veille entre les requêtes envoyées.
Plusieurs ordinateurs de l’agent de charge de test VSTS 2008 peuvent être exécutés en tandem pour simuler des modèles de charge réels. Pour ces tests, les ordinateurs de l’agent de charge de test VSTS 2008 étaient pilotés par un seul ordinateur du contrôleur de l’agent de charge de test VSTS 2008 qui exécutait également BizUnit 3.0. Par conséquent, une charge cohérente a été envoyée aux ordinateurs BizTalk Server physiques et virtuels. Pour plus d’informations sur l’utilisation de VSTS 2008 Test Edition pour générer une charge simulée à des fins de test, consultez https://go.microsoft.com/fwlink/?LinkID=132311.
Tester l’architecture de l’application
Un emplacement de réception WCF-BasicHttp ou WCF-Custom Request-Response reçoit une nouvelle demande CalculatorRequest à partir d’un ordinateur agent de charge de test.
Le composant désassembleur XML promeut l’élément Method dans le document xml CalculatorRequest. L’agent de message envoie le message entrant à la base de données MessageBox (BizTalkMsgBoxDb).
La requête entrante démarre une nouvelle instance de LogicalPortsOrchestration. Cette orchestration utilise un port à liaison directe pour recevoir les messages CalculatorRequest avec la propriété promue Method = « LogicalPortsOrchestration ».
LogicalPortsOrchestration utilise une boucle pour récupérer des opérations et pour chaque élément, il appelle le service web WCF de calculatrice en aval à l’aide d’un port de Solicit-Response logique. Le message de demande pour le service web WCF calculator est créé à l’aide d’un composant d’assistance et publié dans MessageBox.
Le message de demande est consommé par un port d’envoi WCF-BasicHttp.
Le port d’envoi WCF-BasicHttp appelle l’une des méthodes (Ajouter, Soustraire, Multiplier, Diviser) exposées par le service web WCF calculatrice.
Le service web WCF calculator retourne un message de réponse.
Le message de réponse est publié dans MessageBox.
Le message de réponse est retourné à l’appelant LogicalPortsOrchestration. L’orchestration répète ce modèle pour chaque opération dans le document xml CalculatorRequest entrant.
LogicalPortsOrchestration publie le message CalculatorResponse dans messageBox.
Le message de réponse est récupéré par le Request-Response WCF-BasicHttp Emplacement de réception.
Le message de réponse est retourné à l’ordinateur agent de test de charge.
Une capture d’écran de l’orchestration utilisée pendant le test de charge est illustrée ci-dessous :
Notes
À des fins d’illustration, l’orchestration décrite ci-dessous est une version simplifiée de l’orchestration qui a été réellement utilisée pendant le test de charge. L’orchestration utilisée pendant le test de charge comprenait plusieurs étendues, une logique de gestion des erreurs et des types de ports supplémentaires.
Tester l’orchestration des applications
Méthodologie de test
Les tests de performances impliquent de nombreuses tâches, qui, si elles sont effectuées manuellement, sont répétitives, monotones et sujettes aux erreurs. Pour améliorer l’efficacité des tests et assurer la cohérence entre les séries de tests, Visual Studio 2013 Team System (VSTS) Test Edition avec BizUnit 3.0 a été utilisé pour automatiser les tâches requises pendant le processus de test. Les ordinateurs de l’agent de charge de test VSTS 2008 ont été utilisés comme client de test pour générer la charge des messages sur le système et les mêmes types de messages ont été utilisés sur chaque série de tests pour améliorer la cohérence. Le suivi de ce processus fournit un ensemble cohérent de données pour chaque série de tests. Pour plus d’informations sur BizUnit 3.0, consultez https://go.microsoft.com/fwlink/?LinkID=85168. Pour plus d’informations sur Visual Studio 2013 Team System Test Edition, consultez https://go.microsoft.com/fwlink/?LinkID=141387.
Les étapes suivantes ont été automatisées :
Arrêtez les hôtes BizTalk.
Nettoyez les répertoires de test.
Redémarrez IIS.
Nettoyez la base de données messagebox BizTalk Server.
Redémarrez SQL Server.
Effacez les journaux des événements.
Créez un dossier de résultats de test pour chaque exécution afin de stocker les métriques de performances et les fichiers journaux associés.
Démarrez les hôtes BizTalk.
Charger Analyseur de performances compteurs.
Préchauffez l’environnement BizTalk avec une petite charge.
Envoyer via l’exécution représentative.
Écrire des journaux de performances dans un dossier de résultats.
Collectez les journaux d’application et écrivez dans un fichier .csv dans le dossier des résultats.
Exécutez l’outil Analyse des performances des journaux (PAL), les outils Reloger et Analyseur de journaux sur les journaux de performances collectés pour produire des statistiques, des graphiques et des rapports. Pour plus d’informations sur pal, relog et l’analyseur de journal, consultez Annexe D : Outils de mesure des performances.
Notes
Tout le suivi a été désactivé et le travail BizTalk Server SQL Server Agent a été désactivé pendant le test.
Pour s’assurer que les résultats de ce labo ont pu fournir une comparaison des performances de BizTalk Server dans un environnement physique et Hyper-V, les métriques et journaux de performances ont été collectés dans un emplacement centralisé pour chaque série de tests.
Le client de test a été utilisé pour créer un répertoire de résultats unique pour chaque série de tests. Ce répertoire contenait tous les journaux de performances, les journaux des événements et les données associées requises pour le test. Cette approche a fourni les informations nécessaires lorsque l’analyse rétrospective des séries de tests précédentes était nécessaire. À la fin de chaque test, les données brutes ont été compilées dans un ensemble de résultats cohérents et d’indicateurs de performance clés (KPI). La collecte de résultats cohérents pour les machines physiques et virtualisées a fourni les points de comparaison nécessaires entre les différentes séries de tests et différents environnements. Les données collectées sont les suivantes :
Environnement– Pour enregistrer l’environnement sur lequel le test était exécuté, BizTalk Server sur du matériel physique ou BizTalk Server sur Hyper-V.
Numéro de série de tests : Pour identifier de manière unique chaque série de tests
Cas de test : Pour enregistrer l’architecture de la solution BizTalk Server utilisée pendant le test. (Par exemple, orchestration avec ports logiques et orchestration à l’aide d’envois inline)
Date– Pour enregistrer la date et l’heure d’exécution du test
Heure de démarrage : Comme indiqué par le premier agent de test de charge VSTS lancé
Heure d’arrêt : Comme indiqué par le dernier agent de test de charge VSTS à terminer
Durée du test en minutes – Pour enregistrer la durée du test.
Messages envoyés dans le total – Pour enregistrer le nombre total de messages envoyés à partir des ordinateurs de l’Agent de chargement vers les ordinateurs BizTalk Server pendant le test.
Messages envoyés par seconde : Pour enregistrer les messages envoyés par seconde à partir des ordinateurs de l’agent de chargement vers les ordinateurs BizTalk Server pendant le test.
Latence moyenne du client : Pour enregistrer la durée moyenne entre le moment où les clients de l’Agent de charge de test ont lancé une demande et reçu une réponse de la BizTalk Server ordinateurs pendant le test de charge.
Durée moyenne de la demande et de la réponse (ms) – Comme indiqué par le compteur BizTalk :Messaging Latency\Request-Response Latency (s) Analyseur de performances pour bizTalkServerIsolatedHost
Notes
Là où plusieurs hôtes BizTalk virtualisés exécutaient une moyenne de ces compteurs calculés à partir des journaux d’activité a été utilisée.
Orchestrations terminées par seconde : Comme indiqué par le compteur de Analyseur de performances XLANG/s Orchestrations(BizTalkServerApplication)\Orchestrations terminées/s. Ce compteur fournit une bonne mesure du débit de la solution BizTalk Server.
% de messages traités < 3 secondes : pour enregistrer le nombre total de messages traités dans les 3 secondes pendant le test.
Le test de charge VSTS 2008 a été utilisé pour générer une charge cohérente tout au long des tests. Les paramètres de série de tests et le modèle de charge suivants ont été modifiés pendant le test pour ajuster le profil de charge de chaque test :
Tester des paramètres d'exécution
Le paramètre de série de tests suivant a été modifié en fonction du test effectué :
Durée d’exécution : Spécifie la durée d’exécution du test.
Paramètres de la série de tests
Tester des paramètres du modèle
Les paramètres de modèle de test suivants ont été modifiés en fonction du test effectué :
Modèle– Spécifie comment la charge utilisateur simulée est ajustée pendant un test de charge. Les modèles de charge sont basés sur la constante, l’étape ou l’objectif . Tous les tests de charge effectués étaient constants ou pas.
Notes
Tous les tests effectués dans le cadre de ce guide utilisaient un modèle de charge constante ou un modèle de charge d’étape . Les modèles de charge constante et les modèles de chargement par étapes offrent les fonctionnalités suivantes :
- Modèle de charge constante : Le modèle de charge est le même pendant la durée du test, le nombre d’utilisateurs simulés commence à un niveau prédéfini et ne change pas.
- Modèle de chargement d’étape : Le modèle de charge est augmenté pendant la série de tests ; le nombre d’utilisateurs simulés commence à un niveau prédéfini et est incrémenté d’une quantité prédéfinie à intervalles prédéfinis pendant la durée du test.
- Modèle de charge constante : Le modèle de charge est le même pendant la durée du test, le nombre d’utilisateurs simulés commence à un niveau prédéfini et ne change pas.
Nombre d’utilisateurs constants (modèle de charge constante) – Nombre d’utilisateurs virtuels qui génèrent une charge sur l’adresse de point de terminaison spécifiée dans le fichier app.config du projet de test de charge Visual Studio. Cette valeur est spécifiée dans les paramètres de modèle de charge utilisés pour le test de charge.
Nombre d’utilisateurs initial (modèle de chargement d’étape) – Nombre d’utilisateurs virtuels qui génèrent une charge par rapport à l’adresse de point de terminaison spécifiée au début d’un test de modèle de charge d’étape. Cette valeur est spécifiée dans les paramètres de modèle de charge utilisés pour le test de charge.
Nombre maximal d’utilisateurs (modèle de charge d’étape) – Nombre d’utilisateurs virtuels qui génèrent une charge par rapport à l’adresse de point de terminaison spécifiée à la fin d’un test de modèle de charge d’étape. Cette valeur est spécifiée dans les paramètres de modèle de charge utilisés pour le test de charge.
Durée de l’étape (modèle de chargement d’étape) – Nombre de secondes pendant lesquelles les utilisateurs virtuels génèrent une charge par rapport à l’adresse de point de terminaison spécifiée pour une étape de test de charge.
Nombre d’utilisateurs de l’étape (modèle de chargement d’étape) – Nombre d’utilisateurs virtuels à augmenter à chaque étape lors de l’utilisation d’un modèle de charge d’étape.
Paramètres du modèle de test
Pour plus d’informations sur l’utilisation des tests de charge dans Visual Studio 2013, consultez la rubrique Utilisation des tests de charge dans la documentation Visual Studio 2013 Team System à l’adresse https://go.microsoft.com/fwlink/?LinkId=141486.
Indicateurs de performance clés mesurés pendant le test
Les compteurs de Analyseur de performances suivants ont été capturés en tant qu’indicateurs de performance clés (KPI) pour toutes les séries de tests :
Notes
Pour plus d’informations sur l’évaluation des performances avec les compteurs de l’Analyseur de performances, consultez Liste de contrôle : mesure des performances sur Hyper-V.
indicateur de performance clé BizTalk Server
Documents traités par seconde : Tel que mesuré par le compteur BizTalk :Messaging/Documents processed/Sec .
Latence– Tel que mesuré tel que retourné par le Load Test Controller VSTS 2008.
indicateur de performance clé SQL Server
SQL Server utilisation du processeur : mesurée par le compteur SQL\Processor(Total)\%Temps processeur. Ce compteur mesure l’utilisation du processeur de SQL Server traitement sur l’ordinateur SQL Server.
Performances de traitement des commandes Transact SQL : Comme mesuré par le compteur \SQL Server :SQL Statistics\Batch Requests/s. Ce compteur mesure le nombre de lots de commandes Transact-SQL reçus par seconde. Ce compteur est utilisé pour mesurer le débit sur l’ordinateur SQL Server.
Indicateur de performance clé réseau
BizTalk Server débit réseau : tel que mesuré par le compteur de l’analyseur de performances \Network Interface(*)\Bytes Total/s sur les ordinateurs BizTalk Server.
SQL Server débit réseau : mesuré par l’interface réseau SQL\Bytes Total/s (Moy) retourné par le Load Test Controller VSTS 2008.
Indicateur de performance clé de mémoire
Mémoire disponible : Comme mesuré par le compteur \Memory\Available Mbytes pour les différents scénarios.
Spécificités de l’infrastructure physique
Pour chacun des serveurs qui ont été installés, les paramètres suivants ont été ajustés.
Pour tous les serveurs :
Le fichier de pagination a été défini sur 1,5 fois la quantité de mémoire physique allouée. Le fichier de pagination a été défini sur une taille fixe en veillant à ce que la taille initiale et les valeurs maximales soient identiques en Mo.
L’option de performances « Ajuster pour optimiser les performances » a été sélectionnée à partir de l’écran des propriétés système avancées.
Il a été vérifié que le système avait été ajusté pour optimiser les performances des services d’arrière-plan dans la section Options de performances de Propriétés du système.
Windows Server 2008 SP2 a été installé en tant que système d’exploitation invité sur chacune des machines virtuelles.
Windows Update a été correctement exécuté sur tous les serveurs pour installer les dernières mises à jour de sécurité.
Pour SQL Server :
SQL Server a été installé conformément au guide d’installation disponible sur https://go.microsoft.com/fwlink/?LinkId=141021.
SQL Server utilisé avait les LUN SAN configurés conformément au tableau ci-dessous. Les fichiers de base de données et les fichiers journaux ont été séparés entre les lun comme suit pour réduire la contention possible d’E/S de disque :
Le volume Data_Sys a été utilisé pour stocker tous les fichiers de base de données (y compris les bases de données système et BizTalk), à l’exception des bases de données MessageBox et TempDb.
Le volume Log_Sys a été utilisé pour stocker tous les fichiers journaux (y compris les bases de données système et BizTalk Server), à l’exception des bases de données MessageBox et TempDb.
Le volume Data_TempDb a été utilisé pour stocker le fichier de base de données TempDb.
Le volume Logs_TempDb a été utilisé pour stocker le fichier journal TempDb.
Le fichier de base de données MessageBox a été stocké sur le volume Data_BtsMsgBox et le fichier journal a été stocké sur le volume Log_BtsMsgBox.
En outre, un numéro d’unité logique distinct a été fourni pour le fichier journal MSDTC. Sur les systèmes BizTalk à haut débit, il a été démontré que l’activité du fichier journal MSDTC provoque un goulot d’étranglement des E/S s s’il est laissé sur le même lecteur physique que le système d’exploitation.
Nom du volume Fichiers Taille du lun en Go Taille de la partition hôte En Go Taille du cluster Data_Sys Fichiers de données MASTER et MSDB 10 10 64 Ko Logs_Sys Fichiers journaux MASTER et MSDB 10 10 64 Ko Data_TempDb Fichier de données TempDB 50 50 64 Ko Logs_TempDb Fichier journal TempDB 50 50 64 Ko Data_BtsMsgBox Fichier de données BizTalkMsgBoxDb 300 100 64 Ko Logs_BtsMsgBox Fichier journal BizTalkMsgBoxDb 100 100 64 Ko Data_BAMPrimaryImport Fichier de données BAMPrimaryImport 10 10 64 Ko Logs_BAMPrimaryImport Fichier journal BAMPrimaryImport 10 10 64 Ko Data_BizTalkDatabases Autres fichiers de données de base de données BizTalk 20 20 64 Ko Logs_BizTalkDatabases Autres fichiers journaux de base de données BizTalk 20 20 64 Ko N/A Fichier journal MSDTC 5 5 N/A BizTalk Server a été installé conformément aux guides d’installation disponibles sur https://go.microsoft.com/fwlink/?LinkId=128383.
L’outil BizTalk Server Best Practices Analyzer (BPA) a été utilisé pour effectuer la validation de la plateforme une fois le système configuré. BizTalk Server(https://www.microsoft.com/download/details.aspx?id=43382).
Spécificités de la virtualisation
Un seul disque dur virtuel fixe de 50 Go a été utilisé pour héberger le système d’exploitation pour chaque machine virtuelle Hyper-V.
Les disques durs virtuels fixes ont été utilisés à la place de disques durs virtuels de taille dynamique, car ils allouent immédiatement le stockage maximal du disque dur virtuel au fichier sur le lecteur où il est hébergé. Cela réduit la fragmentation du fichier de disque dur virtuel qui se produit sur le lecteur physique où il est hébergé, ce qui améliore les performances d’E/S du disque.
Pour configurer les machines virtuelles, une installation de Windows Server 2008 SP2 édition 64 bits a été effectuée sur un seul disque dur virtuel. Une fois toutes les mises à jour appropriées installées, la machine virtuelle de base a été mise en image à l’aide de l’utilitaire sysprep installé avec Windows Server 2008 SP2, dans le répertoire %WINDIR%\system32\sysprep.
Ce disque dur virtuel de base a ensuite été copié et utilisé comme base pour toutes les machines virtuelles Hyper-V déployées dans l’environnement. Sysprep a été exécuté sur l’image de disque dur virtuel de base pour réinitialiser les identificateurs de sécurité système avant le déploiement de fichiers binaires SQL Server ou BizTalk Server sur le système.
Notes
L’exécution de Sysprep après BizTalk Server a été installée et configurée sur le serveur peut être effectuée à l’aide d’un fichier de réponses Sysprep et de scripts fournis avec BizTalk Server. Ces exemples de scripts sont conçus pour être utilisés avec BizTalk Server installés sur les versions 32 bits et 64 bits de Windows Server 2008 SP2 uniquement. Pour plus d’informations, consultez la documentation en ligne BizTalk Server.
La référence de l’installation de Windows sans assistance est disponible à l’adresse https://go.microsoft.com/fwlink/?LinkId=142364.
Voir aussi
Annexe C : prise en charge de BizTalk Server et de SQL Server par Hyper-V