Examen des goulots d’étranglement
Cette rubrique décrit un processus recommandé pour examiner les goulots d’étranglement.
Quelle est la source du problème ?
La source du goulot d’étranglement peut être liée au matériel ou aux logiciels. Lorsque les ressources sont sous-utilisées, il s’agit généralement d’une indication d’un goulot d’étranglement. Les goulots d’étranglement peuvent être causés par des limitations matérielles, par des configurations logicielles inefficaces ou par les deux.
L'identification des goulots d'étranglement est un processus incrémentiel, où l'élimination d'un goulot d'étranglement peut conduire à la découverte du goulot suivant. L'objectif de cette rubrique est de présenter la méthode qui permet d'identifier et d'éliminer ces goulots d'étranglement. Il est possible pour un système de fonctionner avec des pics d'activité sur de courtes périodes. Toutefois, pour un débit acceptable constant, le système ne peut pas fonctionner plus vite que le plus lent de ses composants.
Utilisation d’une approche itérative pour tester
Des goulots d’étranglement peuvent se produire aux points de terminaison (entrée/sortie) du système ou au milieu (orchestration/base de données). Une fois le goulot d’étranglement isolé, utilisez une approche structurée pour identifier la source. Une fois le goulot d’étranglement allégé, il est important de mesurer à nouveau les performances pour s’assurer qu’un nouveau goulot d’étranglement n’a pas été introduit ailleurs dans le système.
Le processus d’identification et de résolution des goulots d’étranglement doit être effectué de manière itérative. Variez un seul paramètre à la fois, répétez exactement les mêmes étapes pendant chaque série de tests, puis mesurez les performances pour vérifier l’impact de la modification unique. Faire varier plusieurs paramètres simultanément pourrait avoir pour effet de masquer l'impact d'une modification.
Par exemple, la modification du paramètre 1 peut améliorer les performances. Toutefois, la modification du paramètre 2 conjointement avec la modification du paramètre 1 peut avoir un effet néfaste et nier les avantages de la modification du paramètre 1. Cela conduit à un effet net zéro et aboutit à un faux négatif sur l’effet de la variation du paramètre 1 et un faux positif sur l’effet de la variation du paramètre 2.
Test de cohérence
La mesure des caractéristiques de performances après la modification des paramètres doit être effectuée pour valider l’effet de la modification.
Matériel- Utilisez un matériel cohérent, car la variation du matériel peut entraîner un comportement incohérent et produire des résultats trompeurs. Par exemple, vous n’utiliserez pas d’ordinateur portable pour tester les performances d’une solution BizTalk.
Durée de la série de tests - Mesurez les performances pendant une période minimale fixe pour vous assurer que les résultats sont durables. L’exécution de tests pour des périodes plus longues garantit également que le système a traversé la période initiale d’échauffement/de montée en puissance, au cours de laquelle tous les caches sont remplis, où les tables de base de données ont atteint le nombre attendu et où la limitation a suffisamment de temps pour réguler le débit une fois que les seuils prédéfinis sont atteints. Cette approche facilite la recherche du débit durable optimal.
Paramètres de test – Ne modifiez pas les paramètres de test d’une série de tests à l’autre. Par exemple, changer la complexité d'un mappage et/ou les tailles de document peut entraîner des débits et des temps de latence différents.
État propre - Une fois le test terminé, assurez-vous que l’état de l’environnement de test est propre avant d’exécuter le test suivant. Par exemple, les données historiques peuvent s’accumuler dans la base de données affectant le débit d’exécution. Le recyclage des instances de service permet de libérer des ressources mises en cache telles que la mémoire, les connexions aux bases de données et les threads. Dans votre environnement de test, vous pouvez créer et exécuter la procédure stockée bts_CleanupMsgbox comme décrit dans Comment vider manuellement les données de la base de données MessageBox dans un environnement de test (https://go.microsoft.com/fwlink/?LinkId=158064). Ce script est destiné à renvoyer votre environnement de test BizTalk Server à un état nouveau en ce qui concerne la zone de message entre les exécutions. Le script supprime toutes les instances en cours d’exécution et toutes les informations sur ces instances, y compris l’état, les messages et les abonnements, mais laisse tous les abonnements d’activation afin que vous n’ayez pas à réinscrire vos orchestrations ou à envoyer des ports. Notez que cet outil n’est pas pris en charge sur les systèmes de production.
Test et paramétrage des performances - L’objectif de cette catégorie de test est d’optimiser les performances et le débit de votre application et de trouver le débit maximal durable (MST) de votre système. Pour plus d’informations sur la planification et la mesure des performances maximales durables, consultez Planification des performances soutenues (https://go.microsoft.com/fwlink/?LinkId=158065) et Qu’est-ce que la performance durable ? (https://go.microsoft.com/fwlink/?LinkId=132304).
Le MST est la charge de trafic de messages la plus élevée qu’un système peut gérer indéfiniment dans un environnement de production. Toutes les applications BizTalk doivent être testées pour les performances et le débit avant de passer en production. Au minimum, vous devez exécuter un ensemble représentatif de cas de test qui représentent les scénarios d’utilisation les plus courants. Nous vous recommandons de tester les charges attendues et les charges maximales dans un environnement distinct qui correspond aux caractéristiques de l’environnement de production. Tous les services standard d’entreprise doivent être installés et en cours d’exécution dans cet environnement, tels que les agents de surveillance et les logiciels antivirus.
Nous vous recommandons également de tester les nouvelles applications BizTalk sur le même matériel en production avec les autres applications BizTalk en cours d’exécution. Ces autres applications BizTalk mettent une charge supplémentaire sur les BizTalk Server, les SQL Server, les E/S réseau et les E/S de disque. En outre, une application BizTalk peut entraîner une limitation d’une autre application (lorsque la profondeur de la bobine devient trop importante, par exemple). Toutes les applications BizTalk doivent faire l’objet d’un test de performances/de contrainte avant de passer en production. En outre, vous devez déterminer le temps nécessaire au système pour récupérer des charges de pointe. Si le système ne récupère pas entièrement d’une charge de pointe avant le pic de charge suivant, vous rencontrez un problème. Le système prendra de plus en plus de retard et ne pourra jamais se rétablir complètement.
Attentes : débit et latence
Vous pouvez vous attendre à une certaine quantité de débit et/ou de latence à partir du système déployé. La tentative d’obtenir un débit élevé et une faible latence simultanément place des demandes opposées sur le système. Vous pouvez vous attendre à un débit optimal avec une latence raisonnable. À mesure que le débit s’améliore, la contrainte (par exemple, une consommation plus élevée du processeur, une contention d’E/S disque plus élevée, une pression de mémoire et une contention de verrouillage plus importante) sur le système augmente. Cette situation peut avoir un impact négatif sur la latence. Pour découvrir la capacité optimale d’un système, nous vous recommandons d’identifier et de réduire les goulots d’étranglement.
Les instances terminées résidant dans la base de données peuvent entraîner des goulots d’étranglement. Lorsque des goulots d’étranglement se produisent, les performances peuvent se dégrader. Donner au système suffisamment de temps pour vider peut aider à résoudre le problème. Il est important de découvrir la cause de l’accumulation du backlog et d’aider à résoudre le problème.
Pour découvrir la cause du backlog, vous pouvez analyser les données historiques et surveiller les compteurs de performances (pour découvrir les modèles d’utilisation et diagnostiquer la source du backlog). En règle générale, des backlogs peuvent se produire lorsque de grands volumes de données sont traités par lots tous les soirs. Vous trouverez peut-être utile de découvrir la capacité du système et sa capacité à récupérer à partir d’un backlog. Ces informations peuvent vous aider à estimer la configuration matérielle requise pour gérer les scénarios de surdrive et la quantité de mémoire tampon à prendre en charge au sein d’un système pour gérer les pics de débit imprévus.
La surveillance des compteurs de performances peut aider à identifier les goulots d’étranglement potentiels qui pourraient se produire au moment de l’exécution. Toutefois, lorsque nous pensons que le responsable du goulot d’étranglement du processeur ou de la mémoire peut être l’un des composants personnalisés qui composent la solution, nous vous recommandons vivement d’utiliser des outils de profilage tels que Visual Studio Profiler ou ANTS Performance Profiler pendant un test de performances pour affiner et individuer avec certitude la classe qui génère le problème. De toute évidence, le profilage d’une application interfère avec les performances. Par conséquent, ces tests doivent se concentrer sur l’individualisation des composants qui provoquent la consommation de mémoire, l’utilisation du processeur ou la latence, et les chiffres collectés pendant ces tests doivent être ignorés.
L’optimisation du système pour un débit optimal durable nécessite une compréhension approfondie de l’application déployée, des forces et des faiblesses du système et des modèles d’utilisation du scénario spécifique. La seule manière de découvrir les goulots d'étranglement et de prévoir avec certitude le débit durable optimal consiste à effectuer un test rigoureux d'une topologie se rapprochant le plus de celle qui sera utilisée en production. Lors de l’exécution de tests de charge et de contrainte par rapport à un cas d’usage donné, il est essentiel d’isoler des artefacts uniques (emplacements de réception, ports d’envoi, orchestrations) dans des instances hôtes distinctes et de définir les compteurs appropriés à l’intérieur de l’outil d’analyse de performances pour limiter la cause d’un goulot d’étranglement.
D’autres rubriques de cette section vous guident tout au long du processus de définition de cette topologie et fournissent des conseils sur la façon de réduire et d’éviter les goulots d’étranglement.
Mise à l'échelle
Des goulots d’étranglement peuvent se produire à différentes étapes d’une topologie déployée. Certains goulots d’étranglement peuvent être résolus en effectuant un scale-up ou un scale-out de l’environnement. Le scale-up est le processus de mise à niveau de l’ordinateur existant. Par exemple, vous pouvez mettre à niveau un ordinateur BizTalk Server d’un ordinateur à quatre processeurs vers un ordinateur à huit processeurs, en remplaçant les processeurs existants et en ajoutant davantage de RAM. De cette façon, vous pouvez accélérer les tâches gourmandes en ressources, telles que l’analyse et le mappage de documents. Le scale-out est le processus d’ajout de serveurs à votre déploiement. La décision de scale-up ou de scale-out dépend du type de goulot d’étranglement et de l’application en cours de configuration. Une application doit être créée à partir de la base pour pouvoir tirer parti d’un scale-up ou d’un scale-out. Les conseils suivants expliquent comment modifier les topologies de déploiement matériel en fonction des goulots d’étranglement rencontrés.
La montée en puissance signifie exécuter une solution BizTalk sur du matériel mis à niveau (par exemple, en ajoutant le processeur et la mémoire). Vous devez examiner le scale-up lorsque 1) le scale-out est trop coûteux ou 2) le scale-out n’aidera pas à résoudre un goulot d’étranglement. Par exemple, vous pouvez réduire considérablement le temps consacré à la transformation et au traitement d’un message volumineux si vous exécutez la tâche sur un ordinateur plus rapide.
Le scale-out de la plateforme d’application consiste à ajouter des nœuds BizTalk au groupe BizTalk Server et à les utiliser pour exécuter une ou plusieurs parties de la solution. Vous devez examiner la mise à l’échelle lorsque 1) vous devez isoler les hôtes d’envoi, de réception, de traitement et de suivi ou 2) lorsque la mémoire, les E/S ou les ressources d’E/S réseau sont maximales pour un seul serveur. La charge peut être répartie sur plusieurs serveurs ; Toutefois, l’ajout de nouveaux nœuds au groupe BizTalk Server peut augmenter la contention de verrous sur la base de données MessageBox.
Alors, devez-vous effectuer un scale-up ou un scale-out ? La mise à l’échelle de votre plateforme peut réduire la latence d’une solution BizTalk, car elle accélère l’exécution des tâches uniques (par exemple, le mappage de messages). La mise à l’échelle peut améliorer la durée maximale de la mise à l’échelle et la scalabilité de votre solution BizTalk, car elle vous permet de répartir la charge de travail sur plusieurs machines.