Lire en anglais

Partager via


Test de l'état de saturation

Les informations contenues dans cette rubrique font référence aux tests expliqués dans Scénarios de test pour la mesure de la MST du moteur.

Origines des événements de saturation

Il existe un certain nombre de scénarios où seulement quelques pics importants (également appelés événements d’inondation) de messages arrivent au système chaque jour. Entre ces pics d'activité, le débit peut être très modeste. Voici quelques exemples de ces scénarios :

  • les opérations sur les actions, à l'ouverture et à la clôture du marché ;

  • les systèmes bancaires, par exemple pendant le rapprochement des transactions en fin de journée.

    D'autres types d'événements peuvent causer des retards similaires à ceux provoqués par les événements de saturation. Par exemple, si l'adresse d'envoi d'un partenaire devient indisponible et que les messages destinés à cette adresse doivent être renvoyés et/ou suspendus, cela peut entraîner une accumulation de travaux en retard. Quand le partenaire est à nouveau connecté, il risque d'y avoir un volume considérable de messages suspendus qu'il faut reprendre, ce qui génère un autre type d'événement de saturation. Le test suivant du système illustre ce fonctionnement :

Simulation d'un événement de saturation

Pour ce test, le système a fonctionné initialement à la moitié environ de son débit maximum et était donc très stable. Ensuite, pour simuler un événement de saturation, l'outil de génération de charge a été configuré afin d'envoyer 410 msg/s environ pendant un temps très court (le même que pour le test de surcharge). Le profil de charge obtenu, qui mesure les messages reçus par seconde et la profondeur du spouleur, est affiché ci-après.

Profil de charge du test de l'état de saturation

Affichage de l’analyseur de performances des BTS06_Floodgate_Load de chargement de la BTS06_Floodgate_Load

Notez que dans les tables de mise en file d'attente, le nombre de messages en attente de traitement augmente très vite pendant l'événement de saturation. Toutefois, l'événement étant relativement court et le taux de réception après l'événement inférieur au taux maximal, les fonctions de nettoyage ont pu s'exécuter et le système a pu récupérer de l'événement sans qu'il soit nécessaire d'interrompre la réception des messages. Pour ce test particulier, qui a duré 45 minutes environ, la base de données MessageBox était hébergée par SQL Server 2005.

Bien sûr, chaque système est différent, et les « valeurs limites » varieront de l'un à l'autre. Le meilleur moyen de vérifier qu'une récupération est possible consiste à faire un test avec une charge représentative avant le passage en production.

Voir aussi

Scénarios de test pour mesurer le débit maximal acceptable du moteur
Utilisation du panneau de configuration pour le réglage des performances de BizTalk Server
Test de surcharge de dépassement
Test de charge maximale