Microsoft Exchange Server 5.5 : calcul du nombre d'utilisateurs par serveur
Sur cette page
Microsoft Exchange Server 5.5 : calcul du nombre d'utilisateurs par serveur
Par Eric S. Savoldi
Microsoft Consulting Services
Sommaire
| • | Vue d'ensemble |
| • | Introduction |
| • | Définition du contexte de la planification de capacité |
| • | Facteurs affectant les performances |
| • | Détermination des limites |
| • | L'art de l'analyse des performances : détection des goulets d'étranglement des performances |
Vue d'ensemble
Point clé : comment calculer le nombre d'utilisateurs par serveur, planifier le transfert d'un serveur Exchange et le dimensionner pour accroître sa capacité.
Détail : moyen Tâche : administration, déploiement
|
Introduction
Combien d'utilisateurs un serveur Exchange unique peut-il héberger ? Cette question, en apparence simple, mais fréquemment posée, est en fait complexe, car il existe beaucoup de raisons de la poser. Certains administrateurs la posent parce qu'ils ont déjà investi dans du matériel serveur et doivent évaluer sa capacité actuelle ; d'autres parce que ces informations vont déterminer les choix des acquisitions et permettre de planifier la croissance et la capacité futures. Un certain nombre d'utilisateurs par serveur peut fonctionner d'un point de vue administratif, mais n'être pas adapté aux limites de bande passante du serveur, et inversement, se satisfaire de la bande passante disponible, en contrepartie de sauvegardes trop longues. Et ainsi de suite.
La première partie de cet article examine les questions relatives aux performances, qui pourront vous aider à répondre à cette importante question. La seconde partie établit des recommandations spécifiques pour la planification du transfert d'un serveur Exchange et son dimensionnement en vue d'accroître sa capacité.
Définition du contexte de la planification de capacité
Une difficulté inhérente à cette question réside dans les unités de base utilisées pour la cadrer : utilisateur et serveur. Les utilisateurs varient largement dans leur utilisation des applications de messagerie, de planification et de groupe de travail, en fonction de la fréquence d'utilisation des applications de courrier électronique, de calendrier et de dossiers publics pour leurs activités professionnelles et personnelles. La culture d'entreprise de votre organisation et la répartition géographique de ses bureaux affectent également le système de messagerie. Certains utilisateurs reçoivent des centaines de messages chaque jour, d'autres un ou deux seulement. Certains utilisateurs génèrent 50 messages par jour, d'autres quelques-uns par semaine seulement. Dans une société donnée, un petit pourcentage des utilisateurs sont responsables d'une quantité disproportionnée de la charge totale du serveur.
Les serveurs varient largement également. Certaines organisations disposant de sites importants, centralisés ou bien connectés, utilisent un petit nombre d'ordinateurs multiprocesseurs à valeur élevée, avec plusieurs giga-octets de mémoire vive et des dizaines de disques durs. Ces serveurs hébergent autant d'utilisateurs par ordinateur serveur que possible. D'autres organisations déploient des centaines d'ordinateurs bon marché, à valeur faible pour connecter de nombreux petits sites, dispersés géographiquement. Ou encore, il est possible qu'une organisation soit constituée de plusieurs sites distants, variant par la taille et les vitesses de connexion, chacun présentant différentes exigences en termes de capacité serveur et de nombre d'utilisateurs. L'unique règle générale valable pour toutes les organisations est la suivante : toutes veulent tirer le meilleur de leur système de messagerie en termes de capacité et de coût du matériel, de la maintenance et de l'administration.
Pour déterminer le nombre d'utilisateurs qu'un serveur peut prendre en charge, il convient d'évaluer les deux types de charge que les utilisateurs imposent au serveur : les actions initiées par l'utilisateur et les actions d'arrière-plan.
Actions initiées par l'utilisateur
Les actions initiées par l'utilisateur sont des opérations de messagerie que le serveur exécute en conséquence d'une activité de l'utilisateur ; elles semblent (ou doivent sembler) instantanées du point de vue de l'utilisateur. Lorsque les utilisateurs ouvrent un message non lu dans leur dossier privé de la banque d'informations du serveur, le serveur exécute les actions synchronisées suivantes :
| • | réception et interprétation de la requête ouverte ; |
| • | évaluation des restrictions d'accès ; |
| • | récupération du message dans la base de données ; |
| • | marquage du message comme non lu ; |
| • | mise à jour du nombre de messages non lus de ce dossier ; |
| • | assemblage et renvoi des propriétés requises du message au client ; |
| • | génération d'une notification de dossier pour le client, signalant que le message a été lu. |
Toutes ces actions se produisent dans l'intervalle au cours duquel l'appel de procédure distante (RPC, Remote Procedure Call) émis par l'application client renvoie le contrôle au client. Du point de vue de l'utilisateur, l'action entière comprend également le temps de traitement requis par le client pour tracer la fenêtre et afficher les propriétés du message. L'activité initiée par l'utilisateur est responsable du facteur de charge le plus significatif sur les serveurs Exchange qui gèrent directement les utilisateurs (par rapport aux serveurs qui fonctionnent comme segment principal ou passerelle). La charge utilisateur est déterminée par le nombre d'utilisateurs qui utilisent activement le système de messagerie par unité de temps et par les types d'actions qu'ils réalisent.
Actions d'arrière-plan
Exchange Server exécute également des actions d'arrière-plan (ou asynchrones) pour les utilisateurs connectés et distants : acceptation, transfert, routage et distribution des messages ; extension des listes de distribution ; réplication des modifications des dossiers publics et des informations du service d'annuaire ; exécution des règles ; surveillance des quotas de stockage et exécution de la maintenance d'arrière-plan, telle que le nettoyage de la mémoire (défragmentation de bases de données AKA en ligne ) et l'examen de l'expiration d'index. Tant que ces actions sont terminées dans un intervalle de temps raisonnable, elles n'affectent pas la perception par les utilisateurs de la vitesse du système.
La charge d'arrière-plan est également déterminée par le nombre d'utilisateurs sur le serveur. Dans les systèmes gérant de nombreux utilisateurs, les serveurs Exchange qui fonctionnent comme des passerelles ou des connecteurs intersites peuvent connaître une intense activité d'arrière-plan. Toutefois, si ces serveurs n'hébergent pas directement des utilisateurs, ils ne connaissent pas de charge d'activité initiée par l'utilisateur.
Inégalité des actions
Afin de modeler la charge que ces actions imposent au serveur Exchange, certains administrateurs considèrent, par commodité, toutes les actions initiées par l'utilisateur comme équivalentes et toutes les actions d'arrière-plan comme équivalentes. Ceci n'est certainement pas le cas. Un utilisateur qui copie un message de 500 Ko dans sa banque d'informations personnelle impose une charge plus importante au serveur qu'un utilisateur qui copie un message de 1 Ko. L'envoi d'un message électronique à une liste de distribution comptant 100 membres engendre plus d'activité d'arrière-plan que l'envoi d'un message à un destinataire unique.
Il est possible de prévoir la charge du serveur plus efficacement en observant l'activité combinée sur la durée. Examinez l'activité d'un groupe particulier d'utilisateurs sur une période de temps (par exemple, une journée standard de 8 heures de travail), ajoutez-y les actions initiées par les utilisateurs (interaction avec le serveur pour envoyer ou lire les messages, recherche de destinataires dans le carnet d'adresses, etc.). Mesurez les actions d'arrière-plan correspondantes. Classez le niveau d'activité du groupe d'utilisateurs par rapport aux autres groupes. Vous pouvez utiliser ces données pour classifier les groupes d'utilisateurs en fonction du nombre d'actions qu'ils accomplissent par unité de temps et des caractéristiques de charge du serveur (telles que la taille des messages) pour ces actions. Ce sont les informations dont vous devez disposer pour prévoir les performances du système pour diverses communautés d'utilisateurs.
Voici un exemple de classification provenant de l'équipe Performances Exchange, concernant une utilisation faible, moyenne et intense :
Au cours d'une journée moyenne, un utilisateur à fréquence faible :
| • | Envoie 3 messages. |
| • | Lit 5 nouveaux messages et 12 anciens. |
| • | Effectue 1 modification de planification. |
Un utilisateur à fréquence moyenne :
| • | Envoie 6 messages. |
| • | Lit 15 nouveaux messages et 12 anciens. |
| • | Effectue 5 modifications de planification. |
Un utilisateur à fréquence intense :
| • | Envoie 8 messages. |
| • | Lit 20 nouveaux messages et 12 anciens. |
| • | Effectue 10 modifications de planification. |
Le degré de dépendance de votre organisation de la messagerie pour ses communications professionnelles a un impact sur les performances du serveur Exchange et sur le nombre d'utilisateurs qu'un serveur peut héberger. Certaines sociétés, telles que Microsoft, effectuent la plupart de leurs communications par le biais du système de messagerie, ce qui engendre une utilisation intense. Le même matériel assurant les même fonctions peut héberger 500 utilisateurs légers, mais seulement 150 utilisateurs intenses.
Les ressources matérielles d'un serveur comprennent un ou plusieurs processeurs, la mémoire vive principale et un ou plusieurs disques durs avec leur contrôleur (le sous-système E/S). Afin d'exécuter les actions initiées par les utilisateurs ou les actions d'arrière-plan, le serveur Exchange utilise ces trois ressources à des degrés variables. Une requête client d'ouverture de message prend plusieurs millièmes de secondes de traitement processeur, un ou plusieurs accès au disque et suffisamment de mémoire pour contenir le code et les données nécessaires à l'exécution de l'opération. Lorsque chaque action initiée par l'utilisateur se termine avant que la suivante ne démarre, le serveur dédie 100 % de son matériel à chaque action, l'exécutant également rapidement que possible sans attendre les ressources disponibles ; il est alors essentiellement inactif entre les actions. Les utilisateurs connaissent peu de délais de réponse du serveur et du réseau. Le serveur est déchargé.
Lorsque de nombreux utilisateurs initient des actions rapprochées dans le temps, ou lorsque de nombreux événements d'arrière-plan se produisent, les actions sont en concurrence pour bénéficier des ressources matérielles du serveur, ce qui cause des goulets d'étranglement. Le code qui exécute une action doit attendre que le matériel soit disponible. Lorsque le serveur subit une charge, les actions peuvent prendre plus de temps pour s'exécuter et les utilisateurs connaissent des délais de réponse plus élevés.
La relation entre la charge et le délai de réponse détermine le nombre d'utilisateurs qu'un serveur peut prendre en charge. Au fur et à mesure que la charge d'un serveur augmente, les délais de réponse que les utilisateurs subissent finissent par devenir inacceptables. Il convient d'estimer où se situe ce point de croisement (entre une solution acceptable et une solution inacceptable) dans le cas de votre société.
L'activité qui engendre la charge n'est pas équitablement distribuée sur la durée. Au cours d'une journée de travail, la charge la plus intense peut survenir le matin, étant donné que les utilisateurs prennent du temps pour répondre au courrier électronique ou pour lire les informations des dossiers publics arrivées depuis la veille. Au cours de la pause déjeuner, des soirées et des week-ends, l'activité de messagerie connaît des accalmies. Même si vous ignorez les variations à ce niveau et décidez que les intervalles d'utilisation sont assez uniformes, les charges varient quand même sur la durée du fait des différences individuelles en termes de niveau et de planification de l'utilisation.
Imaginez les actions initiées par les utilisateurs comme des événements d'unité de temps, qui rassemblent la charge utilisateur et la distribuent équitablement sur la durée. Par exemple, la plupart des serveurs subissent des pics d'activité au début de la journée de travail, lorsque les utilisateurs d'un même serveur téléchargent les nouveaux messages. Si la plupart de ces utilisateurs lisent immédiatement leurs nouveaux messages, ils provoquent un autre pic d'activité. Lorsqu'un serveur Exchange héberge suffisamment d'utilisateurs, les effets d'unité de temps des schémas, planifications et habitudes d'utilisation individuelle s'égalisent et ne doivent pas représenter un pourcentage élevé de la charge utilisateur totale sur le serveur, à l'exception des situations extrêmes.
Facteurs affectant les performances
Le type et le nombre de processeurs d'un serveur déterminent le potentiel de performances pour un environnement Exchange Server. Les ordinateurs utilisant le processeur Pentium II offrent de meilleures performances que les ordinateurs utilisant la puce Pentium, et un Pentium 233 MHz fonctionne mieux qu'un Pentium 133 MHz. Les ordinateurs à processeurs multiples surclassent les ordinateurs à processeur unique, mais pas de manière linéaire : un serveur à deux processeurs Pentium 233 MHz ne produit en général pas deux fois les performances d'un ordinateur à un seul processeur.
La pagination est le résultat d'un conflit de mémoire survenant lorsque deux applications ou plus veulent utiliser la mémoire système. Si le système manque de mémoire physique, il utilise la pagination pour écrire les pages de mémoire sur le disque dur, libérant ainsi de la mémoire physique pour l'autre processus. Lorsque ce processus est terminé, le système restitue ces pages à partir du disque dur dans la mémoire physique pour être utilisées par le processus d'origine.
Le conflit de mémoire est tolérable jusqu'à ce que le système atteigne un stade où ses ressources (temps processeur, bande passante du bus, temps disque, etc.) consacrent plus d'effort à transmettre les pages entre les processus qu'à effectuer un réel travail. Si vous comparez les courbes de conflit de mémoire à celles des délais moyens de réponse, vous verrez une ligne assez régulière depuis le conflit zéro jusqu'au point où les délais de réponse augmentent considérablement, point appelé point de surcharge. Au fur et à mesure que le conflit de mémoire s'intensifie au-delà de ce point, les délais de réponse augmentent de manière exponentielle. La surcharge temporaire est tolérable dans certains environnements, mais vous devez vous efforcer de l'éviter.
Les performances globales du serveur Exchange varient en fonction du sous-système E/S. Vous devez tenir compte du type et du nombre de contrôleurs de disques, du type des lecteurs installés, de la tolérance de pannes et des configurations RAID. Utilisez tous les canaux SCSI disponibles et ajoutez-en d'autres, si nécessaire, pour améliorer les performances. Des lecteurs de disques supplémentaires accroîtront également les performances, notamment avec les E/S de disque aléatoires, que les banques d'informations publiques et privées du serveur Exchange utilisent. Étant donné que tous les lecteurs connaissent des limites mécaniques, l'ajout de lecteurs peut permettre de répartir efficacement la charge de travail. Pour en savoir plus, consultez l'article intitulé en anglais "The Limits of Unlimited Information Store" sur TechNet.
Pour obtenir des performances réseau optimales, choisissez judicieusement le type de carte et le support réseau : câble à paire torsadée, fibre optique, câble coaxial, etc. Vous pouvez installer une carte réseau haute performance sur le serveur pour n'utiliser qu'un petit nombre de protocoles réseau, ainsi que plusieurs cartes réseau pour segmenter le réseau local, le cas échéant. Dans la mesure où les cartes réseau offrent des niveaux très variables de performances, évaluez avec précaution le type de bus, sa largeur et la quantité de mémoire intégrée.
Comparaison du nombre d'utilisateurs connectés par rapport au nombre total d'utilisateurs
Lors du calcul du nombre d'utilisateurs par serveur, procédez à l'évaluation du nombre d'utilisateurs qui se connecteront simultanément au serveur. Vous pouvez placer davantage de comptes utilisateur sur un même serveur si vous savez que tous ne se connecteront pas en même temps. Par exemple, si deux équipes de collaborateurs ne se connectent jamais au serveur Exchange en même temps, vous pouvez héberger les deux groupes sur le même serveur. L'hébergement de davantage d'utilisateurs par serveur accroît l'activité d'arrière-plan du serveur, mais reste en général une meilleure solution que d'avoir d'autres utilisateurs connectés simultanément. Souvenez-vous, cependant, que le serveur Exchange exécute toujours quelques actions (mises à jour de l'annuaire, routage des messages, etc.) au nom des utilisateurs, même lorsque ces utilisateurs ne sont pas connectés au système.
Emplacement et utilisation des banques d'informations
Les utilisateurs Exchange peuvent stocker leurs messages dans la banque d'informations (IS) sur le serveur ou dans des dossiers personnels (fichier .PST) sur leur ordinateur local ou sur un lecteur réseau. Même dans le cas des dossiers personnels, les utilisateurs disposent d'une banque d'informations sur le serveur pour recevoir les messages et traiter les règles. En revanche, s'ils définissent leur emplacement de distribution par défaut sur un dossier personnel et y stockent la plupart de leurs messages, les utilisateurs pourront alléger le travail du serveur. Les messages distribués dans la boîte aux lettres d'un utilisateur, dans la banque d'un serveur, lancent toujours les règles de classement du courrier dans la boîte de réception, mais le serveur en diffère l'exécution jusqu'à la connexion de l'utilisateur.
Le stockage local des données permet de décharger le serveur d'un grand nombre de transactions Exchange. Par exemple, lorsque les utilisateurs demandent des données de leurs dossiers personnels, le serveur n'a pas à lire les attributs et les données, à les écrire dans le cache tampon, à marquer les données comme lues, à mettre à jour le nombre de messages non lus et à envoyer les données au client. Si les utilisateurs enregistrent une copie de tous les messages envoyés dans le dossier Éléments envoyés, les clients Outlook ou Exchange peuvent les enregistrer localement dans un fichier .PST, libérant ainsi le serveur. Lorsque les utilisateurs suppriment des messages, le client en conserve des copies dans le dossier local Éléments supprimés et non pas sur le serveur. Le serveur Exchange dispose de moins de données en continu, ce qui peut simplifier les sauvegardes.
Types de clients
Lorsque vous décrivez des groupes d'utilisateurs, notez également le protocole client dont il s'agit. Le serveur Exchange prend en charge un éventail de protocoles client : Post Office Protocol (POP3), Internet Message Access Protocol (IMAP4), Messaging Application Programming Interface (MAPI) et Hypertext Transfer Protocol (HTTP) par le biais du client Outlook Web Access (OWA). Exchange prend également en charge les clients Macintosh et MAPI Windows 16 bits. Voici comment chaque protocole peut affecter la charge du serveur Exchange :
MAPI
Le client MAPI Windows 32 bits Outlook, riche en fonctionnalités, impose la plus lourde charge de traitement sur le serveur Exchange. Outlook permet l'accès au Carnet d'adresses global, aux différentes possibilités d'affichage et aux règles dont les autres clients de messagerie ne disposent pas, ainsi que l'accès aux dossiers publics et aux formulaires électroniques. Les composants Calendrier, Journal, Contacts, Liste des tâches et Remarques, augmentent également la charge sur le serveur, en particulier le Calendrier, s'il est utilisé intensément (voir l'explication qui suit dans ce document). Le client OWA prend en charge certaines de ces fonctionnalités et en ajoute au fur et à mesure qu'il progresse. Actuellement, les utilisateurs OWA peuvent accéder à leur calendrier, mais ne disposent pas d'un Assistant Réunion et n'ont pas accès aux calendriers des autres utilisateurs.
Les clients Macintosh et Windows 16 bits Outlook s'appuient également sur l'interface MAPI, mais n'offrent qu'un sous-ensemble des fonctionnalités disponibles sur le client Windows 32 bits Outlook. Par exemple, les formulaires Outlook 32 bits ne fonctionnent pas sur les plates-formes Macintosh ou Windows 16 bits.
POP3 et IMAP4
Les clients Internet POP3 et IMAP4 standard sont des protocoles de téléchargement ou de réception uniquement, qui accèdent au courrier par le biais des protocoles POP3 ou IMAP4 respectivement, mais qui envoient les messages par le biais du protocole SMTP (Simple Mail Transfer Protocol). Ceci peut affecter considérablement les performances du serveur Exchange, car ces clients reçoivent des messages provenant d'un serveur (qui héberge leur boîte aux lettres) et envoient des messages à l'aide d'un autre serveur (qui prend en charge le service Messagerie Internet), divisant ainsi par deux les exigences de traitement du serveur de boîte aux lettres Exchange.
Étant donné que les clients POP3 ne peuvent pas stocker les messages sur un serveur Exchange, ils les enregistrent sur l'ordinateur client, réduisant ainsi les besoins de stockage du serveur. Ceci réduit également les exigences de traitement du serveur, car les actions de récupération et de manipulation de messages sont exécutées sur le client. Les clients POP3 opèrent de manière similaire aux clients Outlook ou Exchange qui travaillent en mode hors connexion. Un client ayant téléchargé du courrier électronique réalise tout le traitement sur le disque dur local ; le serveur n'est donc plus impliqué dans la manipulation ni la suppression de ces messages.
Les clients IMAP4 peuvent voir un aperçu des en-têtes des messages avant de les télécharger, ce qui peut faire économiser beaucoup de temps aux utilisateurs distants, en différant par exemple le téléchargement d'un fichier de 5 Mo entrant sur une connexion d'accès distant.
OWA
Pour les clients OWA, les exigences de traitement (qui peuvent être très lourdes) incombent à l'ordinateur serveur IIS (Internet Information Server). Les tests montrent que, lorsque les serveurs IIS et Exchange se trouvent sur des ordinateurs différents, il est possible de diminuer considérablement le délai de réponse en plaçant plus de 700 utilisateurs OWA sur un serveur IIS unique comportant quatre processeurs et 512 Mo de mémoire vive. L'installation des deux serveurs, IIS et Exchange, sur le même ordinateur diminue considérablement le gain.
Un utilisateur OWA, comparé à un utilisateur Outlook, impose une charge moindre à un serveur Exchange qui ne s'exécute pas sur le même ordinateur que le serveur IIS. Ceci s'explique par les fonctionnalités Outlook plus nombreuses, qui permettent aux utilisateurs d'accomplir plus de tâches avec le serveur Exchange que ne le peuvent les clients OWA.
Utilisation et réplication des dossiers publics
Les dossiers publics peuvent avoir un effet déterminant sur les performances du serveur Exchange, en fonction de leur taille, de la fréquence d'accès utilisateur, du nombre des différents affichages pour chaque dossier, du nombre de répliques, du calendrier de réplication et de la fréquence des modifications de contenu. Les gros dossiers publics occupent une grande partie de la banque et leur lecture nécessite davantage d'E/S disque. Si de nombreux utilisateurs accèdent fréquemment à un dossier, le serveur demeure occupé à satisfaire ces requêtes. Pour chaque utilisateur, le dossier public conserve également un suivi du niveau d'extension de chacun de ses dossiers et de l'état lu/non lu de chaque message.
Bien que la réplication des dossiers publics soit rapide (les tests initiaux indiquent qu'il suffit de 61 secondes pour répliquer un millier de messages de 1 Ko entre deux serveurs), il procède par rafales puisque les modifications sont regroupées par lot, puis répliquées conformément à la planification établie par l'administrateur. Il est possible de planifier la réplication aussi fréquemment que toutes les 15 minutes (paramètre : TOUJOURS) et les utilisateurs accédant à un dossier lors des rafales de réplication entrantes remarquent un ralentissement soudain qui dure jusqu'à la fin du processus de réplication. La mise à jour de nombreux dossiers sollicite le serveur d'autant et prolonge les ralentissements dus aux rafales de réplication.
Les dossiers publics peuvent contenir des messages et des documents à accès libre. Les documents à accès libre subissent davantage de charge que les messages, car ils sont en général volumineux, voire parfois extrêmement volumineux. Par exemple, si vous glissez-déplacez un fichier de 1 Mo vers un dossier public, chaque fois qu'un utilisateur accède à ce fichier, 1 Mo de données sont envoyées sur le câble et, en cas de répétition suffisante, ceci affecte manifestement les performances du serveur pour chaque utilisateur. Un autre problème de performances peut survenir du fait de la mise en cache. Sur leur trajet sortant et entrant, les données transitent également par le cache tampon, qui contient les données les plus récemment utilisées qui ont été lues ou écrites dans la base de données. Lorsqu'un utilisateur ouvre le fichier de dossier public de 1 Mo cité plus haut, 1 Mo d'autres données est purgé du cache tampon. Si un utilisateur tente ensuite d'accéder aux données purgées, le serveur Exchange doit accéder au disque pour les obtenir.
Les utilisateurs remarquent également si un site traverse une liaison lente avec une réplique d'un dossier public de part et d'autre. Cet ensemble de conditions peut survenir logiquement du fait de l'algorithme utilisé par Exchange pour connecter un utilisateur à une réplique de dossier public. Lorsqu'un utilisateur demande l'accès à un dossier public, Exchange vérifie le serveur de base de l'utilisateur pour y rechercher le dossier. S'il ne trouve ni réplica, ni pointeur vers un serveur de dossiers publics pour tous les utilisateurs de ce serveur Exchange, il vérifie alors les autres serveurs locaux. (Cette nouvelle fonctionnalité, champ emplacement, couramment appelée sous-sites, confère aux administrateurs Exchange davantage de contrôle sur l'accès des utilisateurs aux dossiers publics.) Si Exchange n'y trouve pas le dossier, il route alors le client de manière aléatoire vers un serveur de site avec une réplique du dossier ; il est donc possible que ce routage rencontre une liaison lente.
Pour chaque utilisateur, Exchange conserve un relevé de l'état lu/non lu de chaque message et de l'état d'extension de chaque dossier dans la hiérarchie. Il stocke ces informations dans le dossier public sur un serveur spécifique. Exchange doit poursuivre le routage de l'utilisateur vers la même réplique de dossier public pour conserver ces informations synchronisées, de sorte qu'une fois que l'utilisateur est connecté sur la liaison lente, cette connexion est utilisée à partir de ce moment. Les administrateurs Exchange doivent définir avec soin les stratégies de dossier public, en utilisant le champ emplacement et en configurant correctement la topologie du site, afin d'éviter d'éventuels problèmes de performances.
Désormais, le serveur Exchange prend en charge le protocole NNTP (Network News Transfer Protocol), ce qui affecte également l'utilisation des dossiers publics. En premier lieu, NNTP facilite la configuration par les administrateurs d'un dossier public pour y importer les millions de messages trouvés sur le réseau Internet, ce qui peut manifestement accroître les exigences de stockage. En deuxième lieu, les administrateurs peuvent autoriser les utilisateurs NNTP extérieurs à participer aux dossiers publics et le trafic réseau peut connaître des pointes si de nombreux utilisateurs externes sollicitent les dossiers. En troisième lieu, les groupes de discussion NNTP peuvent atteindre la taille de 40 Go, voire plus. Si possible, il est utile de placer ces dossiers publics sur un serveur dédié afin d'isoler le système des charges non prévisibles.
Formulaires électroniques
Les formulaires électroniques sont pour l'essentiel gérés comme tous les autres messages, mais lors de la première utilisation d'un formulaire, le client doit le télécharger dans le cache de formulaires local avant de l'exécuter. Ceci reste une opération unique et ne se reproduit que si le formulaire change. Si un nouveau formulaire est envoyé à de nombreux utilisateurs et s'ils tentent tous de l'exécuter en même temps, l'opération peut être déterminante.
Planification
Le calendrier Outlook et l'ancien client Schedule+ utilisent un dossier public caché pour répliquer les informations de type disponible/occupé. Par défaut, ce dossier est placé sur le premier serveur installé sur un site. L'administrateur doit occasionnellement définir des réplicas afin d'absorber une charge utilisateur plus importante, qui augmentent le trafic de réplication et le temps de latence pour la mise à jour des informations de type disponible/occupé. Par défaut, tous les utilisateurs d'un site peuvent voir les informations de type disponible/occupé pour tous les autres utilisateurs du site. L'administrateur doit définir la réplication des dossiers disponible/occupé entre les sites et cette fonctionnalité peut affecter les performances du serveur Exchange. Des ressources spécialisées sont-elles nécessaires ? À la date à laquelle est écrit ce document, Microsoft utilise quatre serveurs dédiés disponible/occupé (chacun comportant quatre processeurs et une grande quantité de mémoire vive et d'espace disque) pour gérer plus de 40 000 utilisateurs.
Le problème réel de performances, s'agissant de l'ancien client Schedule+, consiste à savoir si l'utilisateur travaille avec un fichier de planification local. Si oui (par défaut), cela signifie que Schedule+ est répond très rapidement et qu'il met à jour périodiquement et de façon efficace les informations de planification sur le serveur. Si un utilisateur choisit de ne pas travailler avec un fichier de planification local, chaque modification de planification nécessite alors une interaction avec le serveur. Schedule+ a été conçu pour fonctionner de manière autonome et non pas simplement par rapport à un serveur ; il fonctionne donc toujours avec un fichier local d'abord, puis met à jour le serveur, plutôt que de simplement interopérer avec le serveur. Les utilisateurs uniques ne travaillant pas sur des fichiers de planification locaux remarquent une chute des performances ; si un nombre important d'utilisateurs travaillent de cette manière, tous les utilisateurs peuvent en être affectés.
Le calendrier Outlook est mieux intégré au client de messagerie et utilise le même emplacement de stockage que celui utilisé pour le reste du courrier. Lorsque les utilisateurs Outlook travaillant sur des serveurs Exchange définissent leur boîte aux lettres basée sur le serveur comme emplacement de distribution par défaut, Outlook stocke toutes les informations du calendrier dans le dossier "calendrier" de leur boîte aux lettres sur le serveur Exchange. Ce dossier peut également être défini pour une utilisation hors connexion, auquel cas les informations de type disponible/occupé des utilisateurs sont mises à disposition des autres. Si les utilisateurs sélectionnent un dossier personnel (fichier .PST) comme emplacement de distribution par défaut, toutes les informations relatives au calendrier y sont stockées et les informations de type disponible/occupé ne sont pas accessibles aux autres. Pour partager les détails du calendrier et les informations de type disponible/occupé avec les autres, les utilisateurs doivent définir leur boîte aux lettres basée sur serveur comme emplacement de distribution par défaut.
Applications MAPI
Il est difficile de mesurer l'effet des applications MAPI sur un serveur Exchange, car chaque application est différente. L'une des cause possibles des faibles performances des applications MAPI réside dans le fait qu'elles utilisent les appels de procédure à distance (RPC) de manière inefficace lors de la communication avec le serveur. Ceci peut être évité en regroupant les fonctions par lot, de sorte qu'elles accèdent au serveur en un seul appel RPC. L'équipe de développement d'Exchange a découvert cela lorsqu'elle a conçu la note de lecture par défaut ; 14 appels RPC ont été nécessaires pour récupérer et afficher un message. Dans le cas d'un utilisateur unique, ceci importe peu, mais si 250 utilisateurs d'un serveur Exchange émettent chacun 14 appels RPC pour récupérer et afficher un seul message, le niveau des performances est affecté considérablement. L'équipe Performances d'Exchange (qui a contribué au renforcement de l'efficacité des appels RPC dans le code Exchange) a conçu à nouveau la fonction, afin de n'utiliser que 2 appels RPC.
Il convient d'écrire tout code d'application client/serveur en vue d'améliorer les performances. En effet, même une petite partie de code indépendante, multipliée par suffisamment d'utilisateurs, peut sérieusement les dégrader.
Connecteurs et passerelles
Les connecteurs et les passerelles fonctionnent sur le serveur et concurrencent les autres processus Exchange pour accéder aux ressources, y compris à la banque. Ils opèrent par rafales et peuvent dégrader les performances temporairement.
Le serveur Exchange est conçu de sorte que, si un connecteur ou une passerelle spécifique engendre des problèmes de performances, vous puissiez facilement lui dédier un ordinateur ou en ajouter une deuxième ailleurs dans le site. Le serveur Exchange traite les sites comme des unités ; ces options sont donc transparentes pour les utilisateurs.
Annuaires, réplication et serveur de tête de pont
Un serveur de tête de pont agit comme porte d'entrée et de sortie de l'annuaire du site. Lors de la configuration d'un connecteur de réplication d'annuaire intersite, l'administrateur désigne un serveur dans chaque site comme serveur de tête de pont responsable de l'échange des mises à jour de l'annuaire avec son homologue. Au sein d'un site, la réplication d'annuaire est proportionnelle au nombre de modifications de l'annuaire. Cela ne doit affecter sensiblement les performances qu'au cours de la migration Exchange Server (lorsque l'annuaire change souvent) ou dans les organisations dans lesquelles des centaines de mises à jour de l'annuaire se produisent chaque jour.
MTA
La tâche principale de l'Agent de transfert des messages (MTA, Message Transfer Agent) consiste à acheminer les messages entre les serveurs. Même dans les systèmes à serveur unique, d'autres responsabilités lui incombent toutefois, telles que l'extension des listes de distribution ou le routage de messages de passerelle ou de connecteur sortants. Il affecte le plus les performances dans des environnements à serveurs multiples, mais même dans des configurations à serveur unique, il initie certains traitements.
Le serveur Exchange 5.5 améliore les performances globales de l'agent MTA. La file d'attente de sa base de données a été optimisée afin de remédier aux problèmes de flexibilité, que le serveur Exchange 4.0 avait résolu en verrouillant les objets de file d'attente de base de données dans la mémoire vive. Le serveur Exchange 5.5 remplace quant à lui tous les accès aux files d'attente de base de données par un mécanisme bien plus simple et plus efficace de files d'attente basées sur la mémoire vive. Il utilise le format de file d'attente de base de données uniquement lors de la sauvegarde des informations de files d'attente sécurisées sur le disque pendant l'arrêt propre du serveur ou pour le traitement de vérification de l'agent MTA, pour le mapper à nouveau dans la mémoire vive au prochain démarrage de l'agent MTA.
Plusieurs autres fonctionnalités du serveur Exchange 5.5 améliorent l'utilisation de l'agent MTA du système de fichiers sous-jacent : la mise en cache des descripteurs de fichiers, la mise en cache des fichiers dont l'objet a été supprimé ainsi que les E/S directes des tampons complets. La mise en cache des descripteurs de fichiers et la mise en cache des fichiers dont l'objet a été supprimé utilisent un nouveau bitmap par objet pour regrouper et supprimer les fichiers à la fermeture. L'agent MTA du serveur Exchange 5.5 permet également d'optimiser les éléments internes du serveur de base de données et l'utilisation des bases de données MTA afin de router plus de messages plus rapidement.
La mise à niveau vers Exchange 5.5 renforce les performances de l'agent MTA, en vous permettant de placer davantage d'utilisateurs sur un serveur sans pour autant accroître sa charge.
Agent de script serveur et routage des objets
Aujourd'hui, le serveur Exchange 5.5 prend en charge les scripts côté serveur par l'intermédiaire d'un agent de script, qui permet aux développeurs de créer des applications de formulaires pilotées par les événements ou l'heure en utilisant VBScript ou JavaScript. Ces scripts sont en fait exécutés sur le serveur Exchange ; les développeurs doivent donc écrire des scripts qui sont efficaces et optimisés. Afin de se prémunir contre l'installation de mauvais scripts (par exemple, un script qui vérifie chaque message d'une banque toutes les heures), l'administrateur doit déterminer qui est habilité à les placer sur un serveur.
Les objets de routage Exchange (Exchange Server 5.5 Service Pack 1) constituent un ensemble de composants qui s'intègrent dans l'architecture d'événement et de script du serveur Exchange 5.5, dans le but de simplifier le développement d'applications de routage et d'approbation. Les composants comprennent un moteur de routage simple, des objets de routage, la référence du programmeur et des exemples d'applications. Dans ce cas également, les développeurs doivent prendre des précautions lors de l'écriture de ces applications.
Collaboration en temps réel
Le serveur Exchange 5.5 prend en charge le protocole Chat. Bien qu'il soit quelque peu superficiel, le service Chat d'Exchange 5.5 permet à un serveur Exchange d'héberger simultanément jusqu'à 10 000 réunions en ligne ainsi que des clients de discussion en temps réel. Si ce type d'activité devient très courant, il affecte les performances du système ; isolez donc ce service sur un serveur dédié.
Le client Outlook 98 contient NetMeeting, application qui permet aux utilisateurs de définir et de planifier des réunions en ligne. Normalement, cela n'a aucun impact sur les performances du serveur Exchange, mais cela peut éventuellement consumer la bande passante si les participants sont nombreux et s'ils utilisent le partage audio, vidéo et d'applications.
Autres activités du serveur
Les tests réalisés par l'équipe Performances l'ont été sur un serveur Exchange pur, c'est-à-dire un serveur Exchange installé sur un ordinateur serveur Windows NT 4.0 qui était un serveur membre et qui n'exécutait aucune autre opération. Cela est rarement le cas dans la réalité. Le serveur Windows NT a en fait été conçu pour exécuter de multiples applications serveur sur un ordinateur, ce qui peut avoir un effet, qui pourrait être déterminant, sur les performances de ce serveur.
L'évaluation des aléas des performances de toutes les applications du serveur Windows NT et de la manière dont elles pourraient affecter les performances du serveur Exchange est trop complexe, mais voici une règle générale : l'exécution simultanée d'applications n'affecte les performances du serveur que lorsque les applications utilisent les ressources de façon intensive. Par exemple, l'utilisation du serveur comme contrôleur de domaine Windows NT, WINS Server ou serveur DHCP sur des systèmes sur lesquels peu d'activités client sollicitent ces services, n'affecte pas énormément les performances. D'un autre côté, l'exécution simultanée de Microsoft Systems Management Server, SQL Server ou SNA Server peut les affecter considérablement.
Connectivité et qualité du réseau
Les performances client/serveur peuvent être déterminées par la qualité du réseau sous-jacent. Le serveur Exchange assure une connectivité et des performances meilleures sur un anneau FDDI (Fiber Distributed Data Interface) de 100 Mo/sec que sur un réseau Token Ring ou lorsqu'il est relié à un segment Ethernet surchargé où se produisent de nombreuses collisions. Étudiez la connectivité et la qualité du réseau étendu, notamment lors du calcul des limites du site, puis déterminez si les clients peuvent accéder à leur serveur Exchange par le biais du réseau étendu.
Dernière mise à jour le mercredi 18 octobre 2000