Bonnes pratiques pour éviter les goulots d’étranglement
Bien que les paramètres par défaut dans BizTalk Server fournissent des performances optimales pour de nombreuses configurations matérielles et logicielles, dans certains scénarios, il peut être utile de modifier les paramètres ou la configuration de déploiement. Lorsque vous configurez BizTalk Server, tenez compte des instructions de performances suivantes :
Pour éviter la contention de ressources, isolez la réception, l’orchestration et l’envoi sur des hôtes distincts. Pour réduire au maximum les conflits, séparez le service de suivi des autres hôtes.
Si le traitement du processeur sur l’ordinateur exécutant BizTalk Server est le goulot d’étranglement, effectuez un scale-up de l’ordinateur exécutant BizTalk Server en incluant des processeurs supplémentaires ou en effectuant une mise à niveau vers des processeurs plus rapides.
Instructions relatives au serveur SQL Server
Tenez compte des instructions de performances suivantes lors de la configuration de Microsoft SQL Server avec BizTalk Server :
Utilisez, autant que possible, un sous-système de disque rapide avec le serveur SQL Server. Utilisez un tableau redondant de disques indépendants de type 10 (RAID10/0+1) ou un réseau de zone de stockage (SAN) avec une alimentation de sauvegarde.
Isolez chaque base de données MessageBox sur un serveur distinct de la base de données de suivi BizTalk (BizTalkDTADb). Pour les déploiements plus petits si des ressources processeur sont disponibles, il peut être suffisant d’isoler la base de données MessageBox sur un disque physique distinct de la base de données BizTalk Tracking.
La base de données MessageBox principale peut être le goulot d’étranglement dû à la saturation du processeur ou à la latence des opérations de disque (longueur moyenne de la file d’attente du disque). Si le traitement du processeur est le goulot d’étranglement, ajoutez des processeurs d’UC au MessageBox principal. Si ce n’est pas le cas, essayez de désactiver la publication sur la base de données MessageBox master. De cette façon, la base de données MessageBox master peut gérer plus efficacement le routage des messages vers les autres bases de données MessageBox. L’option permettant de désactiver la publication est valide lorsque vous utilisez plusieurs bases de données MessageBox.
Si les opérations sur disque constituent le goulot d’étranglement, déplacez la base de données BizTalk Tracking vers un ordinateur SQL Server dédié et/ou un disque dédié. Si le traitement du processeur et les opérations sur disque sur la base de données MessageBox principale ne sont pas le goulot d’étranglement, vous pouvez créer de nouvelles bases de données MessageBox sur le même ordinateur SQL Server pour tirer parti de votre matériel existant.
Suivez les recommandations de l’article Optimisation des groupes de fichiers pour les bases de données2afin d’isoler les fichiers journaux de transactions et de données des bases de données MessageBox et BizTalk Tracking sur des disques physiques distincts.
Allouez suffisamment d’espace de stockage pour les fichiers de données et les fichiers journaux. Sinon, SQL Server consommera automatiquement tout l’espace disponible sur les disques où les fichiers journaux sont conservés. La taille initiale des fichiers journaux dépend des exigences spécifiques de votre scénario. Faites une estimation de la taille moyenne des fichiers dans votre déploiement en fonction des résultats des tests et ajustez l'espace de stockage avant d'implémenter votre solution.
Allouez suffisamment d’espace de stockage pour les bases de données à utilisation élevée sur disque, telles que MessageBox, HAT (Health and Activity Tracking) et Bam (Business Activity Monitoring). Si votre solution utilise le protocole de messagerie BizTalk Framework, prévoyez un espace de stockage suffisant pour la base de données de configuration BizTalk (BizTalkMgmtDb).
En fonction des besoins de l’entreprise, tels que les périodes de conservation des données et le volume des données traitées dans votre scénario, configurez la tâche « Archive et purge de d’AD » SQL Server Agent sur la base de données HAT-Tracking afin que la base de données bizTalk Tracking ne grossisse pas trop. La croissance de cette base de données peut dégrader les performances, car l’atteinte de la pleine capacité de la base de données impose une limite au taux d’insertion des données. Cela est particulièrement vrai lorsqu’une base de données BizTalk Tracking prend en charge plusieurs bases de données MessageBox.
Effectuez un scale-up des serveurs hébergeant les bases de données MessageBox et BizTalk Tracking s’ils constituent le goulot d’étranglement. Vous pouvez mettre à l’échelle le matériel en ajoutant des processeurs, en ajoutant de la mémoire, en effectuant une mise à niveau vers des processeurs plus rapides et en utilisant des disques dédiés à haut débit.
Le fractionnement des fichiers TempDB entre plusieurs fichiers peut résoudre les problèmes de performances liés aux opérations d’E/S. En règle générale, créez un fichier de données par processeur et utilisez la même taille pour tous les fichiers créés.
Remplacez les paramètres de croissance automatique de la base de données par une valeur fixe telle que 100-150 Mo. Par défaut, la croissance de la base de données est configurée à 10 %, ce qui peut entraîner des retards lors de l’augmentation des bases de données plus volumineuses.
SQL Server mémoire doit être définie sur une valeur fixe en définissant à la fois la mémoire minimale du serveur et la mémoire maximale du serveur sur la même valeur. En général, allouez 75 % de la mémoire physique à SQL Server et laissez 25 % pour le reste du système d’exploitation et toutes les applications. S’il s’agit d’un SQL Server dédié, vous pouvez réduire le montant réservé au système d’exploitation à un minimum de 1 Go.