Problèmes de performance lors de la synchronisation avec SharePoint Foundation

Dernière modification : jeudi 8 octobre 2009

S’applique à : SharePoint Foundation 2010

Dans cet article
Latence
Débit
Bande passante
Pagination
Filtrage et tri

N'oubliez pas que certains problèmes de performances peuvent se poser lors d'une synchronisation avec un serveur. Parmi les éléments qui affectent les performances, citons la latence, le débit, la bande passante, la pagination, ainsi que le filtrage et le tri pour renvoyer des jeux de données spécifiques.

Latence

La latence, qui est le délai qui s'écoule entre le moment où un utilisateur fait une demande et le moment où le serveur lui renvoie les informations, est très importante pour les utilisateurs. Il existe également souvent des limites sur la durée admise pour le traitement d'une demande sur un serveur de base de données ou un serveur Web frontal, ainsi que des limites sur la taille de la demande elle-même, de sorte que des demandes très longues peuvent se transformer en demandes refusées.

L’utilisation de la propriété rowLimit sur GetListItemChangesSinceToken pour limiter la quantité de données demandées à chaque fois est primordiale pour les raisons évoquées ci-dessus, mais sachez également que cette propriété augmentera la durée totale de la synchronisation.

Débit

Il est bien évident que la réduction du nombre total de cycles requis pour traiter une demande améliore les performances en réduisant la latence. Toutefois, avec plusieurs clients, il est plus important de réduire les effets néfastes qu'un client a sur les autres. La plupart du temps, il est plus facile, plus sûr et plus efficace d'exiger que le serveur effectue une partie du traitement que de mettre en place le même traitement sur plusieurs clients. Toutefois, pour augmenter le débit, il est presque toujours préférable d'effectuer le traitement sur le client. Bien que le serveur ait probablement plus de puissance de traitement, le client aura probablement davantage de temps processeur. Les demandes de données au serveur qu'effectue un client de synchronisation doivent être aussi petites et simples que possible.

Bande passante

Nous privilégions les scénarios à bande passante élevée, malgré tout il est important de tenter de réduire la quantité de données envoyées sur le réseau. Si un client n'a pas besoin de certaines informations, la demande ne doit pas les inclure.

Pagination

Lors d'une synchronisation complète (pas de jeton de modification), le client doit indiquer un nombre maximum d'éléments renvoyés par page à l'aide du paramètre rowLimit. Si le nombre d'éléments de la liste filtrée est supérieur au nombre maximum d'éléments renvoyés par page, le serveur renvoie un attribut ListItemCollectionPositionNext à utiliser pour demander la page suivante.

Seul le jeton de modification actuel de la liste sur la première page est renvoyé, afin que les modifications apportées à la première page ne soient pas perdues. Le client stocke le jeton de modification de la première page pour une prochaine synchronisation incrémentielle.

Utilisation de la limite des lignes

rowLimit est également pris en charge dans une synchronisation incrémentielle (jeton de modification fourni), mais dans ce cas, cet élément limite le traitement du journal interne des modifications. Il existe en outre une limite interne de 100 lignes par page. Bien que le client ait la garantie que le nombre d'éléments renvoyés ne dépassera jamais cette limite, il peut arriver que toutes les modifications ne soient pas synchronisées, même si le nombre d'éléments renvoyés est inférieur à la limite. Cela se produit lorsque vous arrêtez le traitement du journal des modifications dès que vous atteignez un nombre de mises à jour égal à la limite. Lorsque c'est le cas, vous devez renvoyer l'attribut MoreChanges pour indiquer qu'il y a d'autres modifications dans le journal des modifications. Au lieu d'attendre la prochaine mise à jour de synchronisation, le client doit demander plus de modifications immédiatement, à l'aide du jeton de modification renvoyé.

L'élément rowLimit affecte les synchronisations incrémentielles de la manière suivante :

• Il existe une limite interne de 100 lignes par page. Aucun index de temps modifié ne peut être utilisé pour filtrer les éléments renvoyés. De plus, SQL Server impose une limite de 160 sur le nombre de lignes d'une requête et il commence à subir des pertes de performances en approchant ce seuil. La valeur 100 nous laisse une marge de 60 pour le filtre demandé par le client.

• Nous aurions pu créer plusieurs requêtes SQL distinctes, mais cela implique la prise en charge de toutes les opérations de tri et filtrage au niveau intermédiaire.

Pour cette raison, vous devez renvoyer un jeton de modification qui n'est pas actuel, afin que des modifications supplémentaires puissent être traitées dans un appel séparé. Vous pouvez toujours consulter l'intégralité du journal des modifications pour mieux déterminer à quel moment le nombre d'éléments renvoyés est inférieur à la limite, mais cela ne serait pas précis sans filtrage au niveau intermédiaire.

Filtrage et tri

Lorsque vous appliquez le filtrage, vous pouvez renvoyer un ensemble d'éléments spécifique d'une liste, plutôt que l'ensemble de la liste. Les deux scénarios les plus courants dans lesquels le filtrage est utilisé incluent la synchronisation de dossiers, où l'utilisateur récupère uniquement les éléments d'un dossier et pour certains scénarios de forum de groupe où l'utilisateur récupère uniquement les éléments qui le concernent.

Vous pouvez filter à l'aide du paramètre contains ou Requête de service Web. Contains est plus restrictif, puisqu'en réalité il s'agit de la clause Where d'une requête CAML (Collaborative Application Markup Language), tandis que Requête de service Web est la requête complète. Contains est plus sûr, car vous pouvez optimiser certains scénarios.

Le paramètre The Query est plus puissant et flexible que le paramètre contains, mais vous devez comprendre comment il peut affecter les performances. Certaines manières de structurer le paramètre de la requête peuvent affecter les performances, notamment :

• Un client devrait éviter le filtrage à l'aide d'une colonne non indexée. Sinon, l'extraction d'une page requiert une analyse de la liste entière où se trouvent le nombre d'éléments demandés.

• Un client devrait également éviter le tri par une colonne, à moins que cette colonne soit indexée. Sinon, l'extraction d'une page, nécessitera, au minimum, un tri sur tout le jeu de données filtré.

• Si le filtre ne porte pas sur la même colonne indexée que le tri, SQL Server peut toujours analyser l'ensemble de la liste afin d'éviter de trier le jeu de données filtré.

Une synchronisation incrémentielle dispose d'un filtre implicite. Vous pouvez également demander des éléments avec un identificateur spécifique (ID). Dans ce cas, le client doit toujours renvoyer des éléments triés par ID uniquement. Vous pouvez aussi filtrer par d'autres catégories, car le jeu de données est limité à 100 au maximum.

Pour filtrer par dossier, vous pouvez utiliser l'option de requête Folder, mais la liste doit être triée par FileLeafRef. Une requête récursive doit d'abord être triée par FileDirRef aussi.

Il existe également un moyen de filtrer par plusieurs dossiers à l'aide d'un code comme dans l'exemple suivant.

[ajouter un en-tête de code]

"<Or><BeginsWith><FieldRef Name="FileRef"/><Value Type="Note">Shared Documents/folder1/</Value></BeginsWith><BeginsWith><FieldRef Name="FileRef"/><Value Type="Note">Shared Documents/folder2/</Value></BeginsWith></Or>". 

Cette commande synchronisera le contenu complet des dossiers Folder1 et Folder2.

Le client doit utiliser ce code avec le paramètre contains et ajouter l'option de requête suivante.

"<OptimizeFor>FolderUrls</OptimizeFor> "

Cela permet de garantir que la requête au serveur SQL est optimisée convenablement en la triant comme FileDirRef, FileLeafRef et en contraignant les colonnes appropriées.

Voir aussi

Concepts

GetListItemChangesSinceToken et synchronisation des applications