Edgar Maucourant - Expert / Formateur SharePoint

Bonjour à tous,

MAJ du 3 Février 2010 : je reviens sur la conclusion de cet article qui est en partie erronée.

Pour les utilisateurs finaux, il est important de garder dans tous les cas des vues (affichages) dont le nombre total d'éléments (toutes pages confondues) soit inférieur à 2000 éléments (environ ça peut être un peu plus ou un peut moins).

En effet ce que ne montre pas le test ci-dessous c'est que lorsque beaucoup d'utilisateurs exécutent des affichages renvoyant plus de 2000 éléments au total, le serveur pourrait être très rapidement surchargé même si chaque page ne renvoit que 100 éléments. La gestion d'un nombre maximum d'éléments par page (paging) permet de reduire cette surcharge mais ne l'annule pas. Dans les résultats ci-dessous dès que l'on dépasse 500 éléments par page les performances se réduisent essentiellement à cause du temps de transfert des informations du serveur vers le navigateur et du temps nécessaire au navigateur pour interpreter et mettre en page ces informations. Cependant la surchage sur le serveur est importante à partir du moment où l'on dépasse cette fameuse limite des 2000 éléments, essentiellement à cause de contraintes sur les bases de données SQL Server (pour les amateurs de données techniques lire cet article : http://sharepoint.microsoft.com/blogs/GetThePoint/Lists/Posts/Post.aspx?ID=162)

Il existe donc que deux solutions, mettre moins de 2000 éléments par niveau (racine, dossiers, sous-dossiers,...) ou utiliser des vues avec des filtres renvoyant moins de 2000 éléments (moins efficace que la répartition par dossiers mais permet d'améliorer les performances tout de même).

Dans le deuxième cas, il est important de noter que la première colonne utilisée pour le filtre doit être indexée pour améliorer les performances (les indexes sur les autres colonnes ne sont pas pris en compte lors de la requête). Il est important également de noter que si vous utilisez un filtre à plusieurs colonnes, seuls le nombre d'éléments renvoyés par le filtre sur la première colonne est important. Ainsi si je créé un affichage utilisant un filtre du type "Service égale à DRH ET Créé par égale à Jean Dupont" si la colonne Service contient plus de 2000 éléments avec la valeur DRH, le filtre ne sera pas efficace même si le résultat final (les deux filtres associés) renvoit moins de 2000 éléments !

Comme quoi la gestion des performances est un sujet complexe, j'espère que cet éclaircissement vous sera utile lors de la gestion de grandes listes

Pour plus d'infos : http://office.microsoft.com/en-us/sharepointtechnology/HA101736671033.aspx (article en anglais, je n'ai pas trouvé malheureusement d'équivalent en français).

Fin de la MAJ

On entend régulièrement (y compris de ma part) que les listes SharePoint ont une limite de performance aux alentours de 2000 éléments (a visto de naz...), ce qui est vrai, mais depuis quelques temps déjà je me demandais dans quelle mesure cette perte de performance s'appliquait. En effet la plupart des articles que j'ai lu parlent d'une perte de performance à partir de 2000 éléments par conteneur (dossier) ou par vue, mais ce dernier terme n'est pas clair pour moi.

Une vue peut afficher 2000 éléments au total mais répartis par page de 100 éléments (le défaut), dans ce cas est-ce le nombre d'élément par page ou pour la vue globale dont il faut tenir compte ?

De plus à qui s'applique cette consigne ? Aux utilisateurs finaux ? Aux développeurs ? Aux deux ?

Afin d'avoir enfin la réponse à ces questions j'ai testé différents cas et j'ai calculé les temps d'affichage des pages (oui je sais je suis dans ma phase statistiques en ce moment...). Je me suis donc contenté de tester la partie utilisateurs finaux, car des articles pour les développeurs ont déjà été écrit (un lien vers l'un deux est donné en fin d'article).