Surveiller les performances du cache (SharePoint Server 2010)

 

S’applique à : SharePoint Foundation 2010, SharePoint Server 2010

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

Cet article contient des informations sur la surveillance des performances des caches pour la batterie de serveurs Microsoft SharePoint Server 2010. La surveillance des performances des caches vous permet de vous assurer que les paramètres de cache de la batterie de serveurs sont corrects et que les performances de la mise en cache sont optimisées. Cet article fournit des informations sur la mise en cache des objets BLOB (BLOB, Binary Large Object), la mise en cache de la sortie ASP.NET et la mise en cache des objets.

Dans cet article :

  • À propos de la surveillance des caches

  • Surveillance des performances du cache BLOB

  • Surveillance des performances du cache de sortie ASP.NET

  • Surveillance des performances du cache d’objets

À propos de la surveillance des caches

SharePoint Server 2010 fournit trois types de caches qui permettent d’améliorer la vitesse de chargement des pages Web dans le navigateur : le cache BLOB, le cache de sortie ASP.NET et le cache d’objets.

  • Le cache BLOB est un cache disque contenant des fichiers BLOB (Binary Large Object) qui accélèrent le chargement des pages Web dans le navigateur.

  • Le cache de sortie ASP.NET stocke la sortie rendue d’une page. Il stocke également plusieurs versions de la page mise en cache, en fonction des autorisations des utilisateurs qui demandent celle-ci.

  • Le cache d’objets réduit la quantité de trafic entre le serveur Web et la base de données SQL Server en stockant les objets, tels que les listes et les bibliothèques, les paramètres du site et les mises en page, dans la mémoire sur le serveur Web frontal. Par conséquent, les pages qui requièrent ces éléments peuvent être rendues rapidement, ce qui augmente la vitesse à laquelle elles sont fournies au navigateur client.

La surveillance consiste à observer régulièrement des Analyseurs de performances spécifiques et à ajuster les paramètres pour corriger les problèmes de performances éventuels. Les analyseurs mesurent les accès au cache, les échecs d’accès au cache, les compressions du cache et les purges du cache. La liste suivante décrit chacun de ces Analyseurs de performances.

  • Un accès au cache se produit lorsque le cache reçoit une demande pour un objet dont les données sont déjà stockées dans le cache. Un nombre élevé d’accès au cache indique de bonnes performances et une bonne expérience pour l’utilisateur final.

  • Un échec d’accès au cache se produit lorsque le cache reçoit une demande pour un objet dont les données ne sont pas déjà stockées dans le cache. Un nombre élevé d’échecs d’accès au cache indique de mauvaises performances et une expérience plus lente pour l’utilisateur final.

  • La compression du cache (également appelé ajustement), se produit lorsqu’un cache est saturé et que des demandes supplémentaires pour du contenu non mis en cache sont reçues. Pendant la compression, le système identifie dans le cache un sous-ensemble de contenu à supprimer, puis le supprime. En règle générale, ce sous-ensemble de contenu n’est pas très fréquemment demandé.

    La compression peut consommer une partie significative des ressources du serveur. Cela peut affecter les performances du serveur et l’expérience de l’utilisateur final. Par conséquent, la compression doit être évitée. Vous pouvez réduire la fréquence de la compression en augmentant la taille du cache. Normalement, la compression se produit si la taille du cache est diminuée. La compression du cache d’objets ne consomme pas autant de ressources que la compression du cache BLOB.

  • Une purge du cache correspond au vidage complet du cache. Une fois le cache purgé, le rapport accès au cache/échec d’accès au cache est pratiquement égal à zéro. Ensuite, à mesure que les utilisateurs demandent du contenu et que le cache est rempli, ce rapport augmente et finit par atteindre un niveau optimal. Un nombre constamment élevé pour ce compteur peut indiquer un problème lié à la batterie de serveurs, tel que la modification constante des schémas de métadonnées de bibliothèque.

Vous pouvez surveiller l’efficacité des paramètres de cache pour vous assurer que les utilisateurs finaux bénéficient de la meilleure expérience possible. Les performances sont optimales lorsque le rapport accès au cache/échecs d’accès au cache est élevé et que les compressions et les purges ne se produisent que rarement. Si les analyseurs n’indiquent pas ces conditions, vous pouvez améliorer les performances en modifiant les paramètres de cache. Pour plus d’informations sur les paramètres de cache, voir Opérations liées aux paramètres du cache (SharePoint Server 2010) et Configurer les paramètres de cache pour une application Web (SharePoint Server 2010). Pour plus d’informations sur la planification des caches et la stratégie à mettre en œuvre pour ceux-ci, voir Planifier la mise en cache et les performances (SharePoint Server 2010).

Les sections suivantes fournissent des informations spécifiques pour la surveillance de chaque type de cache.

Surveillance des performances du cache BLOB

Vous pouvez surveiller l’efficacité des paramètres de cache en utilisant les Analyseurs de performances répertoriés dans le tableau suivant. Vous pouvez afficher les Analyseurs dans le groupe de compteurs Cache de publication SharePoint.

Nom du compteur Valeur idéale ou schéma Remarques

Nombre total de compressions du cache

0

Si ce nombre est constamment ou fréquemment élevé, la taille du cache est trop petite par rapport à la quantité de données demandée. Pour améliorer les performances, augmentez la taille du cache.

% remplissage du Cache BLOB

Couleur rouge si taux >= 90 %

Couleur jaune si taux >= 80 %

Couleur vert si taux <80 %

Cela peut indiquer que la taille du cache est trop petite. Pour améliorer les performances, augmentez la taille du cache.

Purges du cache de publication/seconde

0

Il est possible que des propriétaires de site soient en train d’effectuer sur les sites des actions qui entraînent la purge du cache. Pour améliorer les performances pendant les heures d’utilisation maximale, assurez-vous que les propriétaires de site n’effectuent ces actions que pendant les heures creuses.

Taux d’accès au cache de publication

Dépend du schéma d’utilisation. Pour les sites en lecture seule, le taux doit être 1. Pour les sites en lecture/écriture, le taux peut être inférieur.

Un rapport faible peut indiquer que des éléments non publiés font l’objet d’une demande et qu’ils ne peuvent pas être mis en cache. S’il s’agit d’un site portail, il est possible que le site soit configuré de manière à exiger l’extraction ou que de nombreux utilisateurs aient extrait des éléments.

Notes

Dans le cas du cache BLOB, une demande n’est comptabilisée en tant qu’échec d’accès au cache que si l’utilisateur demande un fichier dont l’extension est configurée pour être mise en cache. Par exemple, si le cache est activé pour ne mettre en cache que les fichiers .jpg et que le cache reçoit une demande pour un fichier .gif, cette demande n’est pas comptabilisée en tant qu’échec d’accès au cache.

Surveillance des performances du cache de sortie ASP.NET

Vous pouvez surveiller l’efficacité des paramètres de cache en utilisant les Analyseurs de performances répertoriés dans le tableau suivant. Vous pouvez afficher les Analyseurs dans le groupe de compteurs Applications ASP.NET.

Nom du compteur Valeur idéale ou schéma Remarques

Suppressions d’API du cache

0

Augmentez la quantité de mémoire allouée au cache de sortie ASP.NET.

Taux d’accès API au cache

Dépend du schéma d’utilisation. Pour les sites en lecture seule, le taux doit être 1. Pour les sites en lecture/écriture, le taux peut être inférieur.

Les causes potentielles d’un faible taux d’accès sont les suivantes :

  • Si vous utilisez la mise en cache pour utilisateur anonyme (par exemple, pour un site destiné à Internet), les utilisateurs demandent régulièrement du contenu qui n’a pas encore été mis en cache.

  • Si vous utilisez la mise en cache de la sortie ASP.NET pour les utilisateurs authentifiés, de nombreux utilisateurs ont peut-être des autorisations de modification sur les pages qu’ils affichent.

  • Si vous avez personnalisé des paramètres VaryBy* sur une page (ou sur une page maître ou une mise en page) ou personnalisé un profil de cache, vous avez peut-être configuré un paramètre qui empêche les pages du site d’être mises en cache efficacement (par exemple, vous appliquez peut-être une variation par utilisateur pour un site qui compte de nombreux utilisateurs).

Notes

Dans le cas du cache de sortie ASP.NET, toutes les pages sont mises en cache pour une durée fixe indépendante des actions utilisateur. Par conséquent, il existe des événements de surveillance liés aux purges.

Pour plus d’informations sur le cache de sortie ASP.NET, voir Mise en cache de la sortie et profils de cache (https://go.microsoft.com/fwlink/?linkid=121543&clcid=0x40C) ou cache, élément de caching (Schéma des paramètres ASP.NET) (https://go.microsoft.com/fwlink/?linkid=195986&clcid=0x40C).

Surveillance des performances du cache d’objets

Le cache d’objets permet de stocker des métadonnées sur les sites, les bibliothèques, les listes, les éléments de liste et les documents qui sont utilisés par des fonctionnalités telles que la navigation dans les sites et le composant WebPart Requête de contenu. Ce cache aide les utilisateurs lorsqu’ils accèdent à des pages qui utilisent ces fonctionnalités, car les données dont ils ont besoin sont stockées ou récupérées directement dans le cache d’objets et non dans la base de données de contenu.

Le cache d’objets est stocké dans la mémoire RAM de chaque serveur Web de la batterie de serveurs. Chaque serveur Web gère son propre cache d’objets.

Vous pouvez surveiller l’efficacité des paramètres de cache en utilisant les Analyseurs de performances répertoriés dans le tableau suivant. Vous pouvez afficher les Analyseurs dans le groupe de compteurs Cache de publication SharePoint.

Nom du compteur Valeur idéale ou schéma Remarques

Nombre total de compressions du cache

0

Si ce nombre est élevé, la taille du cache est trop petite par rapport à la quantité de données demandée. Pour améliorer les performances, augmentez la taille du cache.

Purges du cache de publication/seconde

0

Il est possible que des propriétaires de site soient en train d’effectuer sur les sites des actions qui entraînent la purge du cache. Pour améliorer les performances pendant les heures d’utilisation maximale, assurez-vous que les propriétaires de site n’effectuent ces actions que pendant les heures creuses.

Taux d’accès au cache de publication

Dépend du schéma d’utilisation. Pour les sites en lecture seule, le taux doit être 1. Pour les sites en lecture/écriture, le taux peut être inférieur.

Si le taux commence à diminuer, cela peut être dû à une ou plusieurs des causes suivantes :

  • Le cache a été récemment purgé ou compressé.

  • Les utilisateurs accèdent à du contenu qui a été récemment ajouté au site. Cela peut se produire après qu’une grande quantité de nouveau contenu a été ajoutée au site.

See Also

Concepts

Planifier la mise en cache et les performances (SharePoint Server 2010)
Opérations liées aux paramètres du cache (SharePoint Server 2010)
Configurer les paramètres de cache pour une application Web (SharePoint Server 2010)