Recommandations pour le test des performances du moteur
Suivez les directives ci-après lorsque vous testez les performances du moteur BizTalk :
Connaître votre profil de comportement de charge Comme l’illustrent les trois tests de charge, il est essentiel de connaître le profil de votre charge en termes de messages traités au fil du temps. Mieux ce profil est dessiné, plus précisément vous pourrez tester et ajuster la capacité du système. Si vous ne connaissez que le débit maximal requis, l'approche la plus classique consiste à échelonner votre système de sorte que le débit maximal réalisable soit supérieur ou égal à la charge maximale. Toutefois, si vous savez que la charge a des hauts et des bas prévisibles, vous pouvez davantage optimiser votre système de sorte qu'il récupère entre ces pics ; ainsi, vous pouvez réaliser un déploiement global à petite échelle et à moindre coût.
Tester les performances plus tôt Évitez de tomber dans le piège d’investir beaucoup d’efforts dans la conception et le test des fonctionnalités de votre solution, tout en attendant la dernière minute pour tester les performances sur le matériel de production. Exécutez, dès que possible dans votre cycle de développement, des tests de performance sur votre système qui simulent le profil de charge attendu. Ainsi, vous saurez très tôt si vous devez modifier votre conception ou votre architecture pour atteindre vos objectifs et vous pourrez faire les ajustements et les tests nécessaires.
Émuler votre profil de charge attendu lors du test des performances Il existe deux composants principaux :
émulez le profil de charge dans le temps ;
exécutez le test suffisamment longtemps pour évaluer sa faisabilité.
Si, comme cela est fréquemment le cas, vous avez des cycles quotidiens en nature, prévoyez d'exécuter des tests de performance pendant au moins un jour pour valider leur faisabilité. Plus vous exécutez les tests longtemps, mieux c'est.
Émuler la configuration de production Par exemple, le nombre et le type de ports, l’hôte et l’hôte instance configuration, la configuration de la base de données et la configuration de l’adaptateur. Ne croyez pas que les modifications de la configuration n'auront pas d'impact significatif sur les performances.
Utiliser des messages réels La taille des messages et la complexité des messages affectent les performances. Par conséquent, vérifiez et testez avec les mêmes schémas et instances de message que vous prévoyez de voir en production.
Émuler vos opérations normales pendant les tests de performances Bien que les tests de charge ne les aient pas inclus, les activités d’opérations standard telles que les requêtes de base de données périodiques, les sauvegardes et le vidage affectent votre débit durable. Assurez-vous donc d’effectuer ces tâches pendant vos exécutions de tests de performances et de capacité. Ceci inclut le suivi DTA et BAM si vous comptez les utiliser en production.
La vitesse du sous-système d’E/S pour messageBox est un facteur clé de réussite Les tests de charge effectués utilisent un réseau de zone de stockage rapide pour les fichiers de base de données MessageBox dédiés à cette build-out. Même dans ce cas, les travaux de nettoyage ont pu faire passer le temps d’inactivité à près de zéro pour le fichier de données SQL. Le sous-système d'E/S constitue souvent un goulot d'étranglement dans les systèmes de production. La stratégie classique d'optimisation des E/S SQL consiste à placer le ou les fichiers de base de données et le ou les fichiers journaux sur des lecteurs physiques distincts, dans la mesure du possible.
Vérifiez que l’Agent SQL est en cours d’exécution sur tous les serveurs MessageBox De toute évidence, les travaux de nettoyage ne s’exécuteront jamais si SQL Agent n’est pas en cours d’exécution. Assurez-vous donc qu’ils sont en cours d’exécution.
La profondeur du pool est un indicateur clé Quels que soient les autres indicateurs, cette mesure vous permettra d’évaluer rapidement et facilement si votre système est surmené ou non.