Optimisations des scénarios Low-Latency pour BizTalk Server
Par défaut, BizTalk Server est optimisé pour le débit plutôt que pour une faible latence. Les optimisations suivantes ont été appliquées à BizTalk Server pour le scénario de test utilisé pour ce guide.
Notes
Ces optimisations amélioreront la latence, mais peuvent le faire à un certain coût par rapport au débit global.
Augmenter la taille de la file d’attente de messages interne de l’hôte BizTalk Server
Chaque hôte BizTalk a sa propre file d’attente interne en mémoire. Augmentez la taille de cette file d’attente de la valeur par défaut de 100 à 1 000 pour améliorer les performances dans un scénario à faible latence. Pour plus d’informations sur la modification de la valeur de la taille de la file d’attente de messages interne, consultez « How to Modify the Default Host Throttling Settings » dans le BizTalk Server d’aide sur https://go.microsoft.com/fwlink/?LinkID=120225.
Réduire la valeur MaxReceiveInterval dans la table adm_ServiceClass de la base de données de gestion BizTalk Server
BizTalk Server utilise un mécanisme d’interrogation pour recevoir des messages de ses files d’attente hôtes dans la boîte de messages. La valeur MaxReceiveInterval dans la table de adm_ServiceClass de la base de données BizTalk Management (BizTalkMgmtDb) est la valeur maximale en millisecondes que chaque hôte BizTalk instance attende jusqu’à ce qu’il interroge le MessageBox. La table adm_ServiceClass contient un enregistrement pour les types de services suivants :
XLANG/S : pour les instances hôtes d’orchestration BizTalk
Messaging InProcess : pour les instances hôtes in-process
MSMQT : pour les instances hôtes de l’adaptateur MSMQT
Messagerie isolé : pour les instances d’hôte hors processus, utilisées par les gestionnaires d’adaptateur de réception HTTP, SOAP et certains gestionnaires d’adaptateurs de réception WCF
Par défaut, cette valeur est définie sur 500 millisecondes, ce qui est optimisé pour le débit plutôt que pour la faible latence. Dans certains scénarios, la latence peut être améliorée en réduisant cette valeur.
Notes
Les modifications apportées à cette valeur ont un impact sur toutes les instances du type de service associé. Par conséquent, veillez à évaluer l’impact sur toutes les instances d’hôte avant de modifier cette valeur.
Cette valeur n’est utilisée que si messagebox ne contient aucun message non traité restant. S’il existe un backlog constant de messages non traités dans la boîte de messages, BizTalk Server tente de traiter les messages sans attendre le délai d’interrogation. Une fois tous les messages traités, BizTalk Server commencez à interroger à l’aide de la valeur spécifiée pour MaxReceiveInterval.
Dans un environnement BizTalk Server avec un rapport élevé entre les instances hôtes et les instances de base de données Messagebox, la diminution de la valeur de MaxReceiveInterval peut entraîner une utilisation excessive du processeur sur l’ordinateur SQL Server qui héberge la base de données Messagebox instance. Par exemple, si MaxReceiveInterval est réduit à une valeur faible (<100) dans un environnement BizTalk Server avec une seule Boîte de messages et > 50 instances hôtes, l’utilisation du processeur sur le SQL Server peut grimper au-dessus de 50 %. Ce phénomène peut se produire parce que la surcharge associée à l’interrogation continue des files d’attente d’hôtes est importante. Si vous réduisez MaxReceiveInterval à une valeur inférieure à 100, vous devez également évaluer l’impact que cela a sur l’utilisation du processeur de votre SQL Server ordinateur.