Scénario 1 : Dimensionnement de la base de données de suivi pour les messages BizTalk simples

Dans le schéma ci-dessous, un message BizTalk entre et sort du serveur BizTalk Server sans être soumis à aucune transformation.

Un message BizTalk Server simple - aucune transformation

Avant d'appliquer la formule décrite dans la section précédente, vous devez rassembler quelques informations concernant le présent scénario. Dans cet exemple, les données sont les suivantes :

• taille du message : 5 Ko ;

• aucune propriété promue ;

• nombre de messages reçus dans une année : 3,5 millions ;

• suivi activé pour tous les événements, ici au nombre de quatre Les événements sont :

  • Réception du message M0

  • Sortie du message M1 provenant du port de réception

  • Réception du message M1 par le pipeline de transmission

  • Sortie du message M2 par le pipeline d'envoi

• création de deux messages dans ce scénario : le message M0 étant le message entrant, il n'est pas créé par BizTalk Server. le message M1 sortant du port de réception et le message M2 sortant du port de transmission sont créés par BizTalk Server.

  L'intégration de ces données à la formule précédemment mentionnée donne le résultat suivant :

[(5*252 bytes) + (10*182 bytes) + (0*5(40 bytes + 0) * 3,500,000]/1024/1024  
[(1620 + 1820 + 0) * 3,500,000]/1024/1024 = 10280.61 MB ~ 10.04 GB per year  

Messages dont la propriété promue est unique

Reprenons l'exemple précédemment mentionné et prenons en compte les nouveaux éléments suivants dans le scénario. Vous souhaitez promouvoir un seul champ, d'environ 10 octets, du message d'origine. La taille maximale d'un champ promu est de 256 caractères, soit environ 256 octets (512 octets s'il s'agit de caractères Unicode).

En tenant compte de ces nouvelles données, l'équation se présente comme suit :

[(2*150 bytes) + (4*230 bytes) + (1*2(52 bytes + 10 bytes)) * 3,500,000]/1024/1024  
[(300 + 920 + 124) * 3,500,000]/1024/1024 = 4486 MB ~ 4.38 GB per year  

Si vous souhaitez promouvoir un autre champ de 10 octets, l'équation est alors la suivante :

[(2*150 bytes) + (4*230 bytes) + ((1*2*(52 bytes + 10 bytes) + (1*2*(52 bytes + 10 bytes)) * 3,500,000]/1024/1024  
[(300 + 920 + 248) * 3,500,000]/1024/1024 = 4899 MB ~ 4.78 GB per year  

Vous pouvez donc constater que lorsqu'une seule propriété de 10 octets est promue dans ce scénario, la taille de la base de données des suivis augmente de 333,79 Mo (environ 0,33 Go) par an.

Deux propriétés de 10 octets promues entraînent donc une augmentation annuelle de l'espace occupé par la base de données des suivis équivalente à 667,58 Mo (environ 0,65 Go).

Messages pour lesquels le suivi du corps des messages est activé

Dans cet exemple, supposons qu'il soit prévu d'activer le suivi du corps des messages. Il faut alors ajouter la seconde équation de suivi des messages comme indiqué dans la section précédente. L'équation se présente comme suit :

[3,500,000 * 4 * 5KB]/1024 = 68359.375 MB ~ 66.75 GB per year  
  

En ajoutant les résultats des deux équations, il est possible d'estimer que la taille de la base de données des suivis augmentera de 54,48 Go à 54,88 Go par an.

Voir aussi

Utilisation de variables de message pour déterminer la taille de la base de données des suivis
Dimensionnement de la base de données des suivis pour suivre les corps de message
Scénario 2 : Dimensionnement de la base de données de suivi des messages dans les orchestrations
Scénario 4 : dimensionnement de la base de données des suivis pour tous les messages
Scénario 3 : Dimensionnement de la base de données de suivi des messages envoyés aux listes de distribution