Comment garantir des performances durables ?
Lorsque vous planifiez et évaluez votre système, il est crucial de vous projeter à long terme pour savoir si le système envisagé est durable. Les principaux points à prendre en compte sont les suivants :
Profils de charge et objectifs de performances : vous ne pouvez pas avoir trop de détails en ce qui concerne les profils de charge et les objectifs de performances. Le test et l'aptitude à la certification seront basés sur la capacité à gérer ces charges à long terme.
Autres activités et processus qui concurrencent les ressources du serveur : il ne s’agit pas seulement de la charge des messages. D'autres processus et activités, tels que les opérations de maintenance de la base de données et les requêtes exécutées sur MessageBox, ont lieu sur les serveurs. Ils ont une incidence sur les performances.
Pannes et temps d’arrêt du système planifiés et non planifiés : les événements de floodgate et le backlog des messages peuvent modifier le profil de charge effectif.
Lors de la phase d'ébauche de systèmes durables et des tests permettant de les certifier, veillez à prendre ces facteurs en compte.
Les performances de votre système sont-elles durables ?
Lorsque nous discutons des performances pour BizTalk Server, nous définissons les performances durables maximales comme suit :
la charge maximale de flux de messages qu'un système est capable de gérer indéfiniment dans un environnement de production ;
Bien que ceci paraisse simple, vous devez considérer de nombreux facteurs au moment où vous évaluez si une solution, s'exécutant sur un ensemble matériel donné, sera capable ou non de supporter les charges quotidiennes une fois que vous l'aurez mise en production.
Avant de passer à la phase de mise en production, prenez en compte les facteurs suivants pour déterminer si la solution est capable de gérer indéfiniment la charge de flux de messages maximale :
les objectifs de performances et profils de débit/latence souhaités ;
les autres processus partageant le même matériel, par exemple :
la surveillance et le dépannage courants ;
les opérations de maintenance de la base de données, telles que l'envoi de journaux, la sauvegarde, la purge, la maintenance des index et les mises à jour des statistiques ;
les autres applications ;
les temps d'arrêt et les interruptions du système, notamment :
l'arrêt des sites partenaires qui bloque l'envoi et la réception des messages ;
les arrêts périodiques du système pour effectuer la maintenance.
Connaissez-vous bien vos objectifs en matière de performances ?
Avant d'évaluer la durabilité de votre solution, vous devez avoir une vision détaillée des objectifs de production attendus. Si l'objectif n'est pas clair, vous ne pouvez pas savoir si la solution envisagée est adéquate. Il est très important que vous fixiez des objectifs de performances clairs, car ceux-ci vont constituer la base de vos stratégies en matière de test et de certification de votre solution. Vos objectifs devraient comporter les éléments suivants :
une courbe qui définit les performances en tant que fonction temporelle. Ces fonctions peuvent aller des plus simples au plus complexes ;
associer une exigence de performance à la fonction de performance ;
une répartition des fichiers par taille et type.
Exemple 1
tous les jours, le flux de messages passe de 0 msgs/sec à 8:00 à 80 msgs/sec à midi, puis redescend à 0 msgs/sec à 21:00. La courbe ressemble à une cloche.
Le système n'exige aucun délai de latence pour chaque message, cependant il doit être en mesure de traiter cette charge ainsi que tous les messages des jours précédents (par exemple, si le système a subi une interruption de 24 heures) sans prendre de retard.
Il existe trois types de documents : Panier de vente, Commande en arrière et Demande de stock. Les paniers ont une taille qui varie entre 2 et 10 kilo-octets et constituent 75 % du total des messages. Les autres types de documents font environ 1 kilo-octet et constituent, respectivement, 10 % et 15 % du reste des messages.
Exemple 2
tous les soirs à minuit, un lot de 500 000 messages arrive pour être traité.
Tous les messages du lot doivent être entièrement traités dans un délai de 8 heures.
Tous les messages sont du même type et sont également répartis en terme de taille (de 10 à 50 kilo-octets, inclus). En outre, le lot contient toujours 10 messages de type catalogue faisant chacun 10 mégaoctets. Pour leur traitement, ils doivent être sous-divisés en entrées de catalogue individuelles.
Exemple 3
Sept jours par semaine, 4 000 agents du service clientèle se connectent au système interactif tous les matins à 8:00. Chaque agent effectue en moyenne 4 recherches par minute jusqu'à la fermeture (17:00).
Toutes les recherches doivent renvoyer des résultats en moins de 2 secondes.
Toutes les recherches sont du même type et sont également réparties en terme de taille (de 500 à 1 000 octets, inclus).
Associer une exigence en matière de performances à une fonction de performance
Reprenons les exemples précédents.
Exemple 1 (suite) : le système n’a pas d’exigence de latence spécifique pour chaque message, mais il doit être en mesure de traiter cette charge, ainsi que toute la charge des messages de la journée précédente (par exemple, en cas de panne système de 24 heures) sans être en mesure de prendre en charge.
Exemple 2 (suite) : tous les messages du lot doivent être traités jusqu’à l’achèvement dans 8 heures.
Exemple 3 (suite) : toutes les requêtes doivent retourner les résultats en moins de 2 secondes.
Répartition des fichiers par taille et type
Exemple 1 (suite) : Il existe trois types de documents : Panier de vente, Commande en arrière et Demande de stock. Les paniers ont une taille qui varie entre 2 et 10 kilo-octets et constituent 75 % du total des messages. Les autres types de documents font environ 1 kilo-octet et constituent, respectivement, 10 % et 15 % du reste des messages.
Exemple 2 (suite) : tous les messages sont du même type et sont répartis uniformément entre 10 et 50 Kilooctets, inclus. En outre, le lot contient toujours 10 messages de type catalogue faisant chacun 10 mégaoctets. Pour leur traitement, ils doivent être sous-divisés en entrées de catalogue individuelles.
Exemple 3 (suite) : toutes les demandes sont du même type et sont réparties uniformément entre 500 et 1 000 octets, inclus.
Prise en compte des autres processus
Outre les profils de charge qui transitent directement via le moteur BizTalk, d'autres processus entre en concurrence pour se partager les ressources présentes sur le même matériel. Ces autres processus réduisent la capacité que le système a à assurer des performances globales durables. La maintenance de la base de données est l'exemple le plus typique de ce genre de processus.
Toute base de données, qu'elle soit petite ou grande, doit faire l'objet d'opérations de maintenance, telles que l'envoi de journaux, la sauvegarde, l'archivage et la purge. La surveillance et le dépannage sont d'autres exemples d'opérations que vous devez prendre en compte lorsque vous définissez et certifiez un système aux performances durables. Par exemple, les interrogations de la base de données MessageBox (par exemple, par l'intermédiaire de la page Hub du groupe de la console d'administration) réalisées pour connaître le nombre de messages d'un certain type ayant été suspendu au cours des dernières 24 heures font appel à des ressources du serveur SQL Server qui auraient pu être utilisées autrement pour traiter des messages.
Voici une liste d’activités qui auront généralement le plus d’effet sur la durabilité globale dans BizTalk Server :
Envoi des journaux et sauvegarde : Dans le cadre de la plupart des plans de récupération d’urgence impliquant SQL Server, vous devez effectuer régulièrement la copie et la sauvegarde des journaux pour toutes les bases de données de groupe BizTalk Server. Pour plus d’informations, consultez Sauvegarde et restauration de bases de données BizTalk Server. Consultez Également La copie des journaux.
Archivage et vidage des données de suivi. En plus du plan global d’expédition et de sauvegarde des journaux, la base de données BizTalk Tracking (BizTalkDTADb) a ses propres régimes d’archivage et de purge ; Pour plus d’informations, consultez Archivage et vidage de la base de données de suivi BizTalk. La vitesse à laquelle les données peuvent être archivées et purgées au sein de la base de données des suivis BizTalk est particulièrement importante, car cette base de données constitue généralement un goulot d'étranglement lorsque le suivi est actif.
Requêtes système. L’utilisation d’API ou de l’interface utilisateur de la console d’administration BizTalk Server pour exécuter différents types de requêtes sur le système affecte les performances durables.
Maintenance de MessageBox. Il existe un certain nombre de travaux SQL qui font partie des fonctionnalités principales de BizTalk Server qui gèrent la base de données MessageBox en nettoyant les messages et les instances qui ont terminé leur traitement. La vitesse à laquelle ces tâches peuvent s'exécuter est un facteur clé lors de l'estimation de la durabilité du système. Pour plus d’informations sur ces travaux et leur rôle, consultez Maintenance de BizTalk Server1.
Activités de déploiement de solution. lorsque vous déployez, liez et démarrez de nouvelles applications ou de nouvelles versions d'applications existantes, vous imposez des charges supplémentaires sur BizTalk, comme la création de nouveaux abonnements aux bases de données MessageBox. Une fois que les applications ont été déployées, elles sont en concurrence avec les messages en cours de traitement pour obtenir des ressources système. Ceci a un impact sur les performances des applications existantes.
Pour chacun de ces domaines, vous devez vous demander : Quelle est votre recommandation pour réduire l’impact de ces activités ? Par exemple, devraient-elles s'exécuter à 3:00 du matin ?
Prise en compte des interruptions planifiées ou non
L'impact que les interruptions peuvent avoir sur les performances du système varie selon le système. Cependant, les conséquences les plus courantes sont les suivantes :
Événements de floodgate. lorsque les systèmes sont arrêtés pendant une période prolongée, des messages peuvent s'accumuler et arriver tous en même temps pour être traités une fois que les systèmes sont de nouveau opérationnels. Par exemple, si une application qui s'exécute sur BizTalk reçoit des messages via MSMQ, et qu'elle est momentanément arrêtée, des messages peuvent s'accumuler dans les files d'attente. Lorsque l'application est redémarrée, c'est comme si un grand nombre de messages arrivait tous en même temps.
Backlog de messages. lorsque les systèmes destinataires des messages sont arrêtés, un cycle de tentatives a généralement lieu. Ce cycle utilise des ressources supplémentaires. Au terme du cycle, les messages sont en général suspendus. Lorsque les systèmes reviennent en ligne, ils sont parfois inondés si un volume important de messages peut alors être à nouveau traités et/ou envoyés correctement.
Il est évident que vous devez prendre en compte les interruptions planifiées, telles les opérations de maintenance lorsque vous concevez et certifiez un système. Nous vous recommandons également d'analyser les interruptions non planifiées ainsi que leurs conséquences.
Vous aurez une meilleure idée du type de capacité système voulu en identifiant les types d'interruptions pouvant se produire, en les classant par niveau de risque (à savoir, la probabilité de la gravité), en évaluant leur durée et incidence (par exemple, les événements de saturation, le volume de messages suspendus et en souffrance, etc.) pour les interruptions qui présentent le plus de risque. Tout système asynchrone basé sur la messagerie, tel que BizTalk Server, doit être conçu pour traiter une « marge d’attente » suffisante pour faire face aux pannes planifiées et non planifiées.
Voir aussi
Persistance et durabilité du moteur
Recommandations par phase pour la planification du projet
Mesure du débit maximal acceptable du moteur
Mesure du débit de suivi maximal acceptable
Mise à l'échelle des solutions
Identification des goulots d'étranglement des performances
Performances et capacité du moteur