Surveiller les performances du cache dans SharePoint Server 2016
S’APPLIQUE À :2013 2016 2019 Édition d’abonnement SharePoint dans Microsoft 365
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.
À propos de la surveillance des caches
SharePoint Server 2016 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 le trafic entre le serveur web et la base de données SQL 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 analyses des performances spécifiques et à ajuster les paramètres pour corriger les problèmes de performances éventuels. Les analyses 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 chacune de ces analyses des 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 de 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. Habituellement, 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 invariablement é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 analyses n'indiquent pas ces conditions, vous pouvez améliorer les performances en modifiant les paramètres de cache.
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 analyses des performances répertoriées dans le tableau suivant.
Groupe de compteurs sharePoint Disk-Based Cache
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 pour les données demandées. Pour améliorer les performances, augmentez la taille du cache. |
Taux de 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. |
Groupe de compteurs Cache de publication SharePoint
Nom du compteur | Valeur idéale ou schéma | Remarques |
---|---|---|
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
[!REMARQUE] 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 analyses des performances répertoriées dans le tableau suivant.
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é l’un des paramètres VaryBy* sur n’importe quelle page (ou page maître ou 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 pouvez varier par utilisateur pour un site qui a de nombreux utilisateurs). |
Notes
[!REMARQUE] 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, consultez Profils de cache et de cache de sortie ou Élément de cache pour la mise en cache (schéma paramètres ASP.NET).
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 comme 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 vive (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 analyses des performances répertoriées dans le tableau suivant.
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 pour les données demandées. 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. |