Impact sur les performances des nombres élevés d'éléments et des affichages restreints

Dernière rubrique modifiée : 2009-01-14

Cette rubrique vous aide à comprendre, diagnostiquer et résoudre les problèmes de performances Microsoft Exchange Server 2007 en relation avec des nombres élevés d'éléments dans des dossiers importants et des demandes d'affichage restreint en cas d'utilisation de Microsoft Office Outlook en mode connexion, d'Outlook en mode mis en cache avec un accès Délégué et d'Outlook Web Access. Les dossiers importants sont Calendrier, Contacts, Boîte de réception et Éléments envoyés. Les vues restreintes sont des vues de données qui limitent les informations sur la base de critères de recherche qui ne produisent des vues que d'un sous-ensemble d'éléments d'un dossier. Des problèmes de performances apparaissent souvent en relation avec ces situations et peuvent se traduire pour un utilisateur final par un ralentissement de l'accès au client. Il suffit de quelques utilisateurs ayant des nombres anormalement importants d'éléments dans leurs dossiers critiques pour générer des problèmes de performances perceptibles dans l'ensemble de l'organisation Exchange.

Avec Exchange Server 2003, le nombre maximal d'éléments recommandé était de 5 000 éléments. Sous Exchange 2007, les améliorations en matière d'E/S, de taille de page plus large et de mémoire cache accrue permettent une augmentation du nombre maximal d'éléments recommandé. Ave un matériel à l'architecture correcte, une expérience utilisateur acceptable peut tout de même être maintenue avec des nombres d'éléments pouvant atteindre 20 000 éléments.

Ce maximum recommandé varie en fonction de l'accès ou non de programmes tiers aux boîtes aux lettres des utilisateurs. Les programmes tiers concernés sont les suivants, ainsi que des programmes similaires :

• compléments Outlook ;

• archivage de messages ,

• antivirus ;

• périphérique mobile ;

• messagerie vocale ;

• autres programmes ou compléments Outlook qui créent des affichages supplémentaires ou des dossiers de recherche.

Dans ce scénario, le nombre d'éléments doit être déterminé via la consultation de la charge globale du serveur et du mode de traitement par le serveur de chaque demande à partir d'un programme tiers spécifique.

Ce maximum recommandé dépend également des performances de votre environnement Exchange. Vos choix matériels spécifiques peuvent engendrer des nombres maximaux inférieurs. Idéalement, il est préférable de conserver un nombre d'éléments inférieur à 20 000 dans les dossiers Boîte de réception et Éléments envoyés, et un nombre d'éléments inférieur à 5 000 pour les dossiers Contacts et Calendrier. Même en conservant un nombre d'éléments inférieur ou égal aux valeurs maximales recommandées, certaines opérations peuvent prendre du temps (généralement plus ou moins une minute). Celles-ci incluent les nouveaux ordres de tri et la sélection de dossiers pour la première fois. Les premiers affichages d'un dossier peuvent nécessiter encore plus de temps. Des nombres élevés d'éléments dans des dossiers critiques ont un effet négatif sur les performances du serveur parce qu'il s'agit des dossiers faisant l'objet du plus grand nombre d'accès dans la boîte aux lettres d'un utilisateur. D'autres dossiers, en particulier ceux créés par des utilisateurs finaux, peuvent prendre en charge davantage d'éléments sans que cela ait un effet négatif sur l'expérience de l'utilisateur parce qu'ils font l'objet d'un moindre nombre d'accès. Bien que l'effet sur les performances de nombres d'éléments supérieurs dans des dossiers faisant l'objet d'un moindre nombre d'accès soit réduit, des nombres d'éléments importants dans ces dossiers peuvent générer des problèmes de performances passagers lorsque le nombre de dossier de cette sorte augment ainsi que quand augmente le nombre d'utilisateurs actifs sur le serveur.

Important :

Les premiers affichages d'un dossier peuvent nécessiter encore plus de temps. Par conséquent, le déplacement des opérations de boîtes aux lettres entraînera une dégradation des performances du premier affichage pour tous les dossiers incluant un nombre d'éléments élevé. Ceci peut être à l'origine de problèmes de performances passagers lorsque les utilisateurs qui ont été déplacés vers de nouveaux serveurs accèdent à leurs dossiers et recréent les affichages correspondants. Le fait de suivre les meilleures pratiques opérationnelles, à savoir de déplacer les boîtes aux lettres sur plusieurs serveurs et de réduire le nombre de boîtes aux lettres déplacées simultanément sur un même serveur, permet de limiter ce problème.

Lorsque vous évaluez le nombre maximal d'éléments pour votre organisation, vous devez savoir qu'il n'existe pas de seuil maximal. Toutefois, plus le nombre d'éléments est élevé, plus les performances se dégradent. Les limites définies ne sont pas codées en dur. Elles sont basées sur des tests et des analyses de code. Au fur et à mesure que le nombre d'éléments augmente, les utilisateurs peuvent remarquer une dégradation perceptible des performances. Le niveau de performances acceptable pour les utilisateurs de votre organisation permettra de définir le nombre maximal d'éléments adapté à l'environnement.

Il faut comprendre qu'il n'existe pas de limite de taille intrinsèque pour les boîtes aux lettres individuelles. Les principaux facteurs limitant la taille de boîte aux lettres sont les suivants : espace disque disponible, temps de sauvegarde et de restauration, contrats de niveau de service et performances d'Outlook. Concernant les performances d'Outlook, nous faisons spécifiquement référence aux latences rencontrées par l'utilisateur final.

Impact des choix matériels sur les performances

Même si cela peut paraître évident, il convient de répéter ce qui suit : si le matériel de votre organisation n'a pas la taille adéquate, il se peut que vous constatiez des performances médiocres avec un nombre d'éléments moindre. En mode connexion, les besoins d'E/S d'un système augmentent à mesure qu'augmente le nombre d'éléments dans les boîtes aux lettres. Les latences de disque constituent l'un des principaux problèmes de performances matérielles en relation avec des nombres élevés d'éléments. Pour optimiser l'expérience de l'utilisateur, assurez-vous que les latences de disque sont brèves (20 millisecondes ou moins), même en cas d'usage excessif du serveur.

Pour comprendre l'incidence d'une latence de disque sur les performances du serveur, considérez l'exemple suivant. Lorsque vous demandez un affichage, la demande de données passe par des requêtes individuelles, sérialisées, à partir du disque, et non par des opérations en bloc. Par exemple, si un plug-in affiche 1000 éléments, la banque d'informations Exchange génère probablement quelque 200 requêtes de données distinctes (en supposant que 5 messages sont extraits par requête). À une vitesse de 20 millisecondes, cela implique un retard de 4 secondes du seul sous-système de disque. Vous pouvez imaginer l'intensification de l'impact sur les performances d'une latence de disque de 50 ou 100 millisecondes. Le problème se complique encore si plusieurs plug-ins sont utilisés, qui lancent des requêtes similaires. Dans ce cas, les utilisateurs risquent de constater de fréquents blocages d'Outlook.

Pour plus d'informations sur les recommandations de dimensionnement du serveur pour garantir de bonnes performances d'Exchange 2007, consultez la rubrique Planification du serveur et de l'architecture de stockage.

Nécessité d'un temps de traitement supplémentaire

Si vous considérez l'impact sur les performances d'un nombre élevé d'éléments et de demandes d'affichage limitées sur la capacité de traitement du serveur, vous devez être conscient des traitements sous-jacents qui interviennent et de la manière dont des nombres élevés d'éléments et des demandes d'affichage limitées influencent ces processus.

Le contenu des dossiers est stocké dans une table de la base de données de banque d'informations. Toute augmentation du nombre d'éléments entraîne une croissance correspondante de la complexité du stockage. Le mécanisme de stockage de la banque d'informations Exchange est ESE (Extensible Storage Engine). ESE utilise des structures de données arborescentes B+ pour conserver les enregistrements. Si le nombre d'enregistrements augmente, le nombre potentiel de demandes d'E/S sur disque requises pour localiser les informations et parcourir l'arborescence B+ augmente également. Pour plus d'informations, consultez la rubrique Architecture de moteur ESE (moteur de stockage extensible).

Si le nombre d'éléments augmente, la possibilité que des données requises soient localisées dans des emplacements physiquement adjacents sur le disque dur est sensiblement réduite. C'est pourquoi un plus grand nombre de demandes d'E/S sont requises.

La création d'affichages limités nécessite un traitement du serveur Exchange.

Il existe deux façons de filtrer les messages dans MAPI :

• Dossiers de recherche

• Restrictions

  Pour créer une restriction, appelez la méthode IMAPITable::Restrict sur une table MAPI. La table créée affiche uniquement les éléments qui correspondent à la restriction spécifiée. Une table au contenu restreint affiche les messages d'un seul dossier. Ce type de restriction peut parfois prêter à confusion avec la structure définie par MAPI décrivant les critères de filtre d'un dossier de recherche, également appelée restriction.

Les dossiers de recherche et les restrictions requièrent un traitement supplémentaire, par exemple, la création d'un dossier de recherche et son remplissage avec des éléments répondant aux critères de l'utilisateur. Ce processus exige l'examen de chaque élément du dossier pour déterminer s'il doit être placé dans le dossier de recherche. Ainsi, quand un dossier contient un grand nombre d'éléments, l'affichage nécessite plus de temps. Les dossiers de recherche sont stockés comme SearchFID sous chaque dossier où la recherche a été lancée. Par défaut, une fois un dossier de recherche peuplé, son existence peut durer jusqu'à 40 jours.

La présence de vues limitées affecte la vitesse à laquelle des modifications peuvent être apportées aux éléments d'un dossier. Si un dossier de recherche est associé à un dossier, un traitement supplémentaire est nécessaire en cas d'ajout, de suppression ou de mises à jour d'éléments dans l'autre dossier. Ce comportement résulte du fait qu'Exchange doit déterminer si le dossier de recherche nécessite une mise à jour. Si vous créez un grand nombre de dossiers de recherche, chaque modification doit être évaluée par rapport à tous les dossiers de recherche pour déterminer ces derniers nécessitent une mis à jour.

Si des propriétés non standard supplémentaires sont ajoutées à l'affichage d'un dossier dans Outlook, des appels de procédure distante (RPC) supplémentaires peuvent être requis pour extraire les propriétés non standard de la banque d'informations Exchange. Si un dossier contient un grand nombre d'éléments, un plus grand nombre de cycles est requis pour extraire les données du serveur Exchange.

Lorsque vous tentez d'afficher un dossier de calendrier, Outlook doit localiser tous les rendez-vous s'inscrivant dans la plage de dates spécifiée. Cela nécessite au moins deux requêtes de traitement. La première obtient tous les rendez-vous statiques dans la plage de dates spécifiée. La seconde localise les rendez-vous récurrents dans la même plage de dates. Le temps requis pour traiter la deuxième requête est proportionnel au nombre d'éléments dans le dossier de calendrier. Cela résulte du fait qu'Outlook recherche tous les rendez-vous récurrents. Une fois la liste de rendez-vous récurrents reçue, il convient de les examiner pour déterminer s'il s'inscrit dans la plage de dates spécifiée. Si le calendrier contient un grand nombre d'éléments, il faut plus de temps pour traiter ces demandes.

Impact sur les performances des nombres élevés d'éléments par rapport à la taille de boîte aux lettres

Il faut comprendre que la plupart des problèmes de performances ne résultent pas d'une taille de boîte aux lettres importante (2 Go ou plus) mais du nombre d'éléments dans les dossiers faisant l'objet d'un accès sur le serveur. Un nombre important d'éléments dans un dossier affecte négativement les performances du fait que les opérations dans ces dossiers prennent plus de temps. Les performances dépendent en particulier du nombre d'éléments dans les dossiers critiques : Calendrier, Contacts, Boîte de réception et Éléments envoyés. Pour plus d'informations sur la planification de boîtes aux lettres volumineuses, consultez la page White Paper: Planning for Large Mailboxes with Exchange 2007 (en anglais).

Parmi les opérations qui dépendent du nombre d'éléments dans le dossier figurent l'ajout d'une colonne à l'affichage, le tri sur une nouvelle colonne et les recherches. Un grand nombre de plug-ins Outlook effectuent des tris ou des recherches lors de leur exécution et ces requêtent peuvent chevaucher d'autres requêtes MAPI Outlook. Il en résulte une mauvaise expérience pour l'utilisateur.

Si vous travaillez en mode mis en cache (mode par défaut pour Outlook 2003 et les versions ultérieures), les performances du client peuvent devenir problématiques à mesure qu'augmente le nombre d'éléments dans le dossier. Vous devez veiller à ce que vos fichiers OST (le cache de données local) ne contiennent pas de fragments. Vous pouvez utiliser l'outil Windows SysInternals Contig à cette fin. Pour télécharger la dernière version de Contig, consultez la page Contig v1.55 (en anglais).

Outre le nombre d'éléments dans les dossiers critiques, d'autres facteurs affectent le fonctionnement d'Outlook, qui sont exacerbés par des nombres élevés d'éléments, tels que le nombre d'autres applications MAPI ou de plug-ins Outlook en cours d'exécution sur l'ordinateur de l'utilisateur. Toutes les requêtes MAPI nécessitent un temps de traitement avec emsmdb32.dll. Si un utilisateur a de nombreux plug-ins effectuant des requêtes, Outlook fonctionne plus lentement et l'impact sur le serveur peut augmenter. La complexité des actions demandées a également un impact. Par exemple, le marquage de tous les éléments d'un dossier comme lus prend plus de temps que le marquage d'un seul. Parmi les autres actions qui peuvent prendre beaucoup de temps figurent la récupération d'informations de disponibilité pour de grands nombres d'utilisateurs en relation avec une demande de réunion ou l'exécution d'une recherche dans plusieurs dossiers. Si des utilisateurs effectuent fréquemment des actions complexes, utilisent un grand nombre de plug-ins Outlook ou utilisent intensément les dossiers Contacts et Calendrier, la probabilité d'une chute des performances résultant de nombres importants d'éléments est considérablement accrue.

Affichages restreints (Restrictions MAPI)

MAPI affiche généralement les données sous la forme d'un tableau. Il existe une table présentée au client lorsqu'il demande une liste de fournisseurs, une table pour les dossiers, un autre pour leur contenu, une encore autre pour les pièces jointes, etc. Chaque table est composée de colonnes. Chaque colonne correspond à une propriété MAPI distincte représentant des attributs tels que l'expéditeur, l'objet et le temps de délai de remise. Chaque ligne représente un élément spécifique Pour une table de contenu de dossier, chaque ligne représente un message. Les actions client sur ces tables sont représentées par des activités telles que le tri de données. Le client peut rechercher dans la table une ligne spécifique correspondant à des critères déterminés. Cette opération est appelée FindRow(). Elle peut également demander que seuls des éléments répondant à certains critères soient inclus dans la table. Par exemple, elle peut demander de n'inclure que des éléments créés un jour déterminé. C'est ce qu'on appelle une restriction. La table de contenu du dossier obtenue ne contient que les éléments correspondant aux critères spécifiés. Des restrictions sont utilisées lorsqu'il est prévu que le client demande fréquemment la même représentation de données.

Impact des affichages restreints sur les performances

Pour comprendre l'impact des restrictions sur les performances, vous devez savoir que la banque d'informations stocke en réalité les données qu'un client MAPI demande et comprendre comment elle interprète des demandes telles que FindRow et Restrict. Dans le schéma de stockage de la banque d'informations figurent diverses tables qui représentent ensemble des éléments tels que des boîtes aux lettres, des dossiers, le contenu de dossiers et des messages.

Quand un client demande une liste du contenu d'un dossier, cette demande est mappée sur un dossier spécial appelé Message Folder Table (MsgFolder). Chaque dossier créé dans le système est associé à une table de dossiers de messages distincte. La table MsgFolder a pour fonction de mapper un dossier sur son contenu.

Pour gérer les attentes d'un appel restreint (réinterrogations fréquentes des mêmes données), un nouveau dossier spécial (et la table MsgFolder correspondants) est créé, qui est appelé Restricted Search Folder (dossier de recherche restreinte). Ce dossier est lié au dossier original et une relation logique existe entre les deux dossiers. Une condition est appliquée au dossier de recherche de façon à ce qu'il ne puisse inclure que des éléments correspondant aux critères spécifiés dans la restriction. Dans ce dossier de recherche, un lien retour vers la ligne d'origine dans la table MsgFolder existe pour chaque message de la table MsgFolder correspondant aux critères de la restriction.

Le problème de performance que génère ce comportement est le temps requis pour gérer la mise à jour de chacun des dossiers de recherche. En cas de modification d'un dossier d'origine, la modification est comparée à chaque dossier de recherche restreinte associé au dossier en question afin de déterminer s'il doit également être mis à jour. L'impact de cette opération est plus important s'il existe un grand nombre de dossiers de recherche pour un ou plusieurs dossiers. Le second problème rencontré est la création des dossiers de recherche restreinte La création d'un dossier de recherche restreinte requiert une analyse complète du dossier d'origine pour extraire des éléments individuels qui doivent être liés dans le dossier de recherche restreinte. Si ce processus se produit directement à la suite d'une action du client, le retard peut avoir pour effet que l'utilisateur constate une suspension du programme ou voie s'afficher une fenêtre contextuelle RPC Outlook indiquant que le traitement d'une requête prend beaucoup de temps. Le temps requis pour créer le dossier de recherche restreinte est proportionnel au nombre d'éléments dans le dossier ordinaire. À mesure que le nombre d'éléments dans un dossier augmente, la probabilité qu'ils soient placés dans des secteurs de disque adjacents est sensiblement réduite. Cela entraîne une augmentation importante des E/S de disque aléatoires lors de l'exécution de requêtes d'affichage restreint sur des dossiers contenant un grand nombre d'éléments. À mesure que le nombre de demandes d'affichage restreint augmente sur des dossiers contenant un grand nombre d'éléments, l'impact du nombre accru d'E/S est ressenti par tous les utilisateurs qui accèdent à des ressources sur le serveur.

Dans Exchange 2000 Server, Exchange Server 2003 et Exchange Server 2007, il existe un nombre maximal de dossiers de recherche restreinte autorisés par dossier. Le nombre maximal par défaut est 11 et leur durée de vie par défaut est de 40 jours.

Les dossiers de recherche restreinte sont traités dans l'ordre d'arrivée. Si un dossier est déjà associé à 11 dossiers de recherche restreinte, une nouvelle requête de restriction est créée et la liste des dossiers de recherche est évaluée en fonction de la dernière utilisation réelle de la restriction. Cela signifie que le dossier de recherche restreinte le moins utilisé est supprimé pour permettre le traitement de la nouvelle requête Comme mentionné plus haut, cela requiert une analyse complète de la table MsgFolder ordinaire et est effectué en tant qu'action directe par le client qui peut percevoir un problème de performance pendant la création de la table et sa présentation au client. Il est ainsi possible que, à une fréquence quotidienne ou hebdomadaire, plus de 12 dossiers de recherche restreinte soient requis. Cela produit un client subissant une requête de restriction à laquelle ne correspond pas de dossier de recherche. Ceci engendre ensuite la suppression et la création de nouveaux dossiers de recherche restreinte Toutes ces demandes dont traités de façon séquentielle. Cela signifie que, s'il y a un grand nombre d'utilisateurs ayant un nombre très élevé d'éléments dans des dossiers sur lesquels des affichages restreints sont régulièrement demandés, il se peut que ces demandes soient mises en file d'attente. Cela entraîne un ralentissement global perceptible pour tous les utilisateurs qui accèdent à des données de boîte aux lettres hébergées sur le serveur. Cela affecte cependant plus que les utilisateurs accédant à leur boîte aux lettres. Par exemple, des utilisateurs sur d'autres serveurs, qui accèdent à des données de calendrier stockées sur le serveur, perçoivent également un ralentissement.

Important :
L'installation de paramètres régionaux côté client peut générer encore plus d'affichages pour les utilisateurs d'Outlook Web Access et d'Outlook en mode en ligne

Affichages restreints et calendriers partagés

Lorsque vous affichez le calendrier, le dossier de contact, etc. de quelqu'un d'autre, l'affichage du dossier peut être retardé Une fois le dossier affiché, sa fermeture ou un retour en arrière s'opèrent assez rapidement. Toutefois, après un certain temps, l'accès au dossier devient lent. Le retard est particulièrement long si le nombre d'éléments figurant dans le calendrier est supérieur à 5000.

Quand Outlook accède aux dossiers de quelqu'un d'autre, il applique un affichage qui empêche l'utilisateur de consulter des éléments privés.

L'application d'un affichage à un dossier génère des dossiers de recherche dans la banque d'informations. Lors de sa création, le dossier de recherche est mis en cache pour une utilisation ultérieure. Si un utilisateur tente de créer un dossier de recherche existant, le dossier de recherche mis en cache est utilisé. Les affichages ultérieures sont ainsi assez rapides

Par défaut, Exchange ne met pas en cache tous les dossiers de recherche indéfiniment. La mise en cache d'un trop grand nombre de dossiers de recherche entraîne, côté serveur, des retards liés à la mise à jour des dossiers de recherche. Inversement, si un nombre suffisant de dossiers de recherche ne sont pas mis ne cache, un problème similaire se produit, résultant de la nécessité de générer et de mettre à jour des dossiers de recherche.

Pour illustrer ce problème, imaginons un scénario où un serveur Exchange est configuré pour conserver 11 dossiers de recherche (affichages) par dossier. Supposons que Frank ait un dossier de calendrier qu'il partage avec 15 autre utilisateurs. Sally accède au dossier et doit patienter pendant la création de son dossier de recherche. Une fois ce dernier créé, l'accès est rapide. Ensuite, Sally ne consulte plus le dossier pendant une journée tandis que 11 autres utilisateurs y accèdent. Un nouveau dossier de recherche est créé pour chacun d'eux. Comme seuls 11 dossiers de recherche sont mis en cache, lorsque le douzième utilisateur consulte le dossier, Exchange supprime le dossier de recherche créé pour Sally. Ensuite, lorsque Sally rouvre le dossier, elle doit de nouveau attendre qu'Exchange crée son dossier de recherche.

Supposons que vous configuriez le serveur de boîtes aux lettres de Frank pour mettre en cache 20 affichages. Sally et les 14 autres utilisateurs peuvent alors consulter le dossier de calendrier de Frank et seuls 15 dossiers de recherche sont créés. Comme le nombre 15 est inférieur au nombre 20, il n'est jamais nécessaire de reproduire un affichage, de sorte que l'accès est rapide pour tous après l'ouverture initiale pour créer les dossiers de recherche.

Le nombre par défaut de dossiers de recherche mis en cache est 11. Cette configuration est définie au niveau de la base de données. Pour afficher la valeur configurée, vous pouvez utiliser ADSI Edit. Ce dernier permet d'afficher l'objet Banque et d'examiner l'attribut msExchMaxCachedViews. Le nom unique est le suivant :

CN=Base_de_données, CN=Groupe_stockage,CN=Banque_informations,CN=Nom_serveur,CN=Serveurs,CN=Nom_GA,CN=Groupes_administration,CN=Orgname,CN=Microsoft_Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com.

Dans certains cas, une modification visant à augmenter la valeur au-delà de 11 peut être utile pour l'impact sur les performances d'un environnement.

Important :
La valeur d'attribut msExchMaxCachedViews ne doit jamais être supérieure à 50.

Important :
Si vous disposez de la version de publication d'Outlook 2003 dans votre environnement, assurez-vous que le Service Pack 1 ou une version ultérieure est déployé pour corriger un problème connu de ralentissement des performances lorsque vous travaillez avec calendriers partagés.