Conception de grandes listes et optimisation des performances des listes (SharePoint Server 2010)

 

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

Cet article fournit des informations sur les performances des bibliothèques de documents et des listes de grande taille. Les recommandations indiquées dans cet article sont le résultat d’une série de tests de performances effectués avec Microsoft SharePoint Server 2010. Cet article se concentre sur les caractéristiques des performances des grandes listes et sur l’impact de différentes configurations sur les performances des grandes listes et de la batterie de serveurs. SharePoint Server 2010 présente plusieurs nouveautés qui facilitent la création et l’utilisation des grandes listes. Toutefois, la création et l’implémentation de grandes listes doivent toujours faire l’objet d’une planification minutieuse. Vous devez prendre en compte de nombreux facteurs, tels que l’architecture de l’information, les performances, la récupération d’urgence et la gouvernance. Cet article couvre l’architecture de l’information et les fonctionnalités qui permettent d’implémenter des grandes listes, ainsi que l’impact de configurations spécifiques sur les performances.

En outre, certaines décisions clés que vous devez prendre en matière de conception peuvent avoir une incidence sur les performances des grandes listes. Elles concernent notamment les autorisations, le nombre de colonnes ajoutées à une liste, le nombre de colonnes de recherche dans les affichages, ainsi que les dossiers et les index à utiliser pour l’organisation d’une liste. Ces décisions ont une incidence sur les performances des listes, d’autant plus perceptible que la taille des listes augmente. Cet article montre l’impact de différents choix conceptuels sur les performances des grandes listes, afin que vous disposiez des éléments nécessaires pour concevoir correctement une grande liste qui réponde aux contraintes de performances, tout en satisfaisant les besoins de l’entreprise et en procurant une expérience utilisateur de qualité.

Bien que cet article soit spécifique à SharePoint Server 2010, les limitations et limites s’appliquent également à Microsoft SharePoint Foundation. Cet article couvre plusieurs fonctionnalités qui améliorent sensiblement l’expérience liée à l’utilisation des grandes listes, et ces fonctionnalités ne sont disponibles que dans SharePoint Server 2010. Aucune distinction entre SharePoint Foundation et SharePoint Server n’est faite dans cet article.

Dans cet article :

• Présentation des méthodes de requête

• Exemples de scénarios de grande liste

• Grandes listes et SharePoint Server 2010

• Mesures des performances et méthodologie de test

• Limitation et limites

• Autres limites

• Différences entre les grandes listes et les listes ordinaires

• Conception et implémentation des grandes listes

• Conclusion

Présentation des méthodes de requête

Il existe trois méthodes principales pour accéder à des données de liste : affichages de liste avec navigation par métadonnées, composant WebPart Requête de contenu et recherche. Chaque méthode présente des avantages et des inconvénients et est appropriée dans des situations spécifiques.

Affichage de liste et navigation par métadonnées

Les affichages de liste accèdent systématiquement à la base de données Microsoft SQL Server. Cela aboutit à un ralentissement des performances des requêtes et à une augmentation de la charge sur les ressources SQL Server supérieurs à ceux inhérents aux autres méthodes. En outre, les affichages de liste affichent la plupart du HTML, ce qui se traduit par un chargement des pages plus lent que dans les autres méthodes. Les affichages de liste procurent aux utilisateurs la meilleure expérience en matière de configuration des affichages, de filtrage dynamique des données et de réalisation d’actions sur les documents, telles que la gestion des versions et la modification des propriétés. La navigation par métadonnées vous permet de filtrer les résultats des affichages de liste. Privilégiez le recours à des affichages de liste lorsque vous devez disposer de données de colonne complètes et d’un accès aux actions d’élément de liste. Dans les scénarios présentant des taux élevés de lectures et de requêtes, vous devez envisager l’utilisation d’autres méthodes de requête.

Composant WebPart Requête de contenu

Le composant WebPart Requête de contenu affiche une vue à configuration statique de données mises en cache à l’aide du fournisseur du plan de site portail pour de meilleures performances. Le composant WebPart Requête de contenu affiche la plus petite quantité de HTML et est mis en cache. Cela se traduit par un chargement plus rapide des pages et par la simplification de la combinaison de plusieurs requêtes sur une même page. Le composant WebPart Requête de contenu doit être utilisé pour afficher des liens vers des éléments de liste, des documents ou des pages connexes. Bien que le composant WebPart Requête de contenu puisse également être configuré de manière à ne pas être mis en cache, vous ne devez utiliser cette configuration que dans les pages pour lesquelles les contraintes de débit sont limitées ou dans les pages pour lesquelles le cache n’est pas utile, comme dans les cas où les requêtes évoluent en fonction de l’utilisateur qui accède à la page.

Recherche

Les composants WebPart de recherche permettent de déléguer les requêtes à un système optimisé pour la recherche de contenu (au lieu de modifier les propriétés et de voir les mises à jour en temps réel). Les composants WebPart de recherche peuvent être configurés pour utiliser des requêtes statiques ou spécifiées par l’utilisateur. Les composants WebPart de recherche affichent de bonnes performances. Toutefois, les données ne sont pas plus à jour que l’analyse la plus récente. Cela signifie que les résultats sont antérieurs aux résultats issus des affichages de liste et des composants WebPart Requête de contenu.

Exemples de scénarios de grande liste

Il existe différents scénarios de grande liste courants, impliquant chacun des décisions spécifiques en termes de conception. Par exemple, dans un scénario de grande liste collaboratif, les utilisateurs ajoutent du contenu et mettent des propriétés fréquemment. Dans ce type de scénario, il est préférable que la taille de la liste n’atteigne pas des millions d’éléments, car cela peut rendre difficile le filtrage du contenu et celui-ci est fréquemment mis à jour et modifié. Si vous utilisez des bibliothèques de documents non structurées, cet article peut vous aider à comprendre les limitations et les limites qui protègent les performances de SQL Server. Le tableau suivant donne des indications sur les scénarios de grande liste.

Scénario	Taille de la liste	Gestion	Ratio lectures/mises à jour/ajouts	Nouveau contenu	Utilisateurs
Bibliothèque de documents non structurée	Centaines	Pas de responsable	Taux élevé de lectures, taux équilibré d’ajouts et de mises à jour	Transfert manuel	Dizaines
Grande bibliothèque ou liste collaborative	Milliers	Propriétaires de sujet informel	Taux élevé de lectures, davantage de mises à jour que d’ajouts	Transfert manuel	Centaines
Grand référentiel structuré	Dizaines de milliers	Personne chargée du contenu dédiée	Taux très élevé de lectures, moins d’ajouts et sensiblement moins de mises à jour	Envoi et transfert	Dizaines de milliers
Archive à grande échelle	Millions	Equipe de personnes chargées du contenu	Taux faible de lectures et de mises à jour, taux élevé d’ajouts	Envoi	Dizaines de milliers

Bibliothèque de documents non structurée

La bibliothèque de documents non structurée est souvent utilisée pour une équipe ou un groupe de travail et contient généralement entre plusieurs dizaines et plusieurs centaines de documents. Ces bibliothèques peuvent atteindre une taille supérieure au seuil d’affichage de liste en l’absence de planification, ce qui peut avoir une incidence sur les opérations, telles que l’ajout de colonnes. Un problème potentiel est le déclenchement d’exceptions de seuil d’affichage de liste si la taille des affichages dépasse 5 000 éléments. Vous pouvez limiter ce problème en surveillant les bibliothèques dont la taille approche le seuil d’affichage de liste. (Une jauge est affichée dans la page des paramètres de la bibliothèque de documents pour indique que la taille de celle-ci approche le seuil d’affichage de liste.)

Ce scénario implique généralement des dizaines, voire des centaines, d’utilisateurs, mais peu d’utilisateurs simultanés. Par conséquent, la charge au sein d’une même bibliothèque est rarement source de problème. Toutefois, il peut exister un nombre élevé de bibliothèques de ce type. Plutôt que de planifier la prise en charge d’instances spécifiques, il est plus important de mettre l’accent sur la prise en charge de l’échelle de ces bibliothèques.

Grande bibliothèque ou liste collaborative

Une grande liste collaborative comprend entre plusieurs centaines et plusieurs milliers d’éléments et permet de stocker une quantité élevée de contenu actif. En règle générale, les grandes listes collaboratives comprennent des solutions de gestion des connaissances, des bibliothèques d’ingénierie, ainsi que des référentiels de ventes et de marketing annexes. Les utilisateurs ajoutent et modifient du contenu de manière active (nombre élevé d’opérations de lecture et d’écriture). Vous pouvez mettre en place une structure et une procédure de gestion pour que la bibliothèque demeure organisée. Toutefois, une grande quantité de travail étant réalisée par les utilisateurs, des événements échappant au contrôle des administrateurs risquent de se produire. La liste peut donc facilement augmenter plus rapidement que prévu ou franchir les limites pour lesquelles elle avait été planifiée. Ce type de référentiel peut comporter des centaines ou des milliers d’utilisateurs, dont des dizaines, voire des centaines, d’utilisateurs simultanés.

Par rapport à un référentiel ou à une archive structurés, une grande liste collaborative est plus sujette à des modifications administratives telles que l’ajout et la suppression de dossiers, l’ajout de colonnes et de types de contenu ou la réorganisation du contenu. Ces actions peuvent être empêchées si la taille de la liste atteint le seuil d’affichage de liste.

Grand référentiel structuré

Un grand référentiel structuré comprend entre plusieurs milliers et plusieurs centaines de milliers d’éléments. Le contenu a généralement un caractère final et est envoyé par les utilisateurs ou par des processus système, tels que des flux de travail. Les grands référentiels structurés sont généralement utilisés pour les archives d’enregistrements des services, le stockage de documents précieux et les documents finaux qui apparaissent dans les pages Web. Le contenu est généralement structuré et hautement géré ce qui facilite le contrôle de la croissance de la liste. Ce scénario peut impliquer des dizaines ou des centaines d’utilisateurs simultanés et une base d’utilisateurs regroupant plusieurs milliers d’individus. Le pourcentage de lectures est beaucoup plus élevé que celui des écritures. Toutefois, le contenu peut faire l’objet de mises à jour et les opérations d’ajout et de suppression de contenu peuvent être fréquentes. Un référentiel de gestion des connaissances pour une division ou une organisation est un exemple de grand référentiel structuré.

Dans ce scénario, il est important de comprendre précisément les besoins des utilisateurs et d’effectuer des tests complets avant de mettre en œuvre la solution. Par conséquent, la solution est relativement complète et finale avant d’être alimentée avec une grande quantité de contenu. Par exemple, il peut s’avérer nécessaire de configurer des filtres et des hiérarchies de navigation par métadonnées appropriés pour procurer une expérience d’exploration de contenu adéquate.

Archive à grande échelle

Une archive à grande échelle comprend entre plusieurs milliers et plusieurs millions d’éléments, dans une seule liste ou disséminés dans plusieurs listes, voire dans plusieurs collections de sites. En règle générale, ce scénario comporte une faible quantité de lectures et de mises à jour et est utilisé uniquement comme stockage à long terme de documents qui doivent être conservés à des fins de conformité ou pour d’autres raisons (par exemple, des documents qui doivent être conservés pendant sept années pour des raisons juridiques). Un débit élevé de l’envoi et de la suppression des documents est important dans ce scénario. La recherche est la principale méthode de récupération de contenu.

Grandes listes et SharePoint Server 2010

Les fonctionnalités qui facilitaient l’utilisation des grandes listes dans Office SharePoint Server 2007 demeurent présentes dans SharePoint Server 2010 et nombre d’entre elles ont été perfectionnées pour améliorer les performances à grande échelle. En outre, SharePoint Server 2010 possède de nombreuses nouvelles fonctionnalités qui améliorent les performances des grandes listes et qui permettent aux utilisateurs d’exploiter celles-ci efficacement. Cette section récapitule les fonctionnalités nouvelles et améliorées dans SharePoint Server 2010.

Fonctionnalités améliorées

Les sections suivantes présentent les fonctionnalités de Microsoft Office SharePoint Server 2007 qui sont améliorées dans SharePoint Server 2010.

Composants WebPart Requête de contenu

Vous pouvez configurer le composant WebPart Requête de contenu de manière à afficher des résultats en les filtrant sur des listes, des types de contenu et des colonnes. Vous pouvez trier les résultats et sélectionner les colonnes à afficher. Ainsi, le composant WebPart Requête de contenu s’avère idéal pour afficher du contenu de grande liste dans les pages Web. Les composants WebPart Requête de contenu sont généralement mis en cache. Cela permet un chargement plus rapide des pages et réduit la charge qui pèse sur la base de données. Dans les scénarios de gestion des connaissances, vous pouvez utiliser des composants WebPart Requête de contenu dans les pages de publication afin d’afficher des liens vers des documents liés au contenu de la page Web.

SharePoint Server 2010 permet d’améliorer les performances dans les scénarios clés suivants :

• optimisation des requêtes à liste unique pour mieux tirer parti des index ;

• amélioration des algorithmes d’invalidation et d’actualisation et des paramètres par défaut pour améliorer l’utilisation du cache lorsque les utilisateurs effectuent des opérations d’écriture.

Recherche

SharePoint Server 2010 offre de nouvelles fonctionnalités de recherche qui comprennent un panneau d’affinement des termes de recherche et une meilleure évolutivité permettant la prise en charge d’une latence de requête inférieure à la seconde avec 100 millions de documents. Notons également Microsoft FAST Search Server 2010 for SharePoint, qui permet d’atteindre des échelles plus grandes qu’avec SharePoint Server 2010 Search.

Parmi les nouvelles améliorations apportées à la recherche qui facilitent la recherche de contenu dans les grandes listes figurent la prise en charge des opérateurs booléens dans les requêtes en texte libre, l’amélioration de la prise en charge des opérateurs, tels que les opérateurs « égal à », « inférieur à » et « supérieur à », les affinements des plages et la correspondance de préfixe sur les mots clés et les propriétés. Par exemple, la requête « share* » trouve les résultats qui comprennent « SharePoint ». En outre, la recherche propose des suggestions de requête qui formulent des recommandations basées sur la chaîne de caractères que tape l’utilisateur pour une requête. L’interface utilisateur de la recherche est également améliorée avec des panneaux pour les recherches associées, les meilleurs résultats, les personnes associées et les affinements de mots clés.

SharePoint Server 2010 Search améliore également les fonctionnalités liées à la montée en puissance. SharePoint Server 2010 Search prend en charge la montée en puissance parallèle des serveurs d’index, d’analyse et de requête. Les autres améliorations comprennent l’actualisation des index, une meilleure résistance et une disponibilité plus élevée. FAST Search Server 2010 for SharePoint comprend toutes les fonctionnalités de SharePoint Server 2010 Search et permet en outre la prise en charge des demandes extrêmes, de l’extraction d’entités, du classement selon la pertinence paramétrable, des meilleurs résultats, des miniatures et des aperçus.

Modèles de sites Centre de documents et Centre d’enregistrements

Le centre de documents et le centre d’enregistrements sont des modèles de sites SharePoint Server 2010 qui vous permettent de créer des référentiels structurés. Le modèle de site Centre de documents comprend des fonctionnalités telles que les composants WebPart Requête de contenu préconfigurés pour l’obtention de résultats pertinents par les utilisateurs connectés et une bibliothèque de documents avec configuration d’une navigation par métadonnées.

Le modèle de site Centre d’enregistrements ressemble au modèle de site Centre de documents, mais il bénéficie d’office de la fonctionnalité « organisateur de contenu » pour le routage des documents et dispose d’une bibliothèque d’enregistrements dans laquelle les éléments ajoutés à cette dernière sont automatiquement déclarés comme étant des enregistrements et ne peuvent pas être supprimés. Le modèle de site Centre d’enregistrements est le seul modèle de site prêt à l’emploi pour lequel l’analyseur de documents n’est pas activé, ce qui préserve la fidélité du contenu envoyé. Étant donné que la désactivation de l’analyseur de documents a une incidence sur les performances de certaines opérations, elle est plus appropriée pour un stockage de documents à grande échelle (dizaines de millions d’éléments) que d’autres modèles de sites.

Nouvelles fonctionnalités

Cette section décrit les nouvelles fonctionnalités dans SharePoint Server 2010 qui facilitent la gestion des grandes listes et des performances des listes.

Organisateur de contenu

L’organisateur de contenu permet, depuis n’importe quel site, de router du contenu vers des bibliothèques de documents ou des dossiers spécifiques, voire vers d’autres sites. L’organisateur de contenu permet de créer automatiquement des dossiers pour le contenu en fonction de propriétés de métadonnées. Les utilisateurs peuvent envoyer du contenu à l’organisateur de contenu à partir d’autres sites sans se soucier de l’emplacement auquel il est stocké dans le plan de gestion de fichiers. L’organisateur de contenu permet de répartir le contenu dans différents dossiers afin de maintenir automatiquement une taille maximale pour chaque dossier. Lorsque la limite de taille spécifiée est atteinte, un sous-dossier est créé, destiné à contenir des éléments supplémentaires.

Navigation par métadonnées

La navigation par métadonnées est une nouvelle fonctionnalité SharePoint Server 2010 qui permet aux utilisateurs de filtrer les listes dynamiquement afin de rechercher ce dont ils ont besoin. La navigation par métadonnées permet aux utilisateurs de sélectionner des options de filtrage et gère l’exécution de la requête de la manière la plus efficace possible. La navigation par métadonnées se compose de deux parties. La première partie est un ensemble de contrôles de navigation qui permet à un utilisateur de filtrer une liste à laquelle sont associés des hiérarchies de navigation et des filtres de touche. La seconde partie est un mécanisme qui permet de réorganiser et de réexécuter les requêtes.

La navigation par métadonnées comporte une logique de réexécution et de secours qui vise à exécuter les requêtes efficacement à l’aide d’index. Si une requête retourne trop de résultats, elle est réexécutée de manière à retourner un sous-ensemble des résultats pour de meilleures performances. Si aucune requête appropriée ne peut être exécutée, un processus de secours entre en jeu et les filtres sont appliqués sur un ensemble limité des résultats. La navigation par métadonnées crée automatiquement des index. Ensemble, les fonctionnalités de réexécution, de secours et de gestion d’index font de la navigation par métadonnées une composante très importante de l’exploitation efficace des grandes listes. Il existe deux types de mécanismes de filtrage : les hiérarchies de navigation et les filtres de touche.

Les hiérarchies de navigation utilisent un contrôle d’arborescence pour la navigation dans les hiérarchies de dossiers, de types de contenu, de champs de choix ou d’ensembles de termes de métadonnées gérées. Cela permet aux utilisateurs de recourir à un contrôle d’arborescence pour s’appuyer sur une hiérarchie de métadonnées, à l’image de la navigation dans les dossiers. Lorsque les utilisateurs sélectionnent un élément dans une hiérarchie pour une colonne de métadonnées gérées, tous les éléments qui correspondent au terme spécifié ou à n’importe lequel de ses termes enfants descendants sont affichés. Cela s’appelle l’inclusion de descendants et peut être utilisé sur des champs liés à un ensemble de termes de métadonnées gérées. Les utilisateurs peuvent sélectionner de nouveau l’élément pour effectuer un filtrage limité à ce terme et exclure les termes enfants descendants. Toutes les requêtes de navigation par métadonnées sont récursives et affichent des résultats issus de tous les dossiers dans la liste.

Vous pouvez configurer des filtres de touche pour effectuer un filtrage supplémentaire des résultats dans la hiérarchie. Par exemple, vous pouvez ajouter la colonne Modifié par en guise de filtre de touche, puis taper un nom d’utilisateur pour obtenir des résultats dans lesquels Modifié par correspond au nom d’utilisateur entré. Pour plus d’informations, voir Navigation et filtrage de métadonnées (https://go.microsoft.com/fwlink/?linkid=219154&clcid=0x40C). La figure suivante montre un exemple de hiérarchies de navigation par métadonnées et de filtres de touche.

Métadonnées gérées

Les métadonnées gérées constituent un nouvel ensemble de fonctionnalités qui ajoutent des fonctionnalités d’architecture de l’information à SharePoint Server. Les fonctionnalités de métadonnées gérées comprennent un service partagé appelé le service de métadonnées gérées. Celui-ci permet de stocker des ensembles de termes en vue de leur réutilisation dans un déploiement SharePoint Server 2010. Parmi les fonctionnalités de métadonnées gérées figurent les suivantes :

• ensembles de termes qui prennent en charge les hiérarchies plates ou profondes ;

• type de colonne de métadonnées gérées qui utilise des ensembles de termes en guise de propriétés disponibles ;

• ensembles de termes pouvant être ouverts, afin que toute personne soit en mesure d’ajouter de nouveaux termes, ou restreints, afin que seuls des utilisateurs spécifiques soient en mesure de les gérer.

En utilisant des ensembles de termes et des colonnes de métadonnées gérées pour organiser le contenu, vous pouvez recourir à des fonctionnalités telles que le composant WebPart Requête de contenu et la navigation par métadonnées pour permettre aux utilisateurs de rechercher et de découvrir du contenu. En outre, les métadonnées gérées facilitent l’exécution des requêtes de recherche ordinaires, car elles ajoutent des mots clés permettant de classer les documents. Les métadonnées gérées peuvent être utilisées dans le panneau d’affinement de la recherche. La figure suivante montre un exemple de navigation par métadonnées gérées.

Limitation et limites

SharePoint Server 2010 introduit une série de limites configurables qui permettent de préserver les performances de la batterie de serveurs. Au niveau de l’application Web, il existe désormais des limitations et des limites configurables. Celles-ci ont été ajoutées afin que les opérations réalisées par des utilisateurs ou par des processus spécifiques n’affectent pas les performances de la batterie de serveurs. Par exemple, le seuil d’affichage de liste est une limite qui n’autorise que les requêtes qui affectent sur un nombre maximal d’éléments de liste donné.

Index composés

Les index sont importants pour les grandes listes. Dans SharePoint Server 2010, vous pouvez désormais créer des index composés. Ceux-ci sont utiles lorsque des requêtes sont couramment exécutées sur deux colonnes, car une requête sur une seule colonne peut s’avérer insuffisamment sélective. Les index composés ne sont pas utilisés par les affichages. Toutefois, ils sont utilisés par la navigation par métadonnées. Lorsqu’une condition de limitation se produit, la logique de la navigation par métadonnées peut être réexécutée et utiliser des index composés et des index uniques appropriés pour les conditions de filtre choisies afin de rechercher des résultats complets ou partiels qui satisfassent à la requête.

Tableau de bord du développeur

Le tableau de bord du développeur affiche des informations de diagnostic détaillées pour chaque chargement de page. Par défaut, le tableau de bord est désactivé. Toutefois, vous pouvez l’activer manuellement ou le configurer de manière à ce qu’il soit toujours activé. Lorsque le tableau de bord du développeur est activé, il vous permet d’obtenir des informations sur les requêtes de base de données, les durées de chargement et les erreurs. Le tableau de bord du développeur permet d’analyser et de diagnostiquer rapidement les problèmes de performances. La figure suivante illustre le tableau de bord du développeur. La fonctionnalité de navigation par métadonnées est visible dans le tableau de bord du développeur dans le cas de grandes listes et de conditions de limitation, la liste d’index utilisée pour la réexécution et les résultats partiels apparaissant à gauche dans l’arborescence des opérations, les différentes requêtes SQL Server indexées exécutées étant, pour leur part, répertoriées à droite.

Le tableau de bord du développeur est également utile pour le débogage des requêtes et des composants WebPart personnalisés. Pour plus d’informations sur l’activation du tableau de bord du développeur, voir le billet de blog Activer le tableau de bord du développeur à l’aide du modèle objet et de Powershell (https://go.microsoft.com/fwlink/?linkid=219613&clcid=0x40C) (éventuellement en anglais).

Itérateur de contenu

L’API de développement d’itérateur de contenu simplifie l’écriture de code pour les grandes listes et est particulièrement importante avec la nouvelle limite de seuil d’affichage de liste. L’itérateur de contenu est une méthode qui permet de récupérer du contenu pour effectuer des opérations sur des sous-ensembles de celui-ci plutôt que sur la totalité du jeu de données. Cela empêche les opérations de dépasser le seuil d’affichage de liste.

Stockage BLOB distant

Par défaut, SharePoint Server 2010 stocke les données (BLOB (Binary Large Object)) de fichier dans des bases de données SQL Server. Une grande quantité d’une base de données de contenu est couramment constituée de données BLOB. Le stockage BLOB distant permet de stocker ces données en dehors de SQL Server, ce qui se traduit par une réduction du coût des solutions de stockage et de la taille de la base de données de contenu. Le stockage BLOB distant est un ensemble d’API de bibliothèque incorporé en tant que Feature Pack complémentaire pour SQL Server 2008. Un fournisseur de stockage BLOB distant tiers est nécessaire pour utiliser l’API de stockage BLOB distant.

Mesures des performances et méthodologie de test

Cette section explique la méthodologie de test utilisée pour les tests présentés dans cet article. Les écarts par rapport à cette méthodologie sont indiqués avec données à l’appui.

Configuration matérielle et de la batterie de serveurs

La configuration de la batterie de serveurs de test est spécifiée dans les figures et tableau suivants. Deux aspects de la configuration de test se distinguent sensiblement de la plupart des déploiements en situation réelle :

• L’authentification NTLM a été utilisée pour éviter que le contrôleur de domaine ne devienne le goulot d’étranglement. Cela s’est traduit par une légère amélioration des performances.

• Le serveur d’applications contenait une instance SQL Server utilisée pour la base de données de journalisation. Cela avait pour but de réduire la charge sur l’instance SQL Server principale, car le niveau de journalisation était beaucoup plus élevé que dans les déploiements en situation réelle.

Configuration informatique	Deux serveurs Web	Un serveur d’applications	Un serveur de bases de données
Rôle	Serveur Web frontal	Serveur d’applications	Instance SQL Server
Processeur(s)	2px4c@2,33 GHz	2px4c@2,33 GHz	4px2c@3,19 GHz
Mémoire RAM	8 Go	8 Go	32 Go
Système d’exploitation	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64
Stockage et géométrie correspondante (incluant notamment la configuration des disques SQL Server)	50 + 18 + 205 Go	50 + 18 + 300 Go	Baie de disques – 15 disques de 450 Go à 15 000 tr/m
Nombre de cartes réseau	2	2	2
Vitesse de carte réseau	1 gigabit	1 gigabit	1 gigabit
Authentification	NTLM	NTLM	NTLM
Version du logiciel	SharePoint Server 2010 (version préliminaire)	SharePoint Server 2010 (version préliminaire), SQL Server 2008 CTP 3	SQL Server 2008 CTP 3
Nombre d’instances SQL Server	N/A	1	1
Type d’équilibrage de la charge	Matériel	N/A	N/A
Paramètres du cache de sortie
Paramètres du cache d’objets
Paramètres du cache BLOB
Niveau de journalisation du service ULS	Moyen	Moyen	Moyen
Emplacement de la base de données d’utilisation		X
Paramètres de la base de données d’utilisation (ce qui est en cours de journalisation)
Paramètres IRM	Aucun	Aucun	Aucun
Paramètre antivirus	Aucun	Aucun	Aucun

Type de base de données	Nombre de bases de données	Configuration RAID
Base de données temporaire	1	0
Base de données de configuration	1	0
Base de données de contenu n° 1	1	0
Base de données de profils	1	0
Base de données de recherche	1	0
Base de données de taxonomie	1	0

Charge des tests

Des tests ont été menés à un point de charge optimal, ou zone verte, avec une combinaison d’opérations générale. Pour mesurer des changements spécifiques, des tests ont été effectués à chaque point d’altération de variable. Pour rechercher le point de charge optimal, des threads ont été ajoutés pour saturer l’environnement sans atteindre toutefois les mesures suivantes :

• La latence au 75e centile est inférieure à 1 seconde.

• Le taux d’utilisation du processeur du serveur Web frontal est inférieur à 50 %.

• Le taux d’utilisation du processeur SQL Server est inférieur à 50 %.

• Le taux d’utilisation du processeur du serveur d’applications est inférieur à 50 %.

• Le taux d’échec est inférieur à 0,01 %.

Définitions des tests

Le tableau suivant définit les tests et donne un aperçu du processus utilisé pour chaque test.

Nom du test	Description du test
Transfert d’un document	Transférer un document. Modifier et mettre à jour les propriétés du document.
Transfert et acheminement d’un document	Transférer un document. Modifier et mettre à jour les propriétés du document. Acheminer le document en fonction d’une règle de routage.
Téléchargement d’un document	Télécharger un document.
Accéder à une bibliothèque de documents	Accéder à une page d’affichage de liste d’une bibliothèque de documents.
Accéder à une page d’accueil comportant des composants WebPart Requête de contenu	Accéder à une page d’accueil du site Centre de documents dans laquelle se trouvent trois composants WebPart Requête de contenu. Le composant WebPart Requête de contenu mis en cache retourne les 15 documents les mieux notés. Le composant WebPart Requête de contenu mis en cache retourne les 15 documents les plus récents. Le composant WebPart Requête de contenu non mis en cache retourne les 15 éléments les plus récents qui ont été modifiés par l’utilisateur actuel.
Requête de secours sur les métadonnées gérées	Requête d’affichage de liste qui retourne plus de 5 000 résultats, avec filtrage sur une colonne de métadonnées gérées à valeur unique.
Requête sélective sur les métadonnées gérées	Requête d’affichage de liste qui retourne 1 000 résultats, avec filtrage sur une colonne de métadonnées gérées à valeur unique.
Requête de secours sur les types de contenu	Requête d’affichage de liste qui retourne plus de 5 000 résultats, avec filtrage par type de contenu.
Requête sélective sur les types de contenu	Requête d’affichage de liste qui retourne 1 000 résultats, avec filtrage par type de contenu.

Combinaison de tests

La composition de chaque combinaison de tests était variable. Les tests ont été menés à l’aide d’un système de test Visual Studio. Des points de données spécifiques pour chaque test ont été remplis, puis la combinaison de tests a été exécutée pendant 2 minutes de préparation et 10 minutes de collecte de données. Les résultats présentés dans cet article sont une moyenne sur ces 10 minutes. Le tableau suivant indique le pourcentage de chaque solution dans une combinaison de tests.

Nom de la solution	Pourcentage dans la combinaison
Transfert d’un document (y compris la modification des propriétés du document)	20
Téléchargement d’un document	20
Accéder à une bibliothèque de documents	20
Accéder à une page d’accueil comportant des composants WebPart Requête de contenu	10
Requête de secours sur les métadonnées gérées (plus de 5 000 résultats)	5
Requête sélective sur les métadonnées gérées (100 résultats)	10
Requête de secours sur les types de contenu (plus de 5 000 résultats)	5
Requête sélective sur les types de contenu (100 résultats)	10

Limitation et limites

Les limites empêchent les opérations d’affecter les performances de la batterie de serveurs. Ces valeurs par défaut ont été testées et minutieusement choisies. Pour certaines limites, telles que le seuil d’affichage de liste, il est vivement recommandé de ne pas modifier la valeur. Évaluez attentivement l’impact de la modification de ces limites. Si ces limites empêchent l’exécution d’une opération, envisagez de modifier l’opération de manière à ce qu’elle s’exécute en tirant mieux parti des fonctionnalités d’indexation plutôt que de modifier la limite au point de rendre acceptables des opérations faiblement performantes. Vous pouvez configurer la plupart des limitations et des limites couvertes dans cette section dans l’Administration centrale ; pour ce faire, dans Gérer les applications Web, sélectionnez Paramètres généraux – Limitation de ressources dans le Ruban associé à une application Web spécifique.

Seuil d’affichage de liste

SharePoint Server 2010 prend en charge les bibliothèques de documents et les listes comportant des dizaines de millions d’éléments. Vous pouvez créer des bibliothèques de documents très volumineuses en utilisant des dossiers, des affichages standard, des hiérarchies de site et la navigation par métadonnées. Pour récupérer des données de grandes listes à l’aide d’affichages de liste ou de requêtes CAML (Collaborative Application Markup Language), il est nécessaire que les données soient partitionnées à l’aide de dossiers et/ou d’index. Sinon, la recherche est le seul mécanisme permettant d’accéder aux données efficacement. Le nombre d’éléments qu’une bibliothèque de documents unique peut prendre en charge peut varier suivant l’organisation des documents et des dossiers, la taille et le type de documents stockés, l’utilisation de la bibliothèque de documents et le nombre de colonnes dans la bibliothèque de documents.

Conseil

L’introduction du seuil d’affichage de liste peut vous amener à vous interroger sur le lien avec la recommandation de 2 000 éléments par dossier dans le cas d’Office SharePoint Server 2007. Il semblerait qu’au lieu de 2 000, la nouvelle limite soit de 5 000. Si les utilisateurs explorent essentiellement du contenu à l’aide de dossiers, le concept est le même. Toutefois, avec l’introduction des fonctionnalités de réexécution et de secours de la navigation par métadonnées, les requêtes de grande taille retournent un sous-ensemble de résultats pour de meilleures performances. Cela signifie que les performances ne sont pas affectées si les requêtes retournent trop de résultats, même si les dossiers contiennent des milliers d’éléments.

Par défaut, le seuil d’affichage de liste empêche les opérations impliquant plus de 5 000 éléments, telles que les requêtes qui retournent plus de 5 000 éléments ou l’ajout d’une colonne à une liste qui contient plus de 5 000 éléments. Bien que ce paramétrage par défaut puisse être configuré, il est vivement recommandé de le garder tel quel. Si des requêtes faiblement performantes sont utilisées sur des listes comportant plus de 5 000 éléments, le débit global peut diminuer de manière significative lorsque vous augmentez cette limite.

Certaines opérations, telles que les requêtes non indexées ou l’ajout d’une colonne à une liste, prennent du temps et consomment des ressources proportionnellement au nombre d’éléments dans la liste. Dans le cas d’une petite liste, cela n’a pas d’importance, car elle contient si peu d’éléments que l’opération est rapide. À mesure que la taille de la liste augmente, ces opérations prennent plus de temps et consomment davantage de ressources. Au lieu de laisser ces opérations s’exécuter librement, le seuil d’affichage de liste les bloque. Vous pouvez assimiler le seuil d’affichage de liste à une glissière de sécurité le long d’une route indiquant la nécessité de modifier la requête et le mode d’accès aux données, sinon vous devez effectuer l’opération en période de faible utilisation de la batterie de serveurs.

Le seuil d’affichage de liste est le nombre maximal d’éléments de liste ou de bibliothèque qu’une opération de base de données, telle qu’une requête, peut impliquer simultanément. Par défaut, ce seuil est défini sur 5 000 éléments. Cette limite a un impact majeur sur les grandes listes, car, de par la définition de ce seuil, une grande liste est une liste dont le nombre d’éléments est supérieur à cette limite. Les opérations qui dépassent cette limite sont limitées. Les opérations, telles que la création d’un index sur une liste qui dépasse cette limite, sont bloquées, car elles ont une incidence sur plus de 5 000 éléments. Cette limite empêche les requêtes présentant une sélectivité (éléments pouvant être filtrés efficacement à l’aide de critères de filtrage) de plus de 5 000 éléments. En outre, cette limite empêche également les requêtes qui effectuent un filtrage sur des colonnes non indexées. En effet, une requête qui implique un filtrage (et, dans certains cas, des tris) sur une colonne non indexée doit appliquer le filtre à tous les éléments de la liste pour récupérer le jeu de données adéquat et elle portera sur un nombre d’éléments supérieur au seuil d’affichage de liste. La valeur par défaut de cette limite est basée sur les performances de la batterie de serveurs et des listes et sur la façon dont SQL Server gère les verrous. Il est recommandé de ne pas modifier cette limite.

Pour réduire au minimum le risque de conflit de base de données, SQL Server utilise un verrouillage des lignes comme stratégie pour garantir la précision des mises à jour sans affecter les utilisateurs qui accèdent à d’autres lignes. Toutefois, si une opération de base de données de lecture ou d’écriture, telle qu’une requête, entraîne le verrouillage de plus de 5 000 lignes simultanément, il est plus efficace pour SQL Server d’escalader le verrou à l’échelle de la table jusqu’à ce que l’opération de base de données soit achevée. Lorsque cette escalade de verrou se produit, elle empêche les autres utilisateurs d’accéder à la table. Pour plus d’informations sur les verrous, voir Escalade de verrous (moteur de base de données) (https://go.microsoft.com/fwlink/?linkid=219156&clcid=0x40C).

Le graphique suivant montre le débit d’une combinaison de requêtes sur une grande liste à mesure que le seuil d’affichage de liste est ajusté. Étant donné que cette combinaison de requêtes contient des requêtes qui renvoient tous les éléments de la liste, à mesure que le seuil d’affichage de liste est augmenté, davantage d’éléments sont retournés. Même le fait de remplacer la limite par défaut de 5 000 par la valeur 10 000 a un impact significatif sur les performances. Au lieu d’augmenter ou de diminuer le seuil d’affichage de liste pour améliorer les performances, il est recommandé de ne pas modifier le seuil d’affichage de liste par défaut et de faire en sorte que les requêtes soient performantes.

Le déclenchement d’exceptions liées au seuil d’affichage de liste est le signe que les opérations ne sont pas performantes. Dans ce cas, les opérations doivent être reconfigurées. Plutôt que d’augmenter la limite, vous devez analyser les raisons pour lesquelles des opérations inefficaces sont exécutées, puis apporter les corrections nécessaires aux opérations. Dans le scénario le plus défavorable, vous pouvez temporairement définir le paramètre EnableThrottling sur false pour une liste spécifique afin que le seuil d’affichage de liste soit ignoré. Cette opération ne peut être réalisée qu’au niveau de la liste ; il est impossible de l’effectuer pour un site. Sa finalité est d’autoriser l’accès à la liste uniquement jusqu’à ce que des modifications soient apportées pour corriger les opérations faiblement performantes bloquées par le seuil d’affichage de liste. Le paramètre EnableThrottling doit être redéfini sur true aussi rapidement que possible.

Important

Les exceptions liées au seuil d’affichage de liste peuvent être courantes, notamment juste après une mise à niveau. Il peut sembler plus simple de résoudre ces problèmes en modifiant le seuil d’affichage de liste. Toutefois, il est vivement recommandé de ne pas modifier le seuil d’affichage de liste.

Les administrateurs de batterie et les administrateurs d’ordinateur locaux sur le serveur Web frontal, d’où provient une requête, ne sont pas bloqués par le seuil d’affichage de liste. Ces utilisateurs doivent agir avec prudence lorsqu’ils accèdent à des grandes listes qui ne sont pas configurées correctement et lorsqu’ils effectuent des tests. Il peut sembler que tout fonctionne normalement, alors que les données retournées aux utilisateurs peuvent différer sensiblement. Pour une liste des opérations bloquées par le seuil d’affichage de liste, voir Opérations bloquées par le seuil d’affichage de liste plus loin dans cet article.

De même, les services du minuteur peuvent être exécutés à l’aide d’un compte qui n’est pas protégé par le seuil d’affichage de liste. Bien que cela autorise certains scénarios, tels que la création différée d’un index sur une grande liste, vous devez, en règle générale, être particulièrement attentif à ce que votre code n’effectue pas d’opérations sur des grandes listes.

Seuil d’affichage de liste

Par défaut : 5 000	Fonctionnalité présente dans la version 2007 : non	Configurable : oui
Emplacement de la configuration : Administration centrale, par application Web

Seuil d’affichage de liste pour les auditeurs et les administrateurs

Par défaut : 20 000	Fonctionnalité présente dans la version 2007 : non	Configurable : oui
Emplacement de la configuration : Administration centrale, par application Web

Le seuil d’affichage de liste pour les auditeurs et les administrateurs est le seuil d’affichage de liste utilisé pour certains comptes de service, tels que le compte de requête de recherche ou les comptes super en lecture ou en écriture dans le cache d’objets. Par exemple, le composant WebPart Requête de contenu utilise automatiquement cette limite pour mettre en cache les résultats d’une requête de grande taille, ce qui permet d’économiser des ressources serveur. Vous pouvez utiliser du code personnalisé pour demander l’utilisation de cette limite supérieure si vous opérez sous un compte super en lecture ou en écriture défini par une stratégie de sécurité d’application Web.

Autoriser le remplacement du modèle objet

Par défaut : oui	Fonctionnalité présente dans la version 2007 : non	Configurable : oui
Emplacement de la configuration : Administration centrale, par application Web

Le fait d’autoriser le remplacement du modèle objet spécifie si les comptes de service peuvent utiliser le seuil d’affichage de liste pour les auditeurs et les administrateurs. Un administrateur de batterie doit activer le remplacement du modèle objet et spécifier par programme qu’une liste est une exception. Ensuite, les programmeurs disposant de l’autorisation appropriée peuvent demander par programme que leur requête ou liste utilise la limite supérieure du seuil d’affichage de liste afin que les auditeurs et les administrateurs puissent en tirer parti. Lorsque la valeur est définie sur « no », le code personnalisé exécuté par les auditeurs ou les administrateurs, même s’il demande un remplacement, sera tributaire du seuil d’affichage de liste plutôt que de la limite supérieure pour les auditeurs et les administrateurs. Il est recommandé de laisser ce paramètre défini sur la valeur par défaut et de ne configurer le seuil d’affichage de liste pour les auditeurs et les administrateurs que si cela est nécessaire.

Fenêtre de délai quotidien

Par défaut : désactivée	Fonctionnalité présente dans la version 2007 : non	Configurable : oui
Emplacement de la configuration : Administration centrale, par application Web

Une fenêtre de délai quotidien peut être définie afin que les opérations soient exécutées sans être tributaires du seuil d’affichage de liste. Le délai peut être ajusté par incréments de 15 minutes, dans la limite de 24 heures. Une requête ou une opération de base de données démarrée pendant la fenêtre de délai quotidien s’exécute complètement, même si elle ne prend pas fin pendant la fenêtre de délai spécifiée. Par défaut, la fenêtre de délai quotidien n’est pas configurée, car les heures creuses varient sensiblement d’un déploiement à l’autre. Par conséquent, la décision en revient à l’administrateur. Il est recommandé de ne spécifier une fenêtre de délai quotidien que s’il existe une plage d’heures creuses acceptable pendant laquelle peu de personnes utilisent l’application Web. Cela permet aux utilisateurs d’effectuer des opérations administratives pour les grandes listes, telles que la création d’un index, pendant les plages horaires au cours desquelles la batterie de serveurs est beaucoup moins utilisée.

Autorisations uniques

À mesure que le nombre d’autorisations uniques dans une liste augmente, les performances diminuent. Vous devez repenser toute conception dans laquelle la totalité ou la majeure partie du contenu d’une grande liste doit être sécurisée de manière unique. La différence de débit pour les opérations sur une liste selon qu’il existe 0 ou 1 000 autorisations uniques est d’environ 20 %. Par défaut, le nombre d’autorisations par liste est de 50 000, valeur qui peut être configurée. Toutefois, il est recommandé d’abaisser cette limite à 5 000 autorisations uniques et, pour les grandes listes, de recourir à une conception qui utilise le moins d’autorisations uniques possible. Cela permet d’améliorer les performances, mais également la facilité de gestion.

Nous vous recommandons ce qui suit :

• Réduisez au minimum l’utilisation d’autorisations uniques sur les éléments individuels et simplifiez les conceptions de liste dans lesquelles la plupart des éléments doivent posséder des autorisations uniques.

• Si des autorisations uniques sont nécessaires, essayez de ne les définir qu’au niveau de la liste ou du dossier et réduisez au minimum le nombre d’éléments individuels nécessitant des autorisations uniques.

• Repensez votre conception si chaque élément requiert des autorisations spécifiques. Envisagez de répartir les éléments entre plusieurs listes ou de les organiser en dossiers et groupes afin qu’un accès approprié puisse être accordé sans que des autorisations uniques soient définies sur chaque élément.

La définition d’autorisations affinées peut avoir une incidence sur les performances, ce qui peut poser des difficultés en termes de gestion si cette définition varie sur de nombreux éléments individuels. La définition d’autorisations affinées sur une liste ou sur un dossier qui dépasse le seuil d’affichage de liste sera bloquée, car trop d’éléments individuels doivent être mis à jour. Toutefois, la définition d’autorisations affinées a également une incidence sur les performances sous d’autres formes. Par conséquent, il existe une limite configurable qui, par défaut, est de 50 000 autorisations uniques par liste. Il est impossible de déclarer des autorisations uniques une fois que cette limite a été atteinte. À la différence du seuil d’affichage de liste, cette limite s’applique lorsque vous créez des autorisations uniques sur un élément, plutôt qu’au moment de l’exécution de la requête.

Chaque fois qu’un héritage des autorisations est rompu pour un élément, tel qu’un dossier, cela se traduit par la comptabilisation d’une autorisation unique vis-à-vis de cette limite. Chaque fois que l’héritage des autorisations est rompu, un ID d’étendue est créé. Chaque fois que vous exécutez une requête sur un affichage, vous créez une jointure avec la table des étendues. Par la suite, lorsqu’une requête est exécutée, chaque liste de contrôle d’accès unique doit être analysée et traitée. Un nombre élevé d’autorisations uniques dans une liste affecte les performances et n’est pas recommandé. À mesure que le nombre d’autorisations uniques dans une liste croît, les performances des requêtes se dégradent. Même si la limite par défaut est de 50 000 autorisations uniques, vous pouvez envisager de réduire cette limite à 5 000 autorisations uniques.

Autorisations uniques

Par défaut : 50 000	Fonctionnalité présente dans la version 2007 : non	Configurable : oui
Emplacement de la configuration : Administration centrale, par application Web

Retour automatique à la ligne

Lorsque des colonnes sont ajoutées à une liste, elles sont mappées sur des colonnes dans une table de base de données SQL Server. Chaque ligne de la table de base de données prend en charge un nombre fixe des différents types de colonne. Par exemple, supposons qu’une ligne de table de base de données unique prenne en charge huit colonnes date/heure et douze colonnes numériques. S’il existe plus de huit colonnes date/heure, chaque élément de liste utilise deux lignes dans la table de base de données.

Dans le cas des petites listes, l’impact sur les performances de ce retour automatique à la ligne est négligeable. Toutefois, dans le cas d’une grande liste, l’impact peut être significatif. Vous pouvez atteindre la limite pour un nombre quelconque de colonnes avant que le retour automatique à la ligne ne se produise, mais il suffit qu’un seul type de colonne dépasse la limite pour que le retour automatique à la ligne soit appliqué.

Le tableau suivant indique le nombre de colonnes pour des types de données spécifiques au-delà duquel le retour automatique à la ligne se produit.

Type de colonne	Nombre de colonnes par ligne de table
Une seule ligne de texte ou Choix et plusieurs lignes de texte	64 32
Date et heure	8
Oui ou non	16
Numérique et monétaire	12
Calculé	8
Entier, recherche à valeur unique, personnes et groupes, métadonnées gérées	16
identificateur unique	1

Le retour automatique à la ligne entraîne une diminution du débit d’environ 35 % par ligne supplémentaire pour la plupart des opérations. Pour vérifier le nombre de lignes utilisées par une liste, vous devez analyser le schéma de liste et examiner les types de colonne pour les champs de la liste.

Le graphique suivant indique l’évolution des performances de requêtes en lecture seule à mesure que le nombre de lignes de base de données SQL Server utilisées pour une liste croît afin que soit pris en charge un nombre accru de colonnes de métadonnées gérées. Pour atteindre la deuxième ligne, 15 colonnes de métadonnées gérées ont été ajoutées à la liste, contre 31 pour atteindre la troisième ligne. Les tests ont été effectués uniquement à l’aide de requêtes exécutant un filtrage sur les éléments de la liste. Pour chaque ligne supplémentaire, le débit diminue de 35 %.

Taille limite des lignes

Par défaut : 6	Fonctionnalité présente dans la version 2007 : non	Configurable : oui
Emplacement de la configuration : modèle objet uniquement, SPWebApplication.MaxListItemRowStorage

La taille limite des lignes spécifie le nombre maximal de lignes de table internes à la base de données utilisé pour chaque élément d’une liste. Pour prendre en charge des listes volumineuses qui possèdent de nombreuses colonnes, chaque élément est réparti sur plusieurs lignes de table internes, dans la limite de six lignes. Par exemple, si une liste possède de nombreuses petites colonnes, telle qu’une liste contenant des centaines de colonnes Oui/Non, vous pouvez atteindre cette limite. Dans ce cas, vous ne pouvez pas ajouter de colonnes Oui/Non à la liste. Toutefois, vous pouvez ajouter des colonnes d’autres types. Étant donné que chaque ligne supplémentaire se traduit par une surcharge, dans le cas d’une grande liste, vous devez réduire au minimum le nombre de colonnes de mêmes types pour éviter les retours automatiques à la ligne.

Colonnes de recherche et affichages de liste

Chaque colonne de recherche dans un affichage de liste entraîne une jointure avec une autre table. Chaque colonne de recherche supplémentaire dans un affichage accentue la complexité des requêtes de navigation par métadonnées et d’affichage de liste. Outre les colonnes de recherche standard, les colonnes de métadonnées gérées à valeur unique, les colonnes de métadonnées gérées à valeurs multiples, les colonnes de personnes et de groupe à valeur unique et les colonnes de personnes et de groupe à valeurs multiples sont comptabilisées comme des colonnes de recherche. L’ajout de colonnes de recherche à un affichage ne se traduit pas par une diminution progressive ou linéaire des performances ; en revanche, celles-ci demeurent relativement stables avant de diminuer rapidement à partir de huit colonnes.

Le graphique suivant indique l’évolution du débit à mesure que le nombre de colonnes de recherche dans un affichage augmente. Comme vous pouvez le constater, l’évolution des performances de zéro à huit colonnes est relativement stable, mais le débit diminue sensiblement à partir de 10 colonnes de recherche. Ce test a été réalisé avec la liste limitée à une seule ligne. Si une liste utilise le retour automatique à la ligne, les performances se dégradent plus rapidement.

Le graphique suivant montre l’évolution de l’utilisation processeur SQL Server à mesure que le nombre de colonnes de recherche dans un affichage augmente. Comme vous pouvez le constater, il y a un changement significatif à partir de 10 colonnes de recherche. Dans le cas d’une liste possédant un nombre élevé de requêtes, si les affichages contiennent plus de huit colonnes de recherche, les requêtes utilisent une quantité de ressources SQL Server disproportionnée. Il est recommandé de ne pas définir cette limite sur une valeur supérieure à huit.

Bien que cette diminution des performances ne concerne pas le nombre total de colonnes de recherche dans une liste, mais seulement le nombre de colonnes de recherche dans un affichage ou dans une requête, SharePoint Workspace ne peut pas synchroniser une liste qui possède plus de huit colonnes de recherche, que les colonnes soient ou non utilisées dans un affichage.

Seuil de recherche d’affichage de liste

Par défaut : 8	Fonctionnalité présente dans la version 2007 : non	Configurable : oui
Emplacement de la configuration : Administration centrale, par application Web

Autres limites

Cette section décrit des limites qui ne sont pas abordées ailleurs dans cet article.

Index par liste

Par défaut : 20

Fonctionnalité présente dans la version 2007 : oui, la limite était de 10

Configurable : non

Le tableau précédent indique le nombre maximal d’index pouvant être créés par liste, y compris les index composés et les index créés par SharePoint Server 2010. Cette limite n’est pas configurable.

Mode feuille de données et exportation vers Excel

Par défaut : 50 000

Fonctionnalité présente dans la version 2007 : non

Configurable : non

Le tableau précédent indique le nombre maximal d’éléments pouvant être utilisés lors d’une exportation vers Microsoft Excel et avec le mode feuille de données. Toutefois, le mode feuille de données sera bloqué par le seuil d’affichage de liste. Par conséquent, si votre seuil d’affichage de liste est de 5 000 éléments et qu’un affichage de liste contient entre 5 000 et 50 000 éléments, lorsque vous essayez d’utiliser le mode feuille de données, vous obtenez un message exception d’affichage de liste même si la limite du mode feuille de données est supérieure.

SharePoint Workspace

Par défaut : 30 000 éléments par liste

Fonctionnalité présente dans la version 2007 : non

Configurable : non

Microsoft SharePoint Workspace possède une limite non-configurable qui empêche la synchronisation d’une liste comportant plus de 30 000 éléments. Si une liste contient 30 000 éléments, les utilisateurs ne peuvent pas la synchroniser à l’aide de SharePoint Workspace et les éléments ne peuvent pas être synchronisés de façon sélective.

Différences entre les grandes listes et les listes ordinaires

Lorsqu’une liste dépasse le seuil d’affichage de liste, certaines opérations qui auraient pu fonctionner auparavant sont bloquées. Le principal sujet de préoccupation est l’affichage de liste par défaut, car c’est ce à quoi les utilisateurs recourent le plus fréquemment pour accéder à une liste. Les affichages de liste doivent être configurés de manière à fonctionner correctement pour une grande liste. Par exemple, une erreur se produit lorsque vous accédez à une liste si la racine de la liste contient un nombre d’éléments supérieur au seuil d’affichage de liste. Si la fonctionnalité de navigation par métadonnées est activée, un sous-ensemble des résultats apparaît plutôt qu’une erreur.

Le seuil d’affichage de liste bloque toute opération de base de données qui a une incidence sur un nombre d’éléments supérieur au seuil d’affichage de liste ; le seuil ne bloque pas seulement le nombre d’éléments retournés ou modifiés. Par exemple, si un filtre sur une colonne non indexée retourne 100 résultats et que la liste contient 10 000 éléments, la requête échoue, car elle doit effectuer une analyse de la totalité des 10 000 éléments. Si vous ajoutez un index à cette colonne, l’opération est limitée à seulement 100 éléments et est couronnée de succès.

Les opérations sur les grandes listes peuvent être classées dans les deux groupes suivants :

• La liste dépasse le seuil d’affichage de liste   Certaines opérations sont bloquées lorsque la taille de la totalité de la liste dépasse le seuil d’affichage de liste, même si les éléments sont répartis dans des dossiers. Ces opérations comprennent les requêtes récursives, telles que la gestion des versions extraites, qui fonctionne sur tous les éléments indépendamment du dossier qui les abrite. Les affichages qui renvoient tous les éléments sans les dossiers sont également empêchés. En outre, les opérations qui ont une incidence sur la totalité de la liste, telles que l’ajout d’une colonne et la création ou la suppression d’index, sont bloquées.

• Le conteneur dépasse le seuil d’affichage de liste   Certaines opérations sont bloquées, car un dossier ou la racine de la liste contient un nombre d’éléments supérieur au seuil d’affichage de liste. Par exemple, si une liste contient 10 000 éléments et qu’un dossier comprend 3 000 éléments, vous pouvez renommer ou supprimer le dossier. Toutefois, si le dossier contient 6 000 éléments (soit un nombre supérieur au seuil d’affichage de liste), vous ne pouvez pas le supprimer, car l’opération dépasse le seuil d’affichage de liste.

Lorsqu’une liste dépasse le seuil d’affichage de liste, vous devez envisager de configurer correctement les affichages et les autres options de navigation. Dans l’idéal, vous devez configurer les affichages et les autres options de navigation à l’avance, mais souvent les listes peuvent croître rapidement au point de dépasser le seuil d’affichage de liste et nécessitent alors une action. Certaines opérations, telles que la création d’une colonne ou l’indexation d’une colonne dans une liste qui contient de nombreux éléments, prennent beaucoup de temps. Ces opérations sont bloquées par le seuil d’affichage de liste. Toutefois, elles peuvent être réalisées pendant la fenêtre de délai quotidien ou par les administrateurs de batterie ou d’ordinateur. Vous devez préparer ces opérations. Si la liste est déjà trop grande, envisagez d’utiliser une fenêtre de délai quotidien ou des informations d’identification administratives pour réaliser ces opérations.

Conseil

Le seuil d’affichage de liste empêche certaines actions d’administration de liste qui sont courantes dans le cadre de la configuration d’une liste. Dans la mesure du possible, vous devez configurer la totalité des types de contenu, des colonnes et des index d’une liste avant que la taille de celle-ci ne dépasse le seuil d’affichage de liste.

Une liste peut devenir si grande que certaines opérations réalisées à l’aide d’un navigateur Web risquent de ne pas s’exécuter dans le délai imparti. Par exemple, si une liste contient des millions de documents, l’ajout d’une nouvelle colonne risque de prendre beaucoup de temps. Pour accomplir cette opération, vous devriez alors utiliser Windows PowerShell et opérer impérativement pendant des heures creuses, car cette intervention bloque les opérations des autres utilisateurs.

Opérations bloquées par le seuil d’affichage de liste

Les tableaux suivants répertorient les opérations bloquées par le seuil d’affichage de liste.

Opérations bloquées lorsque la liste dépasse le seuil d’affichage de liste

Opération	Description
Ajouter/supprimer/mettre à jour une colonne de liste	Toutes les colonnes, y compris les colonnes de recherche et calculées, en plus des nombreux types de mises à jour, telles qu’une modification de type ou d’unicité. Certaines mises à jour, telles qu’une modification de nom, ne sont pas bloquées, car elles n’ont pas une incidence sur chaque élément de la liste.
Ajouter/supprimer/mettre à jour un type de contenu de liste	Affecte chaque élément de la liste de sorte que l’opération est bloquée pour toute liste dont le nombre d’éléments est supérieur au seuil d’affichage de liste.
Créer/supprimer un index	Affecte chaque élément de la liste de sorte que l’opération est bloquée pour toute liste dont le nombre d’éléments est supérieur au seuil d’affichage de liste.
Gérer les fichiers dont aucune version n’est archivée	Requête récursive non indexée qui échoue pour toute liste possédant un nombre d’éléments supérieur au seuil d’affichage de liste.
Requêtes récursives non indexées	Comprend les filtres et certains tris. Cette opération échoue lorsque la taille de la liste dépasse le seuil d’affichage de liste. Étant donné l’absence d’index, l’opération effectue une analyse complète de la totalité de la liste. En outre, elle retourne tous les éléments et ignore les dossiers.
Requête de liste croisée	Comprend les requêtes exécutées par le composant WebPart Requête de contenu et suit le paramètre du seuil d’affichage de liste pour les auditeurs et les administrateurs, défini par défaut sur 20 000 éléments. Si l’opération implique plus de 20 000 éléments, la requête échoue.
Colonnes de recherche qui appliquent le comportement des relations	Vous ne pouvez pas créer de colonnes de recherche qui appliquent le comportement des relations lorsque la liste référencée contient un nombre d’éléments supérieur au seuil d’affichage de liste.
Suppression d’une liste	Affecte chaque élément de la liste de sorte que l’opération est bloquée pour toute liste dont le nombre d’éléments est supérieur au seuil d’affichage de liste.
Suppression d’un site	Si la somme de tous les éléments d’un site est supérieure au seuil d’affichage de liste, la suppression du site est bloquée, car elle affecte trop d’éléments.
Enregistrer une liste en tant que modèle avec les données	Affecte chaque élément de la liste de sorte que l’opération est bloquée pour toute liste dont le nombre d’éléments est supérieur au seuil d’affichage de liste.
Affichage de totaux dans les affichages de liste	Exécute une requête sur chaque élément de la liste de sorte que l’opération est bloquée pour toute liste dont le nombre d’éléments est supérieur au seuil d’affichage de liste.
Activer/désactiver les pièces jointes dans une liste	Affecte chaque élément de la liste de sorte que l’opération est bloquée pour toute liste dont le nombre d’éléments est supérieur au seuil d’affichage de liste.

Opérations bloquées lorsque le conteneur dépasse le seuil d’affichage de liste

Opération	Description
Supprimer/copier/renommer un dossier	L’opération échoue lorsque le dossier contient un nombre d’éléments supérieur au seuil d’affichage de liste, car elle affecte trop de lignes.
Requêtes qui filtrent sur des colonnes non indexées	Échoue lorsque le conteneur (dossier ou liste) comporte un nombre d’éléments supérieur au seuil d’affichage de liste. L’opération effectue une analyse complète de la totalité du dossier, car il n’y a pas d’index.
Définir des autorisations de sécurité affinées	L’opération échoue lorsque la liste ou le dossier sur lesquels vous essayez de définir des autorisations affinées contient un nombre d’éléments supérieur au seuil d’affichage de liste, car elle affecte trop de lignes. Vous pouvez néanmoins définir des autorisations affinées sur les éléments enfants, tels que les documents, dans une grande liste, bien que vous ne puissiez pas les définir sur la liste elle-même ou sur des dossiers qui comportent un nombre d’éléments supérieur au seuil d’affichage de liste.
Ouvrir avec l’Explorateur	N’affiche aucun élément si un conteneur comporte un nombre d’éléments supérieur au seuil d’affichage de liste (à l’exclusion des éléments dans les sous-dossiers). Si un dossier contient 8 000 éléments, dont 4 000 éléments dans un sous-dossier et uniquement 4 000 éléments à la racine, l’opération Ouvrir avec l’Explorateur fonctionne. Si la racine d’une liste contient un nombre d’éléments supérieur au seuil d’affichage de liste, l’opération Ouvrir avec l’Explorateur n’affiche rien du tout. Pour que l’opération Ouvrir avec l’Explorateur fonctionne, il faut que les éléments de la liste soient organisés dans des dossiers comportant un nombre d’éléments inférieur au seuil d’affichage de liste à la racine d’un conteneur donné.

Fonctionnalités disponibles sujettes à des dysfonctionnements

Cette section contient des informations sur les fonctionnalités qui risquent de ne pas fonctionner normalement avec des grandes listes.

Mode Feuille de données

Le bouton du mode feuille de données disponible dans l’onglet d’une bibliothèque de documents, sur le Ruban de la bibliothèque, n’est pas désactivé si le nombre d’éléments dans la liste dépasse le seuil d’affichage de liste. Toutefois, en cas de dépassement, l’affichage charge certains éléments et le message « Vous n’êtes pas autorisé à afficher la totalité de la liste car sa longueur dépasse le seuil imposé par l’administrateur » apparaît. Vous pouvez désactiver l’option mode feuille de données dans le Ruban à partir des paramètres de la liste. En outre, en raison de l’existence d’une limite non modifiable de 50 000 éléments, cet affichage est bloqué même si le seuil d’affichage de liste est supérieur à 50 000 éléments.

Planification de la conception et de l’implémentation des grandes listes

Avant d’implémenter une grande liste, analysez le projet et ses contraintes. Parmi celles-ci, le contrat de niveau de service, le calendrier des sauvegardes et des restaurations, la taille du contenu, la quantité de contenu (nombre d’éléments) et les temps d’accès sont tous autant de points que vous devez prendre en considération. Suivant la taille et les exigences de l’application, vous devez prendre des décisions importantes à plusieurs niveaux, notamment concernant la configuration matérielle, le stockage de contenu et l’architecture de l’information SharePoint Server 2010. Une application volumineuse qui possède des millions d’éléments et des centaines d’utilisateurs simultanés peut nécessiter une configuration matérielle autonome pour le projet, bien qu’un référentiel de documents avec des dizaines d’utilisateurs simultanés et des dizaines de milliers de documents puisse fonctionner correctement avec la configuration matérielle partagée existante et avec une seule bibliothèque de documents dans un site existant.

Au terme de la planification, vous devrez avoir déterminé une liste de types de colonne (noms, type de données et utilisation), des index, une structure de dossiers, l’utilisation des pages et des liens pour la navigation, une structure d’autorisations planifiée, une estimation du nombre d’éléments et la taille totale des données. Vous devez également inclure des informations sur les types de requêtes qui seront exécutées et sur les modalités d’accessibilité, de création et de mise à jour des données de la liste.

Après avoir planifié la conception et l’implémentation d’une grande liste, l’étape suivante consiste à concevoir et à créer un prototype. Cette phase de planification comprend la conception de la grande liste, l’implémentation d’une preuve de concept et la validation de son fonctionnement. À ce stade, il peut être utile de remplir un environnement de test avec une grande quantité de contenu pour valider les hypothèses relatives à l’accessibilité des données et aux performances. Le résultat final du processus de conception doit être une preuve de concept de la liste envisagée, une documentation des colonnes, des types de contenu, une structure des dossiers, des affichages, des index, des colonnes utilisées pour la navigation par métadonnées ou autres méthodes de récupération, toutes les taxonomies utilisées, l’utilisation des différents composants WebPart et l’utilisation d’autres fonctionnalités telles que l’organisateur de contenu.

Estimation de la taille du contenu

Dans le cas des grandes listes, il est important d’estimer une série de valeurs pour prendre des décisions en termes de planification et de conception de la capacité. Il existe quelques valeurs importantes que vous devez évaluer, notamment les suivantes :

• taille totale de la base de données de contenu ;

• tailles moyenne et maximale des fichiers ;

• nombre de versions ;

• quantité de contenu (nombre total d’éléments dans une liste)

Taille de la base de données de contenu

Il est important de planifier la taille totale de la base de données de contenu afin d’évaluer l’espace disque et la configuration matérielle requis, en plus de déterminer ce qui peut être pris en charge pour la sauvegarde, la restauration et un contrat de niveau de service. La taille globale de la base de données de contenu est l’élément le plus important pour l’évaluation de la quantité de temps mort nécessaire pour la sauvegarde et la restauration.

Vous pouvez estimer la taille de la base de données de contenu à l’aide de la formule suivante : taille moyenne des documents * nombre moyen de versions par document * nombre escompté de documents. Ajoutez 20 % pour les données de la base de données de contenu en plus des fichiers. Ce nombre est élevé, car la taille des versions augmente généralement au fil du temps, si bien que la taille de fichier moyenne des documents archivés est généralement supérieure à la taille de fichier moyenne de toutes les versions. Vous devez ajouter une marge significative au cas où la liste croîtrait plus que prévu, à moins que vous ne disposiez de mécanismes permettant de contrôler efficacement la quantité de contenu.

Tailles moyenne et maximale des fichiers

Vous devez déterminer la taille maximale des fichiers afin que le paramètre d’application Web adéquat soit spécifié pour le transfert des fichiers (par défaut 50 Mo, le maximum pouvant être 2 Go). La taille moyenne des fichiers permet d’évaluer le taux de croissance possible du contenu et la taille totale de celui-ci. Vous pouvez estimer la taille moyenne des fichiers en évaluant les fichiers dans les systèmes qui remplissent actuellement le rôle du système envisagé.

Conseil

Vous devez prévoir que 10 à 20 % seront ajoutés pour les données de la base de données de contenu en plus des fichiers et que l’index de recherche représentera approximativement 75 % de la taille de la base de données de contenu.

Nombre moyen de versions

Vous devez prendre en compte le contrôle de version, car il peut augmenter sensiblement la taille du contenu. Il existe différentes méthodes permettant de limiter les versions. Par exemple, vous pouvez utiliser des stratégies de rétention en gestion des informations pour supprimer toutes les versions antérieures après une période spécifique ou vous pouvez limiter le nombre de versions à enregistrer. D’autres facteurs ont également une incidence sur les versions ; par exemple, si le référentiel reçoit la totalité de son contenu par le biais d’un organisateur de contenu, il est possible qu’il n’existe aucune version, car l’organisateur de contenu ne copie que la version la plus récemment archivée. Si des documents du référentiel sont activement modifiés par des utilisateurs, vous devrez peut-être prendre en considération la co-création ; chaque session de co-création crée une version automatiquement. Analysez l’utilisation du référentiel et évaluez les solutions existantes pour estimer le nombre moyen de versions qui seront créées pour un document.

Quantité de contenu

La quantité de contenu est le nombre total d’éléments dans une liste spécifique. Pour estimer la quantité de contenu, vous devez évaluer les sources existantes de contenu et ce qui sera déplacé vers le nouveau système ou déterminer le nombre d’utilisateurs qui utiliseront le système, ainsi que la finalité de celui-ci. Il existe d’autres valeurs connexes, notamment le nombre d’éléments par conteneur et le nombre d’éléments par pivot de métadonnées ou filtre d’index. Ces valeurs sont également importantes lorsque vous planifiez les affichages et la navigation par métadonnées.

Stockage BLOB distant

Les listes qui nécessitent un espace de stockage volumineux peuvent jouer un rôle déterminant dans le choix de la solution de stockage des documents. Par défaut, SharePoint Server 2010 stocke tous les documents en tant qu’objets BLOB dans la base de données SQL Server. SharePoint Server 2010 et SQL Server 2008 fournissent une API de stockage BLOB distant, qui permet de stocker les documents en dehors de la base de données SQL Server, ce qui réduit la taille de la base de données. La décision d’utiliser ou non le stockage BLOB distant est étroitement liée aux économies réalisables.

Les tests actuellement menés par Microsoft montrent que le stockage BLOB distant se traduit par une diminution de 5 à 10 % du débit et que, dans le cas des fichiers volumineux, il n’entraîne aucune différence de latence perceptible. Toutefois, les performances peuvent différer suivant le fournisseur de stockage BLOB distant utilisé. L’utilisation du stockage BLOB distant entraîne une diminution de la taille de la base de données de contenu. Toutefois, cela ne signifie pas nécessairement que vous pouvez stocker davantage d’éléments dans une base de données de contenu. Les performances sont tributaires de la quantité d’éléments dans les listes dans la base de données SQL Server ; même si les objets BLOB sont supprimés, la taille de la liste ne change pas. Il existe quelques scénarios dans lesquels les avantages en termes de coûts peuvent facilement l’emporter sur les questions liées aux performances :

• Archivage, données non collaboratives ;

• stockage d’objets BLOB très volumineux tels que des vidéos et des images rarement mis à jour.

L’utilisation du stockage BLOB distant peut se traduire par l’ajout de serveurs et de technologie à votre batterie de serveurs et requiert l’ajout d’un fournisseur de stockage BLOB distant. Un fournisseur de stockage BLOB distant peut prendre en charge le stockage des objets BLOB sur des supports de stockage moins onéreux hors de la base de données SQL Server. SQL Server Enterprise est requis pour utiliser l’API du stockage BLOB distant.

Le stockage BLOB distant peut s’avérer économique dès lors que la taille des bases de données de contenu avoisine plusieurs téraoctets. Toutefois, cette situation ne peut pas justifier à elle seule l’utilisation du stockage BLOB distant. Vous devez attentivement vous pencher sur la sauvegarde et la restauration, ainsi que sur les contrats de niveau de service. Le stockage BLOB distant rend la récupération d’urgence plus difficile, car deux technologies doivent être synchronisées. Le point principal est le temps nécessaire pour restaurer le système après un incident et pour gérer les objets BLOB de sauvegarde et de récupération. Pour plus d’informations, voir Vue d’ensemble du stockage BLOB distant (SharePoint Server 2010).

Architecture des listes

Il est important de choisir l’architecture appropriée pour un projet de grandes listes, car les décisions peuvent être difficiles à modifier une fois implémentées. Vos efforts de préparation et d’analyse doivent porter sur la taille et la quantité de contenu, l’utilisation du référentiel, ainsi que sur les modalités d’ajout, de mise à jour et d’accessibilité du contenu. Tous ces éléments peuvent avoir une incidence sur l’organisation du contenu (dans une liste, plusieurs listes, voire plusieurs collections de sites), les métadonnées utilisées et la façon dont le contenu est récupéré. Toutes ces décisions sont particulièrement importantes pour une grande liste, car lorsque la quantité de contenu est volumineuse, il devient beaucoup plus difficile de repenser la façon dont un système est utilisé.

Une seule liste, plusieurs listes ou plusieurs collections de sites

Lorsque vous concevez une solution de grande liste, il est important de déterminer si une architecture à liste unique est appropriée. La décision de placer du contenu dans une liste unique doit reposer sur les besoins de l’entreprise, tels que la facilité d’utilisation du point de vue de l’exploitation et de la découverte du contenu. Dans de nombreux cas, il peut être préférable d’utiliser plusieurs listes. Vous devez privilégier la création d’une implémentation très conviviale, procurant une très bonne expérience utilisateur et bénéficiant des fonctionnalités de SharePoint Server 2010 et des ressources disponibles.

Utilisez une liste unique pour que les utilisateurs puissent facilement rechercher et exploiter du contenu sans qu’ils aient à décider où placer leur contenu ou à déterminer la liste à laquelle ils doivent accéder pour trouver ce qu’ils recherchent. Toutefois, à mesure que la quantité de contenu augmente, il peut également être plus difficile de rechercher du contenu, notamment à l’aide de méthodes telles que le filtrage des affichages ou la navigation dans les dossiers. Lorsqu’une liste atteint plusieurs centaines de milliers d’éléments, l’utilisation de la navigation par métadonnées peut s’avérer difficile. Les requêtes risquent de retourner des centaines ou des milliers de résultats, car elles ne sont pas suffisamment spécifiques.

Par exemple, si le domaine d’un index contient 5 000 termes et que chaque terme possède une quantité égale d’éléments correspondant au filtre, le filtrage sur un terme aboutit à 20 résultats dans le cas d’une liste de 100 000 éléments et à 200 résultats dans le cas d’une liste de 1 000 000 d’éléments. Si la taille de la liste est trop élevée, de nombreux filtres sélectionnés par les utilisateurs ne retournent pas d’ensemble de résultats leur permettant de trouver ce qu’ils recherchent. Si un projet comprend plusieurs types de contenu distincts facilement différentiables par les utilisateurs, vous devez envisager l’utilisation de plusieurs listes.

À très grande échelle, à l’image d’un scénario d’archivage étendu, il peut être utile d’envisager une architecture avec plusieurs collections de sites. Une nouvelle fonctionnalité SharePoint Server 2010 permet de regrouper les collections de sites afin d’équilibrer la charge des documents. La fonctionnalité d’organisateur de contenu permet d’acheminer les documents entre plusieurs collections de sites. La recherche doit être utilisée pour la récupération des documents. Cette configuration convient pour le stockage à long terme, car elle permet de répartir le contenu entre plusieurs collections de sites et, grâce à sa souplesse, de prendre en charge beaucoup plus de documents qu’une seule liste.

Synthèse des recommandations pour les listes

• Utilisez une seule liste pour des nombres élevés d’éléments dans les cas suivants :

  • Il n’est pas logique de placer les éléments dans des listes distinctes.

  • Cette configuration procurera la meilleure expérience utilisateur.

• Utilisez plusieurs listes pour les grandes quantités d’éléments dans les cas suivants :

  • Il est logique de regrouper les éléments dans plusieurs listes.

  • Cette configuration procurera la meilleure expérience utilisateur.

  • Il n’y aura pas de confusion parmi les utilisateurs quant à la liste à utiliser pour ajouter ou rechercher du contenu.

• Utilisez une architecture avec plusieurs collections de sites dans les cas suivants :

  • Le référentiel doit pouvoir accueillir une quantité d’éléments supérieure aux dizaines de millions d’éléments pris en charge par un référentiel unique.

  • Il est logique de regrouper les éléments dans plusieurs collections de sites, par exemple pour partitionner les données par année.

Métadonnées

Avec SharePoint Server 2010, les métadonnées et les types de contenu sont utiles pour la création d’une architecture de l’information. De nouvelles fonctionnalités, telles que les métadonnées gérées, les ensembles de termes et la navigation par métadonnées, rendent les métadonnées très utiles et importantes pour la récupération de contenu. Étant donné que les opérations, telles que la modification des types de contenu et des colonnes, sont bloquées sur les grandes listes, il est particulièrement important de planifier les besoins liés aux métadonnées. Si vous envisagez d’utiliser la navigation par métadonnées ou une autre méthode de récupération de contenu par métadonnées, il est important de planifier les types de contenu et les colonnes correspondantes pendant la phase de conception.

Dans la plupart des scénarios de grande liste, les métadonnées sont non seulement utiles, mais également indispensables pour l’utilisation du système par les utilisateurs. Les métadonnées peuvent être appliquées au moyen de trois méthodes principales : processus système intégrés, configurations et code personnalisés et application manuelle par les utilisateurs. La récupération de contenu à l’aide d’une colonne n’est possible que si la plupart des éléments possèdent une valeur spécifiée pour la colonne. Il est donc important de planifier les colonnes à utiliser pour la navigation et le mode de remplissage des métadonnées. La seule façon de garantir l’application des métadonnées appropriées consiste à utiliser des processus intégrés et des personnalisations. Par exemple, étant donné que chaque élément possède un type de contenu, si des types de contenu sont utilisés pour le classement des documents, chaque élément possède ces métadonnées, ce qui facilite le filtrage en fonction du type de contenu.

Types de contenu

La catégorisation de contenu la plus élémentaire doit faire appel aux types de contenu. Si vous disposez de métadonnées pour classer le contenu, tel que le type de document ou d’élément, vous devez envisager d’utiliser cette classification pour vos types de contenu. Les types de contenu vous permettent de définir les colonnes qui sont associées à un genre de contenu, en plus d’être associées à des flux de travail et au modèle. Un seul modèle peut être associé à un type de contenu, et c’est ce modèle que vous utilisez lorsque vous créez une instance du type de contenu à l’aide du menu Nouveau document dans une bibliothèque de documents.

Vous pouvez utiliser des modèles pour les formats de fichiers dans Microsoft Word, Microsoft PowerPoint et Excel, ainsi que dans d’autres produits. Lorsque les utilisateurs créent des instances du type de contenu, ils démarrent la création dans l’application cliente concernée à l’aide du modèle. Lorsque le contenu est transféré, les utilisateurs peuvent choisir parmi les types de contenu disponibles. Les types de contenu doivent être distincts, spécifiques et chaque liste doit posséder un nombre de types de contenu suffisamment réduit pour que les utilisateurs puissent sans difficulté sélectionner le type de contenu à utiliser.

Étant donné que les types de contenu contrôlent les métadonnées que les utilisateurs doivent remplir lorsqu’ils créent ou transfèrent un élément, déterminez les colonnes nécessaires pour répondre aux besoins de l’entreprise et réduire au minimum l’obstacle à l’envoi de contenu. Le choix d’un ensemble adéquat de types de contenu pour classer le contenu au niveau principal se traduit systématiquement par une amélioration de la navigation. Étant donné que chaque élément possède un type de contenu, il existe un pivot de filtrage opérationnel pour chaque élément.

Synthèse des recommandations pour les types de contenu

• Utilisez des types de contenu en guise de méthode la plus élémentaire pour organiser du contenu.

• Utilisez des types de contenu pour sélectionner les colonnes nécessaires pour le genre de contenu concerné.

• Les types de contenu par liste doivent être peu nombreux (pas plus de 10) et suffisamment distincts pour que les utilisateurs comprennent facilement le type de contenu à utiliser.

• Les types de contenu fournissent une colonne intégrée dont chaque élément possède une valeur qui peut être utilisée pour le filtrage et la navigation par métadonnées.

Exemple de grande liste collaborative et de types de contenu : bibliothèque de spécifications de produit

Une bibliothèque de spécifications de produit permet aux équipes de développement de produit de stocker les spécifications de la conception, les plans de test et les autres éléments du développement de produit. Dans cet exemple, les six types de contenu suivants sont utilisés. Tous les types de contenu possèdent une série de colonnes pour la date de début du projet, la date de fin du projet, le budget, les membres de l’équipe de conception, le nom du produit et le type de produit.

• Spécification du produit : fichier Word qui contient les détails de la conception d’un produit. Les métadonnées supplémentaires indiquent le concepteur et la date de révision finale.

• Spécification des tests : fichier Word qui contient le plan de test d’un produit. Les métadonnées supplémentaires indiquent le testeur et l’état d’achèvement des tests.

• Plan de développement : fichier Word qui contient le plan de développement du produit.

• Plan conceptuel : présentation PowerPoint qui permet de présenter les maquettes de la conception.

• Analyse du coût : feuille de calcul Excel qui analyse le coût de développement du produit et les opportunités commerciales potentielles.

• Chronologie : feuille de calcul Excel qui détaille la planification du développement du produit.

Dans cet exemple, les utilisateurs peuvent appliquer un filtre en fonction du type de contenu pour rechercher une spécification de produit ou un plan conceptuel de produit. En outre, les modèles personnalisés permettent de structurer le travail de l’utilisateur. Le nombre de colonnes et de types de contenu est suffisamment petit pour que les utilisateurs puissent facilement sélectionner les options appropriées pour leur travail, mais le remplissage des métadonnées facilite le filtrage et la recherche de contenu.

Colonnes

Nombre de colonnes et colonnes obligatoires

Vous pouvez utiliser des colonnes pour spécifier le type de métadonnées associé à un élément, et vous pouvez les marquer comme étant masquées, facultatives ou obligatoires. Utilisez des colonnes masquées pour les tâches automatisées, telles que les flux de travail, afin que les utilisateurs ne puissent pas les modifier. N’utilisez des colonnes obligatoires que lorsque cela est absolument nécessaire. Par exemple, une propriété de métadonnées peut être nécessaire pour l’acheminement d’un élément vers l’emplacement approprié ou pour la navigation. Dans ces cas, vous souhaitez que les utilisateurs indiquent une valeur. Moins il y a d’éléments dont les métadonnées sont remplies pour une colonne utilisée en tant que filtre de navigation, moins la navigation est utile, car de nombreux éléments ne seront jamais retournés par une requête.

À mesure que le nombre de colonnes de métadonnées augmente, il devient de moins en moins probable que les utilisateurs rempliront les métadonnées, en raison du travail supplémentaire à réaliser pour déterminer les colonnes qui s’appliquent, puis pour spécifier une valeur. Si vous utilisez un nombre élevé de colonnes obligatoires, l’adhésion de l’utilisateur peut s’avérer difficile à obtenir, car le transfert de contenu prend beaucoup de temps. Dans un scénario collaboratif et très ouvert, cela peut être préjudiciable. Toutefois, à mesure que le contenu prend de la valeur et que l’effort lié à sa création s’accentue, il devient de plus en plus probable que les utilisateurs prendront le temps de remplir les champs appropriés, notamment lorsque cette opération n’est pas fréquente.

Pendant la phase de conception, vous devez déterminer les métadonnées nécessaires à la réalisation des opérations requises et à la récupération du contenu, estimer le temps que devront consacrer les utilisateurs au remplissage de ces métadonnées et évaluer l’impact sur les utilisateurs. Si les utilisateurs n’adoptent pas le système en raison de la charge élevée liée à la création de contenu, il peut s’avérer difficile de restructurer le système ultérieurement.

Types de champs et champs à valeur unique ou à valeurs multiples

Lorsque vous choisissez les colonnes, vous devez déterminer leur type et si elles doivent être à valeurs multiples. Les requêtes sur les champs de métadonnées gérées étant plus efficaces que les requêtes sur les colonnes de choix, vous pouvez envisager l’utilisation de champs de métadonnées gérées au lieu de champs de choix. Les colonnes, telles que les métadonnées gérées et les personnes ou les groupes, peuvent prendre en charge plusieurs valeurs. Les requêtes sur les colonnes à valeurs multiples ne sont pas aussi efficaces que les requêtes sur les colonnes à valeur unique.

En règle générale, les colonnes et les types de contenu sont les composants centraux de la classification et de la récupération du contenu dans une grande liste. Une liste de colonnes et de types de contenu doit avoir été préparée pendant le processus de planification. Le nombre de colonnes et de types de contenu ajoutés à une liste peut avoir des incidences subtiles sur les performances. Le nombre de colonnes d’un type spécifique ajoutées à une liste unique entraîne un retour automatique à la ligne. Pour plus d’informations, voir Retour automatique à la ligne plus haut dans cet article.

Exemple de grande liste collaborative et de colonnes : bibliothèque de spécifications de produit

Cette section décrit les colonnes utilisées dans cet exemple :

• Colonnes automatiquement gérées par SharePoint Server 2010 : ID, Type de contenu, Date de modification, Date de création, Modifié par, Créé par, ID de document

• Colonnes gérées à l’aide de personnalisations :

  • Valeurs par défaut de métadonnées par dossier pour le type de produit et l’équipe de produit (chaque type de produit possède un dossier et chaque dossier de type de produit possède plusieurs dossiers d’équipe de produit)

  • Mise à jour des flux de travail : Statut d’approbation, Projet terminé

• Colonnes gérées par les utilisateurs : Concepteur, Testeur, Date de révision finale

• Colonnes qui fonctionnent correctement pour la navigation : Type de contenu, Type de produit, Équipe de produit

• Colonnes qui sont utilisées pour le suivi du statut et qui fonctionnent également pour la navigation : Date de révision finale, Statut d’approbation, Projet terminé

• Colonnes qui peuvent être utiles pour la navigation : Concepteur, Testeur, Nom du produit, Date de modification, Modifié par

Synthèse des recommandations pour les colonnes

• Réduisez au minimum le nombre de colonnes pouvant être remplies.

• Sélectionnez attentivement les colonnes qui seront utilisées pour les processus du système et pour la navigation. Déterminez les champs qui seront obligatoires et réduisez au minimum le nombre de champs obligatoires.

• Les champs obligatoires doivent être utilisés lorsqu’ils sont nécessaires pour la navigation, par exemple lors de l’utilisation de composants WebPart Requête de contenu par rapport à un champ spécifique. Ils doivent également être utilisés pour l’administration, par exemple lors de la spécification d’actions de rétention sur un champ date que les utilisateurs doivent spécifier.

• Étant donné que les requêtes sur les colonnes à valeur unique sont plus rapides que celles sur les colonnes à valeurs multiples, concevez des colonnes à valeur unique, sauf si plusieurs valeurs sont nécessaires.

Le nombre total de colonnes sur une liste peut entraîner un retour automatique à la ligne, ce qui réduit les performances. Réduisez au minimum le nombre de colonnes sur une grande liste et évitez le retour automatique à la ligne, dans la mesure du possible.

Dossiers

Vous devez déterminer attentivement le mode d’organisation du contenu en dossiers. Vous pouvez utiliser des dossiers essentiellement de trois façons :

• Organisez le contenu dans des dossiers de façon logique. Par exemple, organisez les contrats dans des dossiers en fonction de l’année ou du mois de leur signature, ou les factures en fonction de la date de leur création. Dans ce scénario, les utilisateurs peuvent facilement naviguer dans la structure des dossiers ou utiliser des métadonnées pour rechercher des documents. En outre, il est facile d’acheminer automatiquement les documents vers le dossier adéquat. L’organisateur de contenu possède des fonctionnalités qui permettent de limiter la quantité d’éléments dans un dossier spécifique en créant des sous-dossiers dès que le nombre d’éléments ajoutés dépasse une limite donnée.

• Organisez le contenu dans des dossiers pour des fonctions administratives, telles que la rétention et les autorisations. Par exemple, un dossier pour les documents confidentiels auquel un nombre réduit d’utilisateurs a accès ou une rétention basée sur l’emplacement de sorte que la planification de rétention d’un document dépende du dossier dans lequel il se trouve. Dans ce scénario, la navigation des utilisateurs peut s’avérer plus difficile, car ils ne se soucient pas forcément de l’emplacement d’un document tant qu’ils ont accès à celui-ci. La navigation par métadonnées et la recherche sont les méthodes dominantes de recherche de documents, plutôt que l’utilisation de la structure des dossiers.

• Organisez le contenu dans des dossiers pour faciliter la navigation des utilisateurs par sujets ou par catégories. De nombreux utilisateurs sont habitués à naviguer avec des dossiers. Pour des applications spécifiques, il peut s’avérer important de conserver une structure de dossiers dans laquelle les utilisateurs puissent naviguer facilement. Dans ce scénario, les utilisateurs comprennent généralement la structure de dossiers et savent où rechercher et placer les documents. La navigation par métadonnées et la recherche peuvent être utilisées conjointement avec cette méthode.

Les améliorations apportées dans SharePoint Server 2010 permettent d’utiliser les dossiers avec davantage de souplesse et d’être moins tributaire de considérations liées aux performances. Grâce aux métadonnées gérées et à la navigation par métadonnées, les utilisateurs peuvent facilement filtrer sur des métadonnées, plutôt que naviguer dans des dossiers. Cela vous permet d’organiser le contenu à des fins administratives, par exemple en fonction d’autorisations ou d’une stratégie, plutôt qu’uniquement pour la navigation des utilisateurs. Par exemple, supposons l’existence d’un dossier de documents classifiés auquel seuls certains employés ont accès et d’un autre dossier auquel tous les employés ont accès. Vous pouvez spécifier différentes autorisations sur les dossiers, puis utiliser l’organisateur de contenu pour que le contenu soit automatiquement déplacé vers le dossier approprié, en fonction des métadonnées. Il est toujours possible d’utiliser à la fois la navigation dans des dossiers et la navigation par métadonnées.

Grâce à la fonctionnalité d’organisateur de contenu, le contenu peut être automatiquement déplacé vers les dossiers en fonction des types de contenu et des métadonnées sans que les utilisateurs aient besoin de choisir l’emplacement du contenu. En outre, l’organisateur de contenu permet de créer automatiquement des dossiers lorsqu’un dossier a atteint une limite d’éléments spécifiée. Vous devez envisager l’échec de l’utilisation de la fonctionnalité Ouvrir avec l’Explorateur (WebDAV) sur les grandes listes si les éléments ne sont pas organisés dans des dossiers dont le nombre d’éléments n’est pas supérieur au seuil d’affichage de liste à la racine d’un dossier donné.

Les affichages basés sur les dossiers et les affichages basés sur les métadonnées offrent des performances très similaires. Du point de vue de la logique et de l’expérience utilisateur, il est sensé d’utiliser des dossiers pour répartir le contenu. La navigation par métadonnées exécute des requêtes récursives de sorte que tous les éléments sont retournés en dehors des dossiers. S’il s’agit de la principale méthode de récupération de contenu, la structure des dossiers peut ne pas revêtir d’importance.

Le graphique suivant indique les résultats d’un test consistant à accéder au même nombre d’éléments au moyen d’affichages de différents types. Tous les affichages ont retourné 1 000 résultats. Ce graphique montre l’évolution des demandes par seconde de chacun de ces affichages à mesure que la taille de la liste augmente. Les résultats montrent qu’au fil de cette augmentation, les performances des affichages de dossier et indexés demeurent relativement stables, bien que les dossiers présentent de meilleures performances à des tailles de liste réduites. Pour la plupart des grandes listes, une combinaison de dossiers et d’affichages indexés étant utilisée, les différences de performances ne doivent pas déterminer s’il faut utiliser des dossiers ou des index pour récupérer des données.

Synthèse des recommandations pour les dossiers

• Planifiez le mode d’organisation des éléments dans les dossiers. Les éléments peuvent être déplacés automatiquement ou manuellement.

• Les fonctionnalités telles que la navigation par métadonnées réduisent la nécessité de limiter la quantité d’éléments dans les dossiers.

• Utilisez la navigation par métadonnées conjointement avec la navigation dans les dossiers. Vous pouvez ainsi recourir aux dossiers pour gérer la stratégie et la rétention, plutôt que de vous en servir seulement pour organiser le contenu en vue d’une récupération de données.

• Lorsque cela procure la meilleure expérience utilisateur, envisagez l’organisation du contenu en dossiers pour faciliter la navigation, même conjointement avec d’autres options de navigation.

• Lorsque vous utilisez l’organisateur de contenu pour déplacer automatiquement les documents dans des dossiers en fonction des métadonnées, envisagez l’activation de l’option permettant de créer des éléments supplémentaires dans les sous-dossiers lorsqu’une limite spécifique est atteinte.

• Si vous envisagez d’utiliser la fonctionnalité Ouvrir avec l’Explorateur (WebDAV), vous devez organiser les éléments dans des dossiers comportant un nombre d’éléments inférieur ou égal au seuil d’affichage de liste à la racine d’un dossier donné.

• Pour récupérer du contenu dans des affichages de liste, vous devez utiliser la navigation par métadonnées et des index si vous ne recourez pas à des dossiers.

Exemple de grande liste collaborative et de dossiers : bibliothèque de spécifications de produit

Dans la bibliothèque de spécifications de produit, les dossiers facilitent la navigation et le placement logique du contenu. Les utilisateurs savent sans difficulté quel dossier ils doivent utiliser pour créer une spécification de produit. Il existe un dossier par type de produit, et chaque type de produit possède un dossier par équipe de produit. Chaque équipe de produit possède un ensemble de documents pour chaque produit qu’elle conçoit, et les documents spécifiques à un produit sont stockés dans l’ensemble de documents. La structure ainsi obtenue se présente comme suit :

• Skis alpins – Type de produit (dossier)

  • Skis de compétition – Équipe de produit (dossier)

    Super-descendeur X – Produit (Ensemble de documents)

Vous pouvez configurer les valeurs par défaut des métadonnées pour chaque dossier, et il est facile pour les utilisateurs de la bibliothèque de rechercher du contenu en utilisant les dossiers.

Exemple d’une archive à grande échelle et de dossiers : Centre d’enregistrements

Le site du centre des enregistrements est utilisé pour le stockage à long terme des éléments qui doivent être conservés à des fins de conformité légale, mais le contenu n’est plus modifié de façon active. Dans ce scénario, les éléments sont automatiquement acheminés vers deux dossiers : restreint et confidentiel. Des autorisations strictes sont définies sur le dossier restreint, auquel un nombre réduit de personnes a accès, et les documents doivent être conservés pendant 10 ans. Le dossier confidentiel est plus accessible que le dossier restreint, et les documents qu’il contient doivent être conservés pendant 7 ans. Cela permet de réduire le nombre d’autorisations uniques et facilite la gestion des autorisations, car les éléments reçoivent leurs autorisations du dossier approprié. Tous les éléments qui parviennent au site du centre des enregistrements sont acheminés vers les dossiers racine, confidentiel ou restreint en fonction des métadonnées.

Index

Il existe une limite non configurable de 20 index pouvant être créés par liste, y compris les index composés et ceux que créent par défaut les fonctionnalités SharePoint Server 2010 pour les colonnes. L’ajout d’index à une liste a un impact minime sur les performances. Toutefois, cela a une incidence sur certaines opérations, telles que l’ajout et la mise à jour. Vous devez éviter d’utiliser plus d’index que nécessaire, car les index inutilisés affectent légèrement les performances et certaines fonctionnalités SharePoint Server 2010 ajoutent des index lorsqu’elles sont activées. Par exemple, SharePoint Server 2010 requiert au moins trois emplacements d’index si vous utilisez les fonctionnalités d’expiration et eDiscovery. Veillez à ce qu’au moins trois emplacements d’index soient disponibles si vous êtes appelé à créer des index.

SharePoint Server 2010 utilise son propre mécanisme d’indexation pour manipuler la structure des tables de sa base de données. Créez des index dans SharePoint Server en modifiant les paramètres de la liste.

Lorsque vous planifiez les index, prenez en considération les points suivants :

• Vous devez recourir à des index pour effectuer des opérations de filtrage sur des listes qui dépassent le seuil d’affichage de liste.

• Planifiez attentivement les index uniques et composés à créer, en raison de la limite de 20 index.

• Réservez des emplacements d’index aux fonctionnalités SharePoint Server 2010 qui peuvent être amenées à créer des colonnes, telles que les fonctionnalités eDiscovery et Stratégie de gestion des informations Rétention.

• Créez des index uniques lorsque vous utilisez un champ unique pour filtrer à l’aide de composants WebPart Requête de contenu, des affichages avec des filtres, et lorsque vous recourez à des filtres et à des hiérarchies de navigation par métadonnées souvent utilisés en guise de filtre unique.

• Créez des index composés pour les requêtes qui filtrent à l’aide de deux colonnes et qui, en règle générale, renvoient un nombre d’éléments supérieur au seuil d’affichage de liste séparément, mais qui sont sélectives ensemble.

• Les index peuvent affecter les performances de certaines opérations, telles que l’ajout d’un document ou la modification de ses propriétés. Par conséquent, ne créez des index que lorsque cela est nécessaire.

Planifier les index avec précaution

Il ne peut exister que 20 index par liste et les colonnes indexées sont très importantes pour une grande liste. Par conséquent, vous devez sélectionner les index uniques et composés avec précaution. Plusieurs fonctionnalités utilisent des index. Par exemple, la fonctionnalité de navigation par métadonnées effectue automatiquement des opérations d’indexation pour les filtres de touche et les hiérarchies de navigation configurés. Vous devez créer des index sur des colonnes qui sont importantes pour le filtrage dans la navigation et l’architecture de l’information.

Index créés automatiquement

Les fonctionnalités SharePoint Server peuvent créer des index qui sont comptabilisés par rapport à la limite d’index de liste. Le tableau suivant répertorie les fonctionnalités SharePoint Server 2010 courantes dans les bibliothèques de documents qui ajoutent des colonnes indexées.

Colonne	Fonctionnalité	Utilisation
État de suspension et d’enregistrement	Gestion des enregistrements sur place ou Blocage et eDiscovery	Cette colonne est ajoutée et indexée lorsque la fonctionnalité de collection de sites Gestion des enregistrements sur place ou la fonctionnalité Blocage et eDiscovery est activée et qu’un élément est déclaré en tant qu’enregistrement ou suspendu dans une liste.
Date d’expiration, Type de contenu	Stratégie de gestion des informations	Ces deux colonnes sont ajoutées et indexées lorsque la rétention est activée pour la stratégie de gestion des informations sur un type de contenu qui est ajouté à la liste ou lorsque la rétention basée sur l’emplacement est activée sur une liste.

Quand créer des index uniques et des index composés

La fonctionnalité de navigation par métadonnées crée automatiquement les index appropriés pour les colonnes de hiérarchie et de filtre de touche sélectionnées dans la page des paramètres de navigation par métadonnées. Des index uniques sont créés pour tous les champs de l’arborescence hiérarchique et pour certains des types de filtre de touche plus sélectif afin que des résultats indexés et des résultats partiels puissent être retournés lorsqu’ils sont utilisés seuls. Des index composés sont créés pour toutes les combinaisons prises en charge de hiérarchies et de filtres de touche pour optimiser la sélectivité lorsqu’à la fois une valeur de filtre d’arborescence et une valeur de filtre de touche sont utilisées.

Dans le cas d’une liste qui comprend de nombreuses colonnes sur lesquelles des opérations de filtrage pourraient être effectuées, vous pouvez être amené à gérer les index manuellement pour éviter d’atteindre la limite d’index. Si vous ne prévoyez pas d’utiliser des combinaisons particulières de hiérarchies de navigation et de filtres de touche, vous pouvez renoncer à créer des index composés afin de diminuer le nombre d’index. Lorsque vous créez ces index, il est important de choisir l’indexation unique sur les colonnes qui sont sélectives et qui peuvent être utilisées seules dans l’affichage de liste, en tant que filtre unique ou que premier filtre appliqué avant qu’un autre ne soit choisi. Les index composés doivent être utilisés lorsque deux filtres seront généralement utilisés ensemble dans la navigation par métadonnées ou dans les requêtes personnalisées et lorsqu’un index n’est pas très sélectif à lui seul. Créez des index pour les colonnes utilisées pour le filtrage avec des affichages de liste, des composants WebPart et autres méthodes d’accès aux données.

Dans certains cas, il peut s’avérer que plusieurs index ne sont pas utiles. Imaginons la situation dans laquelle vous filtrez sur deux colonnes (Division et Type de contenu). Étant donné qu’il s’agit d’une opération AND, seule l’intersection des filtres pour Division et Type de contenu est retournée. Cela signifie que lorsque la requête est exécutée, tous les éléments qui correspondent au filtre Division sont retournés, puis filtrés par type de contenu. Si seuls 10 éléments correspondent dans une division particulière, l’ensemble de données obtenu est suffisamment petit pour qu’un index sur Type de contenu ne présente pas d’intérêt. Si des milliers d’éléments correspondent à la valeur de Division, un index composé doit être utilisé.

Un index composé vous permet de créer un index sur deux colonnes afin de renforcer l’efficacité des requêtes. Les index composés doivent être utilisés lors d’une opération AND sur deux colonnes. La navigation par métadonnées est la seule fonctionnalité SharePoint Server prête à l’emploi qui utilise des index composés. Lorsque la fonctionnalité de navigation par métadonnées est activée, la logique de réexécution et de secours est utilisée même si des contrôles de navigation par métadonnées ne sont pas configurés pour la liste. Les index composés ne sont pas utilisés par les affichages sauf dans le cas d’une requête de navigation par métadonnées.

Impact sur les performances des index

Les index sont nécessaires pour l’exécution de requêtes sur des listes dont le nombre d’éléments est supérieur au seuil d’affichage de liste dans un conteneur donné, et ils peuvent aboutir à une amélioration significative des performances. Bien que les index soient nécessaires pour l’exécution de requêtes efficaces sur les grandes listes et qu’ils puissent améliorer sensiblement les performances des requêtes, ils peuvent affecter les autres opérations, car ils doivent être gérés. Lorsque des éléments sont créés, mis à jour et supprimés, tous les index auxquels ils participent doivent être mis à jour. Des tests effectués avec des opérations de transfert, de mise à jour et de suppression sur une liste qui possède 10 000 éléments montrent qu’entre zéro et 20 index moins de 10 % des éléments sont affectés.

Création d’index

Par défaut, la fonctionnalité de navigation par métadonnées crée automatiquement des index uniques et des index composés. Dans la page des paramètres de navigation par métadonnées, vous pouvez désactiver cette option. La fonctionnalité de navigation par métadonnées crée automatiquement un index unique pour chaque type de colonne pris en charge et des index composés pour chaque combinaison prise en charge de hiérarchies de navigation et de filtres de touche. Des index composés ne sont pas créés automatiquement pour les combinaisons de deux filtres de touche, mais vous pouvez en créer manuellement. La navigation par métadonnées crée automatiquement des index uniques et des index composés pour la plupart des types de colonnes qui prennent en charge les index. Des index uniques ne sont pas automatiquement créés pour les types de filtre de touche qui possèdent relativement peu de valeurs et qui peuvent ne pas être sélectifs à eux seuls. Cela inclut les colonnes Oui/Non, de choix à valeur unique et de type de contenu, mais les index sont pris en charge et peuvent être créés manuellement.

Colonnes prises en charge pour les index uniques

Le tableau suivant fournit des informations sur les index qui sont créés automatiquement par la navigation par métadonnées. Celle-ci crée des index à valeur unique pour toutes les colonnes qui prennent en charge la création d’un index.

Type de colonne	Index créé
Hiérarchies de navigation
Métadonnées gérées à valeur unique	Oui
Métadonnées gérées à valeurs multiples	Non (système indexé en tant que valeur multiple)
ID du type de contenu	Oui
Choix à valeur unique	Oui
Dossier	Non (système indexé par dossier)
Filtres de touche
Métadonnées gérées à valeur unique	Oui
Métadonnées gérées à valeurs multiples	Non (système indexé en tant que valeur multiple)
ID du type de contenu	Non (peut être créé manuellement)
Choix à valeur unique	Non (peut être créé manuellement)
Choix à valeurs multiples	Non (non prise en charge sous forme indexée)
Numérique	Oui
Date	Oui
Oui/Non	Non (peut être créé manuellement)
Monétaire	Oui
Utilisateur (valeur unique)	Oui
Utilisateur (plusieurs valeurs)*	Non (système indexé en tant que valeur multiple)
Toutes les balises	Non (système indexé en tant que valeur multiple, filtre spécial sur toutes les valeurs de métadonnées gérées dans l’élément)

Index composés créés automatiquement

Grâce à la fonctionnalité de navigation par métadonnées, les utilisateurs peuvent sélectionner une hiérarchie de navigation et un filtre de touche ensemble. La fonctionnalité de navigation par métadonnées crée automatiquement des index composés pour toutes les combinaisons prises en charge de hiérarchies de navigation et de filtres de touche. Le tableau suivant indique les combinaisons prises en charge.

Hiérarchies de navigation	Métadonnées gérées à valeur unique	Métadonnées gérées à valeurs multiples	ID du type de contenu	Choix unique	Dossier
Filtres de touche
Métadonnées gérées à valeur unique	Oui	Non	Oui	Non	Non
Métadonnées gérées à valeurs multiples	Non	Non	Non	Non	Non
ID du type de contenu	Oui	Non	Non	Non	Non
Choix à valeur unique	Non	Non	Non	Non	Non
Choix à valeurs multiples	Non	Non	Non	Non	Non
Numérique	Oui	Non	Oui	Non	Non
Date	Oui	Non	Oui	Non	Non
Utilisateur (unique)	Oui	Non	Oui	Non	Non
Toutes les balises	Non	Non	Non	Non	Non
Oui/Non	Oui	Non	Oui	Non	Non
Monétaire	Oui	Non	Oui	Non	Non
Utilisateur (plusieurs valeurs)	Non	Non	Non	Non	Non

Sélectivité des métadonnées

La sélectivité des métadonnées prend de l’importance à mesure que la taille de la liste augmente. Les recommandations suivantes concernent néanmoins toutes les tailles de liste. Toutefois, elles peuvent revêtir moins d’importance pour les listes plus petites.

La sélectivité est la quantité d’éléments à prendre en compte pour qu’une requête retourne des résultats. Il existe deux aspects à cet égard : la sélectivité réelle (nombre total de résultats qui correspondent à la condition de recherche d’une requête) et la sélectivité de limitation (nombre de résultats à prendre en considération après application de conditions aux colonnes indexées). La sélectivité réelle est l’aspect principal du point de vue de l’expérience utilisateur, tandis que la sélectivité de limitation est l’aspect principal du point de vue de l’impact sur l’instance de SQL Server.

Pour utiliser efficacement la navigation par métadonnées et les autres mécanismes de filtrage de liste, il est nécessaire que les métadonnées utilisées pour le filtrage soient sélectives. Par défaut, les affichages de liste comportent 30 éléments afin que les utilisateurs puissent trouver ce qu’ils recherchent en analysant rapidement les résultats. Si les requêtes renvoient plus de 30 résultats, les utilisateurs doivent recourir à la pagination pour rechercher les résultats. Si vous utilisez un composant WebPart Requête de contenu, le nombre de résultats est souvent compris entre 10 et 15. Au-delà, les résultats ne sont pas affichés. Lorsqu’une requête retourne des centaines de résultats, il devient difficile de trouver ce que vous recherchez. La sélectivité est également importante pour empêcher les opérations qui dépassent le seuil d’affichage de liste, ce qui, dans le cas de la navigation par métadonnées, aboutit à une procédure de secours au terme de laquelle tous les résultats ne sont pas retournés.

Organisateur de contenu et équilibrage automatique

L’organisateur de contenu peut être le composant central de l’organisation de contenu dans un référentiel de documents. Les référentiels sont le théâtre d’opérations d’envoi lorsque les utilisateurs y transfèrent un document qui se trouve dans un état final. Voici quelques exemples de scénarios dans lesquels l’organisateur de contenu peut être utilisé :

• acheminement automatique des documents en fonction des métadonnées entre et dans les sites ;

• acheminement des documents et création de dossiers automatiquement, tels que des dossiers basés sur le jour, le mois et l’année ;

• équilibrage automatiquement du nombre d’éléments dans les dossiers.

Accès aux données et récupération de données

La principale finalité de la plupart des grandes listes est le stockage de contenu à des fins de récupération. Il est important de planifier la façon dont les utilisateurs récupéreront du contenu, car cela a l’impact le plus significatif sur les performances d’une grande liste et sur la réussite de l’implémentation des grandes listes. Plusieurs fonctionnalités, notamment la recherche, la navigation par métadonnées, les composants WebPart Requête de contenu et les affichages, peuvent aider les utilisateurs à récupérer du contenu. En outre, les solutions personnalisées, telles que les composants WebPart personnalisés qui interrogent les données, sont couramment utilisées. Planifiez l’organisation du site Web. Vous pouvez utiliser une page d’arrivée centrale, telle que la page d’accueil du site Centre de documents, pour rassembler le contenu et fournir des points d’entrée dans la grande liste. Vous pouvez également utiliser des pages de publication pour créer un site Web où différents sujets sont couverts dans chaque page, au sein desquelles des composants WebPart permettent d’extraire de la grande liste les documents ou éléments associés. Voici une série d’observations sur l’accès aux données et sur la récupération de données :

• Toute combinaison impliquant la recherche, des composants WebPart Requête de contenu, la navigation par métadonnées, des affichages de liste et des composants WebPart personnalisés peut être utilisée.

• Planifiez la façon dont le contenu sera récupéré et les colonnes à utiliser pour les opérations de filtrage et de tri.

• Planifiez le modèle de page de base. Déterminez si la totalité du travail est réalisée dans la bibliothèque de documents ou s’il existe une page d’arrivée ou un modèle à plusieurs pages qui établit un lien avec le contenu associé.

Méthodes d’accès aux données

Il existe trois fonctionnalités SharePoint Server 2010 principales qui permettent d’interroger et de filtrer les données de liste avec une configuration simple : affichage de liste et navigation par métadonnées, composant WebPart Requête de contenu et recherche. Des options supplémentaires qui permettent d’interroger une liste à l’aide d’un code personnalisé ne sont pas décrites dans cet article.

• Les affichages vous permettent de configurer les colonnes qui sont affichées. Il existe diverses méthodes d’affichage pour les données de liste. Les affichages peuvent être configurés pour filtrer et trier les résultats en fonction des colonnes.

  • La navigation par métadonnées est un contrôle de filtrage pour les affichages de liste SharePoint Server 2010. Lorsque la navigation par métadonnées est configurée, vous pouvez sélectionner des hiérarchies de métadonnées et des filtres de touche pour filtrer dynamiquement les résultats qui apparaissent dans un affichage de liste.

• Le composant WebPart Requête de contenu affiche des données de listes SharePoint Server 2010. Des requêtes peuvent être configurées pour retourner des résultats à partir d’une ou de plusieurs listes. Par défaut, le composant WebPart Requête de contenu est mis en cache. Toutefois, il peut ne pas être mis en cache.

• Les zones de recherche ou les composants WebPart de résultats de recherche permettent de retourner des résultats de recherche. Vous pouvez limiter ces résultats à une liste particulière et effectuer une recherche guidée à l’aide des contrôles d’affinement des métadonnées de recherche.

Le tableau suivant recense les méthodes d’interrogation et la façon de les utiliser.

Méthode d’interrogation	Utilisation
Affichage de liste et navigation par métadonnées	Les affichages de liste accèdent toujours à la base de données principale SQL Server, ce qui aboutit aux requêtes ayant le plus fort impact sur les performances et par une augmentation de la charge SQL Server. Utilisez des affichages de liste pour fournir davantage d’options d’interaction avec les documents (archivage, extraction, modification des propriétés) et d’accès aux données en temps réel.
Composant WebPart Requête de contenu	Les composants WebPart Requête de contenu utilisent le fournisseur du plan de site portail pour mettre en cache les requêtes et ils affichent la plus petite quantité de HTML, ce qui aboutit aux temps d’interrogation et d’affichage les plus rapides. Utilisez des composants WebPart Requête de contenu pour la navigation dynamique et pour exécuter plusieurs requêtes sur une même page.
Composant WebPart Requête de contenu non mis en cache	Pour fournir un accès aux données en temps réel, le composant WebPart Requête de contenu peut interroger la base de données directement. Utilisez cette configuration lorsque la requête ne peut pas être mise en cache, lorsque des mises à jour en temps réel sont requises et pour les pages auxquelles le système accède moins d’une fois par heure rendant impossible le remplissage du cache. Le chargement initial d’un composant WebPart Requête de contenu mis en cache entraîne une charge supplémentaire.
Recherche	Utilisez des requêtes de recherche pour déléguer les lectures à une infrastructure de serveur plus facilement adaptable et qui permet d’obtenir des performances de lecture optimisées. Les requêtes de recherche peuvent être configurées pour utiliser des requêtes statiques, ou vous pouvez autoriser les utilisateurs à spécifier des requêtes de recherche.

Composants WebPart Requête de contenu

Le tableau suivant indique les avantages et les inconvénients de l’utilisation de composants WebPart Requête de contenu.

Avantages

Inconvénients

Excellent en tant que composant de navigation, par exemple comme lien vers des documents ou des pages associés. Configuration simple pour afficher différentes colonnes. Plusieurs composants WebPart Requête de contenu peuvent facilement être utilisés sur une même page. Temps d’affichage le plus rapide par rapport à la recherche et aux affichages de liste. Mis en cache par défaut, ce qui réduit la charge SQL Server.

Seul un nombre limité de propriétés peut être affiché. Les liens ne mènent directement qu’à des éléments tels que le document, la page ou l’élément de liste lui-même. Vous ne pouvez pas effectuer d’actions de liste.

Le composant WebPart Requête de contenu permet de récupérer du contenu dans les listes. Il peut être utilisé pour des pages, des documents et des éléments de liste. Par défaut, les composants WebPart Requête de contenu sont mis en cache, ce qui se traduit par de meilleures performances et par un impact moindre dur les ressources SQL Server. La durée de la mise en cache est définie par défaut sur 30 minutes. Par conséquent, les données demeurent relativement actuelles. Toutefois, cela signifie également que le composant WebPart Requête de contenu utilise plus de ressources SQL Server que les requêtes de recherche. Étant donné que les composants WebPart Requête de contenu affichent la plus petite quantité de HTML, ils permettent d’afficher les pages plus rapidement et plusieurs composants WebPart Requête de contenu peuvent être configurés sur une même page. Les composants WebPart Requête de contenu mis en cache fournissent un accès rapide aux données lorsque la taille de la liste augmente. Les composants WebPart Requête de contenu non mis en cache présentent une latence pratiquement identique à celle d’une requête d’affichage de liste similaire.

Les composants WebPart Requête de contenu doivent être utilisés en tant que composant de navigation et pour regrouper du contenu dans les pages. Par exemple, vous pouvez utiliser des pages pour fournir des aperçus d’un contenu qui se trouve dans une bibliothèque de documents, puis utiliser des composants WebPart Requête de contenu pour retourner les pages et les documents associés. À titre d’exemple, citons également les éléments modifiés par l’utilisateur actuel, les éléments les plus récents et les éléments les mieux notés. Le composant WebPart Requête de contenu peut être utilisé dans les scénarios où prédominent les opérations de lecture dans lesquels la plupart des utilisateurs n’ont pas besoin d’effectuer d’actions de liste telles que l’archivage, l’extraction ou la gestion des versions. La figure suivante illustre un composant WebPart Requête de contenu qui affiche les documents les mieux notés.

Le composant WebPart Requête de contenu permet d’accéder à du contenu sans passer par un affichage de liste. Il est possible que les utilisateurs accèdent fréquemment à une petite quantité de contenu ou qu’ils souhaitent suivre certains éléments. Dans le modèle de site Centre de documents, trois composants WebPart Requête de contenu sont utilisés par défaut : le premier retourne les éléments modifiés par l’utilisateur connecté, tandis que les deuxième et troisième indiquent respectivement les documents les mieux notés et les documents les plus récents. Combinés, ces trois composants WebPart Requête de contenu offrent une page d’arrivée qui fournit du contenu auquel un utilisateur peut accéder fréquemment ou qui l’intéresse tout particulièrement. Ce dispositif prend en charge la découverte de nouveau contenu et l’accès rapide aux documents fréquemment utilisés. À titre d’exemple, citons également la création d’une liste de favoris afin que les utilisateurs puissent marquer le contenu à suivre, puis l’utilisation d’un composant WebPart Requête de contenu permettant de retourner la liste des favoris afin que les utilisateurs puissent accéder rapidement au contenu qu’ils utilisent fréquemment sans accéder à la liste elle-même.

Lorsque vous utilisez un composant WebPart Requête de contenu avec une grande liste, vous devez tenir compte de certains points importants afin qu’il retourne des résultats correctement et qu’il ne soit pas bloqué par le seuil d’affichage de liste. Les éléments doivent être filtrés au moyen d’une colonne indexée de sorte que leur nombre soit inférieur au seuil d’affichage de liste. Il est déconseillé d’utiliser des requêtes de liste croisée lorsque l’une des listes est une grande liste. Si le nombre total d’éléments pris en compte dans la requête de liste croisée est supérieur au seuil d’affichage de liste pour les auditeurs et les administrateurs (par défaut 20 000), l’opération est bloquée.

Synthèse des recommandations pour les composants WebPart Requête de contenu

• Utilisez des composants WebPart Requête de contenu pour retourner des éléments auxquels les utilisateurs sont susceptibles d’accéder fréquemment, qui peuvent les intéresser ou qui peuvent les aider à découvrir du contenu.

• Lorsque vous utilisez un composant WebPart Requête de contenu par rapport à une grande liste, vous devez filtrer les éléments afin que la requête ne dépasse pas le seuil d’affichage de liste.

• Vous devez utiliser uniquement des colonnes avec des index pour le filtrage.

• N’utilisez pas le composant WebPart Requête de contenu pour interroger plusieurs listes si le nombre total d’éléments pris en compte est supérieur au seuil d’affichage de liste pour les auditeurs et les administrateurs (par défaut 20 000).

• Utilisez la mise en cache pour réduire les durées de chargement de chargement et la charge SQL Server.

Composants WebPart de recherche

Le tableau suivant indique les avantages et les inconvénients de l’utilisation de composants WebPart de recherche.

Avantages

Inconvénients

Basculez les requêtes depuis les ordinateurs exécutant SQL Server vers des serveurs de recherche plus facilement adaptables. Les serveurs d’index et de requête de recherche sont plus facilement adaptables et offrent des performances meilleures que l’interrogation directe de SQL Server. Les résultats sont basés sur la recherche de texte intégral de documents plutôt que seulement sur les métadonnées. Les résumés de texte fournissent davantage d’informations sur les résultats que les composants WebPart Requête de contenu.

Les résultats sont les moins actuels et sont seulement aussi à jour que l’analyse la plus récente. Les résultats n’affichent pas de valeurs de colonne. Vous ne pouvez pas effectuer d’actions de liste.

Les requêtes de recherche sont plus facilement adaptables que l’accès direct aux ressources SQL Server, car la recherche est optimisée pour les scénarios où prédominent les opérations de lecture et qu’il est plus facile de l’organiser sur plusieurs serveurs de requête et d’index de recherche que d’adapter des instances SQL Server. Vous pouvez utiliser des composants WebPart de recherche préconfigurés et/ou des zones de recherche pour aider les utilisateurs à récupérer du contenu. Les requêtes de recherche offrent une méthode qui permet de déléguer les requêtes aux index de recherche, ce qui se traduit par la réduction de la charge SQL Server. En outre, les requêtes de recherche sont moins affectées par la taille de la liste que les composants WebPart Requête de contenu ou les requêtes d’affichage de liste.

Vous pouvez utiliser la recherche dans n’importe quel scénario pour afficher les résultats issus de requêtes préconfigurées ou spécifiées par l’utilisateur. La recherche offre les meilleures performances à grande échelle. Elle ne doit pas être utilisée si des actions de liste doivent être réalisées sur des éléments ou que des données doivent être affichées en temps réel, car les résultats sont seulement aussi à jour que l’analyse la plus récente. Le tableau suivant indique les trois composants WebPart de recherche utilisables.

Composant WebPart de recherche	Description
Composant WebPart Résultats principaux	Résultats complets avec pagination et composant WebPart le plus complet. Il peut prendre en charge les requêtes système ou spécifiées par l’utilisateur.
Composant WebPart Résultats fédérés	Ensemble réduit de résultats qui possède un lien facultatif permettant d’accéder aux résultats complets.
Composant WebPart de zone de recherche	Composant WebPart permettant de recueillir l’entrée utilisateur pour une requête.

Affichages de liste

Le tableau suivant indique les avantages et les inconvénients de l’utilisation des affichages de liste.

Avantages	Inconvénients
Les actions d’affichage de liste telles que l’archivage, l’extraction et la modification des propriétés permettent d’interagir avec les documents. Il est facile de personnaliser les affichages et d’afficher différentes colonnes. Expérience hautement interactive permettant de filtrer et de trier dynamiquement les résultats en temps réel.	Impact le plus négatif sur les performances en termes de latence et de débit. Plus long temps d’affichage La meilleure expérience utilisateur n’est obtenue qu’avec un seul composant WebPart d’affichage de liste par page.

Les affichages de liste et la navigation par métadonnées peuvent prendre en charge la récupération de contenu dans les bibliothèques de documents volumineuses qui utilisent des dossiers et/ou des index. L’interrogation avec un affichage de liste est réalisée en temps réel et sollicite directement la base de données SQL Server. Ce dispositif fournit les résultats les plus récents. Toutefois, il a le plus fort impact sur les performances. Le débit global diminue et la latence des opérations augmente avec des tailles de liste volumineuses. En outre, les affichages de liste affichent la majeure partie du contenu d’une page à charger. Par conséquent, le temps d’affichage des pages est souvent supérieur avec un affichage de liste.

Vous devez utiliser la navigation par métadonnées et les affichages de liste s’il est indispensable de pouvoir effectuer des actions d’affichage de liste sur les éléments. Les affichages de liste peuvent constituer la principale méthode d’utilisation d’une liste dans les scénarios où les opérations de lecture sont peu nombreuses. Dans les scénarios qui impliquent de nombreuses opérations de lecture, vous pouvez envisager d’autres méthodes d’interrogation comme méthode principale d’accès aux données des listes.

Configuration des affichages

Synthèse des recommandations pour la configuration des affichages

• Sélectionnez attentivement les colonnes utilisées dans les affichages. Plus le nombre de colonnes est élevé, plus la quantité de données à afficher est grande, ce qui entraîne une augmentation de la durée de chargement des pages. Un compromis est nécessaire entre la durée de chargement des pages et une expérience utilisateur optimale.

• Réduisez au minimum la quantité de colonnes de recherche, telles que les métadonnées gérées et les personnes et groupes, dans les affichages, car cela entraîne la création de jointures avec d’autres tables de base de données et accroît la charge de la base de données.

• N’utilisez pas de totaux pour les colonnes.

• Si les affichages ne sont pas filtrés à l’aide de colonnes indexées, choisissez l’option permettant d’afficher les éléments dans des dossiers et veillez à ce que chaque dossier ne possède pas un nombre d’éléments supérieur au seuil d’affichage de liste.

• Les affichages doivent être filtrés sur des colonnes indexées afin que le nombre d’éléments retournés soit réduit à une valeur inférieure au seuil d’affichage de liste (notamment en l’absence de sous-dossiers ou si les dossiers contiennent un nombre d’éléments supérieur au seuil d’affichage de liste).

• Activez la fonctionnalité de navigation par métadonnées pour retourner les résultats les plus récents pour les requêtes qui seraient bloquées par le seuil d’affichage de liste. Par défaut, cette fonctionnalité est activée sur presque tous les sites.

• Si vous utilisez des affichages filtrés conjointement avec la navigation par métadonnées, envisagez d’utiliser des affichages par emplacement pour créer des affichages non filtrés pour les pivots de navigation par métadonnées afin que tous les résultats soient retournés.

Nombre de colonnes et colonnes de recherche

Les affichages constituent la méthode la plus courante pour accéder à des données de liste. Vous devez sélectionner les affichages attentivement afin d’optimiser les modalités de recherche de contenu et d’obtenir les performances requises. Dans le cas d’une grande liste, attachez une attention particulière à la configuration des affichages. Seuls sont recommandés les affichages standard et les affichages personnalisés. Le mode feuille de données, l’affichage de Gantt et l’affichage Calendrier ne sont pas recommandés avec les listes qui dépassent le seuil d’affichage de liste, car ils peuvent être bloqués par le seuil d’affichage de liste. Les affichages doivent posséder le moins de colonnes possible, mais soyez très prudent avec le nombre de colonnes de recherche (métadonnées gérées, personnes et groupes et types de recherche), car les recherches créent des jointures avec les autres tables, ce qui affecte les performances.

Filtrage et totaux de colonnes

Le nouveau seuil d’affichage de liste dans SharePoint Server 2010 apporte une modification majeure à la façon dont les affichages doivent être utilisés avec les grandes listes. Les utilisateurs obtiennent des erreurs si les affichages essaient de retourner un nombre de résultats supérieur au seuil d’affichage de liste. L’utilisation de totaux sur une grande liste sera toujours bloquée par le seuil d’affichage de liste. Par conséquent, n’en utilisez pas. Ce qui importe, c’est le nombre d’éléments à analyser, pas nécessairement le nombre de lignes retournées. Si un affichage possède un filtre où la colonne Couleur a pour valeur « Rouge » et que cette colonne n’est pas indexée, il peut être bloqué. Si la liste contient 10 000 éléments, la requête doit analyser 10 000 éléments, même si seulement 100 éléments correspondent à cette requête. Dans cette situation, les utilisateurs obtiennent des erreurs lorsqu’ils essaient d’accéder à l’affichage. Pour résoudre ce problème, vous pouvez utiliser des dossiers, des filtres, l’indexation et la navigation par métadonnées.

Dossiers

Si une liste est organisée de façon à ce qu’aucun dossier ne contienne un nombre d’éléments supérieur au seuil d’affichage de liste, vous pouvez choisir l’option permettant d’afficher les éléments dans des dossiers. L’affichage de tous les éléments en dehors des dossiers doit être évité sauf si vous disposez de mécanismes permettant de filtrer les résultats de telle sorte que leur nombre soit inférieur au seuil d’affichage de liste.

Indexation

Dans l’exemple précédent, l’exécution d’une requête sur la colonne Couleur échoue, car celle-ci n’est pas indexée. Pour résoudre ce problème, la colonne Couleur pourrait être indexée de manière à ce que les requêtes fonctionnent si les valeurs sont suffisamment distinctes. Si seuls 100 éléments correspondent à « rouge », la requête fonctionne. Toutefois, si le nombre d’éléments correspondants est supérieur au seuil d’affichage de liste, l’opération est bloquée, même avec l’indexation. Par défaut, le champ d’ID, la structure de dossier et les recherches à valeurs multiples sont indexés dans le système. Toutes les colonnes créées et utilisées pour le filtrage doivent posséder des index créés manuellement.

Exemples d’affichage

Éléments récemment modifiés

L’affichage des éléments récemment modifiés permet d’indiquer les éléments les plus récemment modifiés. Il peut être utilisé pour l’affichage par défaut lorsque les utilisateurs accèdent fréquemment au contenu depuis diverses sources qui ont été récemment modifiées. Il est facile de configurer cet affichage, car il utilise des métadonnées système qui sont toujours définies pour chaque élément. Dans le cas d’une grande liste, vous devez définir la limite d’éléments sur une quantité inférieure au seuil d’affichage de liste ou filtrer les résultats de sorte que leur nombre soit inférieur au seuil d’affichage de liste. Pour créer cet affichage, vous devez indexer le champ modifié et effectuer un tri dans l’ordre décroissant. Spécifiez un filtre pour la colonne Date de modification et utilisez la formule, [Aujourd’hui-x], où x est le nombre de jours de données à afficher. Sélectionnez l’option « supérieur ou égal ». La formule, [Aujourd’hui-x], doit renvoyer une quantité d’éléments inférieure au seuil d’affichage de liste.

Mes éléments

L’affichage Mes éléments peut être utilisé dans les référentiels où les utilisateurs accèdent fréquemment à leurs propres documents. Cet affichage est facile à configurer, car il utilise des métadonnées système qui sont toujours définies pour chaque élément. Dans cet affichage, vous filtrez en fonction des colonnes Modifié par et/ou Créé par. Pour créer cet affichage dans les filtres, sélectionnez la colonne Modifié par, définissez la valeur sur [MOI], puis définissez un second filtre avec OR (OU) sur la colonne Créé par, en définissant également la valeur sur [MOI]. La colonne Créé par doit être utilisée en plus de la colonne Modifié par lorsque plusieurs utilisateurs modifient les mêmes documents. La colonne Modifié par n’est pas une colonne multi-utilisateur. Par conséquent, cet affichage ne montre pas nécessairement tous les documents qu’un utilisateur a modifiés. Dans cet exemple, les deux colonnes doivent être indexées, car l’opération est une opération OR.

Conclusion

SharePoint Server 2010 fournit des fonctionnalités nouvelles et perfectionnées qui améliorent l’expérience utilisateur et les performances de l’utilisation des grandes listes. Les limitations et les limites protègent les performances de la batterie de serveurs pour les autres utilisateurs et empêchent les opérations de consommer une quantité disproportionnée de ressources SQL Server. Les améliorations apportées aux métadonnées et la navigation par métadonnées facilitent la récupération des données de liste, et il est possible de configurer les composants WebPart Requête de contenu, la recherche et les affichages de liste pour manipuler les grandes listes. Une planification attentive est néanmoins nécessaire pour que les solutions créées répondent à vos besoins. Toutefois, vous pouvez définir des grandes listes rapidement avec des solutions de configuration prêtes à l’emploi qui ont été conçues pour offrir de bonnes performances.

See Also

Other Resources

Centre de ressources : Gestion de la capacité pour SharePoint Server 2010