Mise en cache de Windows Server AppFabric Guide de planification la capacité

Jason Roth, Rama Ramani, Jaime Alva Bravo

Mars 2011

Ce livre blanc fournit des recommandations relatives à la planification de la capacité de Mise en cache de Windows Server AppFabric.

1. Introduction

2. Évaluation des performances de mise en cache d'AppFabric

3. Méthodologie de planification de la capacité

   1. Étape un : comprendre les goulots d'étranglement et identifier les candidats à la mise en cache

   2. Étape deux : évaluer les schémas actuels de charge de travail

   3. Étape trois : comprendre l'infrastructure physique et les ressources matérielles

   4. Étape quatre : finaliser le contrat de niveau de service (SLA) en matière de performances pour toutes les applications

   5. Étape cinq : identifier les fonctionnalités et les paramètres de configuration appropriés d'AppFabric

4. Outil de planification de la capacité

5. Étapes suivantes de la planification de la capacité

6. Surveillance des exigences continues de capacité de mise en cache

Introduction

La mise en cache de Windows Server AppFabric offre un cluster de cache en mémoire distribué. Ce document fournit des recommandations de planification de la capacité pour un déploiement local de la mise en cache de Windows Server AppFabric.

L'architecture de la mise en cache de Windows Server AppFabric est décrite en détail dans la documentation. Pour plus d'informations, consultez la rubrique Fonctionnalités de mise en cache de Windows Server AppFabric. En résumé, un cluster de cache AppFabric est constitué d'un ou plusieurs serveurs de cache (également appelés hôtes de cache). Les caches sont distribués entre les hôtes de cache et stockés en mémoire.

Notes

Notez qu'il existe également une mise en cache de Windows Azure AppFabric afin de permettre l'utilisation de la mise en cache dans le cloud. Certaines étapes de ce document concernant l'estimation des besoins en mémoire s'appliqueront à une solution cloud, mais ce livre blanc se concentre spécifiquement sur le scénario du cluster de cache local. Pour plus d'informations sur l'utilisation de la fonctionnalité de mise en cache d'Azure AppFabric, consultez la page Windows Azure AppFabric Caching..

Les informations de ce document sont fondées sur le travail de planification que Microsoft a mené avec des clients. Tous les clients qui utilisent la mise en cache d'AppFabric posent une question commune : « Combien de serveurs sont nécessaires pour mon scénario » ? Dans bon nombre de ces discussions, nous commençons par la réponse classique : « Ça dépend ». Nous analysons ensuite rapidement les divers détails pour parvenir à un bon point de départ. Au cours de ce processus, d'autres questions plus spécifiques émergent :

• Quelle quantité de mémoire de mise en cache exigent mes applications ?

• Combien d'ordinateurs dois-je utiliser dans un cluster de cache ?

• De combien de mémoire doit être doté chacun des ordinateurs et comment doivent-ils être configurés ?

• Dans quelle mesure la bande passante réseau affecte-t-elle les performances du cluster de cache ?

Ce livre blanc vise à tirer avantage des leçons apprises au cours de ces discussions avec les clients afin de proposer une méthodologie utilisable pour votre planification de capacité.

Si vous lisez ce document, vous êtes susceptible de vous trouver dans l'une des phases de développement suivantes :

1. Vous entamez à peine l'étude de la mise en cache distribuée et ne disposez pas de données à analyser sur les charges de travail, les exigences en termes de performances ou la topologie de déploiement de serveur. À ce stade, vous souhaiterez peut-être commencer par consulter quelques données de performances de la mise en cache d'AppFabric.

2. Vous avez peut-être déjà analysé les fonctionnalités et performances de la mise en cache d'AppFabric. Vous recherchez maintenant une aide pour étudier attentivement votre scénario spécifique et vos exigences de haut niveau. C'est là que vous plongez dans les détails de la planification de la capacité.

3. Enfin, il est également possible que vous soyez déjà en production. À ce stade, vous souhaitez comprendre comment analyser les données de performances afin de vous assurer que vous disposez d'une capacité suffisante. En outre, vous voulez également planifier les augmentations futures de la charge de travail, et ce en connaissant les indicateurs clés et les meilleures pratiques sur la base du comportement à l'exécution du cache d'AppFabric.

Ce livre blanc est structuré de manière à aborder ces différentes phases de manière séquentielle. Si vous ne faites qu'évaluer les performances d'AppFabric, nous vous recommandons un livre blanc complet rédigé par notre partenaire Grid Dynamics. Ici, nous allons grouper les données de ce livre blanc d'une manière aisée afin de faciliter votre évaluation et de fournir des informations pour le processus de planification de la capacité.

Si vous êtes prêt à passer au processus de planification de la capacité, nous présentons un ensemble d'étapes afin de formaliser une méthodologie applicable à votre scénario.

Si vous utilisez ou testez un cluster de cache, vous pouvez valider le processus de planification de la capacité en consultant l'ensemble clé d'indicateurs de performances afin de vous assurer que vous disposez de la capacité correcte. Par ailleurs, nous étudierons quelques bonnes pratiques.

Évaluation des performances de mise en cache d'AppFabric

Notre partenaire, Grid Dynamics, a récemment terminé une série de tests sur les performances de la mise en cache d'AppFabric. Les résultats ont été publiés dans le livre blanc suivant : Windows Server AppFabric Cache: A detailed performance & scalability datasheet.

Chaque test se concentre sur une variable spécifique, comme la taille du cache ou le nombre de serveurs du cluster de cache. Il est possible d'utiliser l'étude de Grid Dynamics pour évaluer les performances et l'évolutivité de la mise en cache d'AppFabric. Vous pouvez comparer les chiffres de débit et de latence d'un large éventail de scénarios et de topologies de test avec les exigences de votre application. En règle générale, dans chaque test, seulement un ou deux paramètres ont été modifiés afin de se concentrer sur leur impact sur les performances. L'ensemble complet de paramètres comprend :

Schéma de charge	Schéma d'utilisation du cache, c.-à-d, pourcentage d'opérations « Get », « Put », « BulkGet », « GetAndLock », « PutAndUnlock »
Taille des données mises en cache	Quantité de données stockées en cache pendant le test
Taille de cluster	Nombre de serveurs dans le cluster de cache
Taille des objets	Taille des objets après sérialisation stockés dans le cache
Complexité des types	Les différents types d'objets .NET, tels que byte, string[], etc., qui sont stockés dans le cache
Sécurité	Paramètres de sécurité du cluster de cache

En plus de vérifier les performances et l'évolutivité de la mise en cache d'AppFabric, Grid Dynamics fournit l'atelier de test afin de vous permettre de répéter les tests avec vos propres données et charges de travail. Il s'agit là d'une autre possibilité d'évaluer les performances de la mise en cache pour votre scénario spécifique.

Bien que nous recommandions vivement la lecture de l'ensemble de l'étude et de ses conclusions, voici un résumé de quelques-unes des découvertes de l'étude qui alimenteront les meilleures pratiques présentées dans la suite de ce document :

• La mise en cache d'AppFabric évolue de manière linéaire à mesure que des ordinateurs sont ajoutés à un cluster de cache.

• La taille du cache a peu d'impact, excepté pour les caches volumineux avec un pourcentage élevé d'écritures. Entre autres facteurs, les charges d'écritures élevées mettent plus de pression sur le nettoyage de la mémoire .NET lorsque la taille de la pile gérée est importante.

• La complexité élevée des types n'affecte que les performances du côté client en raison de la sérialisation.

• Les appels Bulk Get entraînent une meilleure utilisation du réseau. L'accès direct au cache est beaucoup plus rapide que les serveurs proxy (ASP.NET, WCF), et cela est dû aux performances de la couche intermédiaire plutôt qu'à celles de la mise en cache.

• Les performances des verrouillages pessimiste et optimiste étant similaires, il convient d'utiliser la technique la mieux appropriée à la conception de votre application. Tant la latence que le débit s'améliorent lorsque le ratio de conflits diminue.

• La sécurité du cluster de cache ne réduit pas les performances et est activée par défaut. Le débit le plus élevé et la latence la plus faible s'obtiennent lorsque la sécurité est désactivée, mais cela peut s'avérer inacceptable en raison de la sensibilité des données et des besoins métier.

• L'utilisation d'un réseau dédié entre les serveurs d'applications et les serveurs de cache réduit les goulots d'étranglement réseau.

Notez que le livre blanc de Grid Dynamics est un bon point de départ pour une évaluation de la mise en cache d'AppFabric et qu'il contient par ailleurs également des données brutes et des schémas observés qui peuvent être exploités pour alimenter le processus de planification de la capacité.

Méthodologie de planification de la capacité

Dès que vous avez décidé que votre application pourrait tirer avantage d'un cache en mémoire distribué, comme la mise en cache d'AppFabric, vous entrez dans la phase de planification de la capacité. Bien qu'il soit possible d'effectuer certaines étapes de planification de la capacité par le biais de tests directs sur un cluster de cache AppFabric, vous pourriez être amené à créer une estimation sans ce type de tests. C'est l'objet de cette section. Les étapes qui suivent offrent un moyen systématique d'envisager vos besoins de mise en cache d'AppFabric :

1. Comprendre les goulots d'étranglement et identifier les candidats à la mise en cache

2. Évaluer les schémas actuels de charge de travail

3. Comprendre l'infrastructure physique et les ressources matérielles

4. Finaliser le contrat de niveau de service (SLA) en matière de performances pour toutes les applications

5. Identifier les fonctionnalités et les paramètres de configuration appropriés d'AppFabric

Ce document fournit des exemples pour ces étapes en examinant les besoins d'un exemple d'application de magasin en ligne. La mise en cache peut toutefois être utilisée par tout type d'application .NET, de même qu'il est possible que plusieurs applications accèdent au même cluster de cache. Dans ce scénario, vous devez exécuter les étapes suivantes pour chaque application et consolider les résultats pour avoir une estimation précise de la capacité.

Étape un : comprendre les goulots d'étranglement et identifier les candidats à la mise en cache

Commencez par identifier les données que vous souhaitez mettre en cache. Cette opération s'effectue à l'aide d'outils d'analyse des performances, comme SQL Server Profiler, l'analyseur de performances, les tests Visual Studio, etc. Ces outils peuvent identifier les objets de bases de données à accès fréquents ou des appels lents de services Web. La mise en cache des jeux de données renvoyés depuis ces emplacements principaux est susceptible de s'avérer utile. Le stockage temporaire de ces données dans le cache peut améliorer les performances et relâcher la pression sur les magasins de données principaux.

Dès que vous avez identifié les candidats possibles à la mise en cache, il est intéressant de les classer en trois grandes catégories : données d'activité, données de référence et données de ressource. Il est préférable d'expliquer ces différentes catégories par le biais d'exemples.

• Les données d'activité contiennent des données en lecture/écriture liées à un utilisateur particulier. Par exemple, dans un magasin en ligne, le panier d'un utilisateur constitue des données d'activité. Elles s'appliquent à la session en cours de l'utilisateur et peuvent changer fréquemment. Bien qu'il soit important de préserver une disponibilité élevée du panier, il s'agit de données qui ne nécessitent pas nécessairement un stockage permanent dans une base de données principale. En raison de leur nature temporaire, les données d'activité sont un candidat logique pour la mise en cache.

• Les données de référence sont des données en lecture seule qui sont partagées par plusieurs utilisateurs ou par plusieurs instances d'application. L'accès à ces données est fréquent ; en revanche, elles changent peu souvent. Ainsi, toujours dans l'exemple du magasin en ligne, le catalogue des produits constitue des données de référence. Le catalogue sera valable un ou plusieurs jours et des utilisateurs différents y accèderont des milliers de fois. Les données de ce type sont également bien adaptées à la mise en cache. Sans mise en cache d'aucune sorte, chaque utilisateur qui consulte le catalogue de produits doit accéder aux données directement à partir de la base de données. L'utilisation de la mise en cache peut relâcher la pression sur la base de données principale en cas de requêtes répétées sur des données semi-statiques. En raison de leur caractère permanent, ce sont également un candidat logique pour la mise en cache.

• Les données de ressource sont des données en lecture/écriture partagées entre plusieurs utilisateurs. Un forum d'assistance contient, par exemple, ce type de données. Tous les utilisateurs peuvent lire une réponse aux publications d'un forum.

Dans la mesure où les différents types de données mises en cache présenteront des schémas d'utilisation différents, la classification des données dans ces catégories peut s'avérer utile. Par exemple, l'identification d'un objet comme données de référence suggère instantanément qu'il induit plus une charge de lecture seule. Cette classification peut également aider à déterminer des stratégies d'expiration, qui seront plus courtes pour les données qui changent plus fréquemment. Dans le cadre d'un développement, ces répartitions logiques peuvent suggérer des sections encapsulables dans le code.

Il est recommandé de produire des estimations pour les différents objets, puis de consolider les données. Le tableau suivant illustre un exemple d'informations collectées à ce stade :

Objet à mettre en cache	Classification de mise en cache	Emplacement de stockage permanent
Objet Panier	Données d'activité	Aucun
Objet Préférences utilisateur	Données d'activité	Base de données principale
Catalogue de produits	Données de référence	Base de données principale
Fil de discussion d'un forum d'utilisateurs	Données de ressource	Base de données principale

Lors de l'identification de données candidates à la mise en cache, il n'est pas indispensable de trouver des données pour chaque catégorie. Il peut s'avérer que la seule mise en cache du panier de votre application suffise à améliorer les performances et l'évolutivité. L'important à ce stade consiste à utiliser les informations disponibles pour identifier les meilleurs éléments à mettre en cache.

Étape deux : évaluer les schémas actuels de charge de travail

Dès que vous avez déterminé les données appropriées à mettre en cache, vous devez comprendre comment l'application accède à ces données et les schémas de charge de travail associés. Au terme de cette étape, vous devriez pouvoir parvenir à une estimation brute de vos besoins en mémoire de mise en cache. Vous devriez également avoir une meilleure compréhension de la façon dont les utilisateurs accèdent aux données et les utilisent, ce qui s'avèrera important dans des étapes ultérieures.

Par exemple, si vous envisagez de mettre en cache un catalogue de produits, vous devez analyser quand l'application récupère les données du catalogue et à quelle fréquence ont lieu ces requêtes. Sur la base de l'étape précédente, vous savez qu'il s'agit de données de référence, et par conséquent, que la charge de travail est essentiellement en lecture seule. Une parfaite compréhension des schémas de charge de travail pour les différents objets guidera vos décisions futures en matière de capacité. Voyons d'un peu plus près ce qu'implique cette étape.

Il existe plusieurs façons de mieux comprendre vos schémas actuels d'accès aux données :

1. Étudiez attentivement le code pour déterminer où les données se trouvent et leur fréquence d'accès.

2. Utilisez un profileur de code qui peut fournir la fréquence d'appel de la méthode et les données de performances associées.

3. Créez une instrumentation dans le code autour de sections spécifiques d'accès aux données. Journalisez la tentative d'accès aux données et les performances associées de l'opération de données.

4. Utilisez un profileur de bases de données, comme SQL Server Profiler, pour observer le nombre et la durée des opérations de base de données.

Il convient de noter que bon nombre de ces techniques auraient pu être utilisées à l'étape précédente pour déterminer quelles données cibler pour la mise en cache. Toutefois, à ce stade, nous sommes essentiellement intéressés par des chiffres plus détaillés utilisables dans les futurs calculs de planification de la capacité.

Une partie de cette évaluation implique la compréhension du ratio de lectures par rapport aux écritures. La charge de travail de lecture/écriture peut influencer les décisions ultérieures relatives à la capacité. Par exemple, une charge de travail avec un pourcentage élevé d'écritures engendrera un nettoyage plus important de la mémoire .NET. Cette question est abordée dans une étape ultérieure.

Un autre facteur est la fréquence de lectures et d'écritures pendant une charge de pointe. Le tableau suivant présente un exemple de données collectées à ce stade pour l'objet Panier de notre exemple.

Objet à analyser	Panier
% de lectures	50%
% d'écritures	50%
Opérations de lecture par seconde (max.)	250
Opérations d'écriture par seconde (max.)	250

Une fois encore, cette même analyse doit être effectuée pour chaque type d'objet. Les différents types d'objets présenteront des schémas d'accès différents et des valeurs maximales différentes de lectures et d'écritures par seconde en charge.

Pour comprendre les besoins de mise en cache, il est nécessaire de disposer d'une estimation dunombre maximal d'objets actifs de chaque type dans le cache à tout moment. Cette estimation implique un équilibre entre la fréquence d'insertion d'objets et l'espérance de vie de ces objets. L'utilisation d'un exemple permet une meilleure compréhension.

Dans l'exemple d'application Web ASP.NET, les données opérationnelles peuvent révéler des pointes de 25 000 utilisateurs simultanés. Chaque utilisateur nécessite des informations d'état de session, soit 25 000 objets mis en cache. Cependant, l'expiration de ces objets pourrait être fixée à 30 minutes. Pendant les périodes de pointe, les données opérationnelles pourraient indiquer qu'il y a 5 000 nouveaux utilisateurs par heure, ce qui implique que 2 500 nouveaux utilisateurs pourraient arriver pendant la période d'expiration de 30 minutes. En outre, certains utilisateurs sont susceptibles de fermer leur navigateur et de lancer une nouvelle session. Dans ce cas, bien qu'il s'agisse des mêmes utilisateurs, ils utilisent alors une session différente. Une marge supplémentaire est donc nécessaire pour en tenir compte. Enfin, toute croissance prévue au cours des 6-12 mois doit être planifiée. Ainsi, le calcul final du nombre maximal d'objets actifs dans le cache pourrait se présenter comme suit :

Objet à analyser :	Panier
Nombre maximal d'utilisateurs simultanés	25000
Nouveaux utilisateurs pendant la période d'expiration (30 minutes)	2500
Utilisateurs existants démarrant de nouvelles sessions de navigation	250
Estimation de la croissance future (25 %)	6940
Total d'objets actifs (max.) :	~35 000 objets actifs au maximum

Les modifications des valeurs en entrée, comme la période d'expiration, changeront le nombre d'objets non expirés résidant dans le cache pendant les charges de pointe. Il ne s'agit ici que d'un exemple du processus de réflexion. Avec d'autres types d'objets, le calcul peut intégrer d'autres schémas et d'autres variables. Par exemple, si un catalogue de produits partagé est valable pour une journée entière, le nombre maximal d'objets Catalogue de produits dans le cache au cours de la journée serait un.

Toutefois, connaître le nombre maximal d'objets dans le cache ne s'avère utile que si vous connaissez également la taille moyenne des objets. En soi, ce problème est complexe. Dans l'exemple du panier, un utilisateur est susceptible de ne placer qu'un seul article dans son panier alors qu'un autre pourrait avoir 10 ou 20 articles. L'objectif est d'appréhender la moyenne. Comme la plupart des valeurs de ce processus, cette moyenne ne sera pas parfaite, mais le résultat final constituera un point de départ bien réfléchi pour votre cluster de cache plutôt qu'une simple approximation.

Les objets sont stockés dans le cache sous forme sérialisée. Dès lors, pour comprendre la taille moyenne des objets, il est nécessaire de calculer la taille moyenne des objets sérialisés. AppFabric utilise la classe NetDataContractSerializer pour la sérialisation avant de stocker les éléments dans le cache. Pour déterminer la taille moyenne des objets, ajoutez à votre application du code d'instrumentation qui sérialise vos objets et enregistre leur taille sérialisée.

L'exemple de code suivant tente d'estimer la taille moyenne d'un seul objet. L'objet sérialisé se nomme obj. La variable length est utilisée pour enregistrer la longueur. En cas de problèmes d'obtention de la taille avec la classe NetDataContractSerializer, la classe BinaryFormatter est utilisée. Vous pouvez l'inclure dans une méthode pour une utilisation plus aisée. Dans ce cas, obj serait transmis comme paramètre et length renvoyé par la méthode.

// requires following assembly references:
//
//using System.Xml;
//using System.IO;
//using System.Runtime.Serialization;
//using System.Runtime.Serialization.Formatters.Binary;
//
// Target object “obj”
//
long length = 0;

MemoryStream stream1 = new MemoryStream();
using (XmlDictionaryWriter writer = 
    XmlDictionaryWriter.CreateBinaryWriter(stream1))
{
    NetDataContractSerializer serializer = new NetDataContractSerializer();
    serializer.WriteObject(writer, obj);
    length = stream1.Length; 
}

if (length == 0)
{
    MemoryStream stream2 = new MemoryStream();
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(stream2, obj);
    length = stream2.Length;
}

Notes

Notez que si vous disposez d'une configuration de cluster de cache de test, vous pouvez ajouter des éléments au cache et utiliser la commande de Windows PowerShell, Get-CacheStatistics, pour déterminer la taille d'un ou plusieurs objets ajoutés au cache. Vous pouvez également diviser la taille de plusieurs objets présents dans le cache par le nombre d'objets du cache. Vous pouvez produire des estimations à l'aide de code ou de tests.

Si vous comptez utiliser la mise en cache d'AppFabric pour l'état de session, il est important de comprendre que le fournisseur SQL Server pour l'état de session ASP.NET utilise toujours BinaryFormatter plutôt que NetDataContractSerializer. Il arrive que des objets sérialisés par la classe NetDataContractSerializer présentent une taille plusieurs fois supérieure à celle d'objets qui utilisent la classe BinaryFormatter. C'est important si vous analysez la taille d'objets d'état de session dans SQL Server, puisque vous ne pouvez pas utiliser cette taille et supposer qu'elle sera la même dans le cache. Vous pourriez multiplier cette taille par 6 pour obtenir une estimation grossière. Pour avoir une meilleure estimation, utilisez le code ci-dessus sur les objets stockés dans l'état de session. Avec les données collectées à ce stade, vous pouvez commencer à formuler vos besoins totaux en mémoire. Cette étape implique les sous-tâches suivantes :

1. Concentrez-vous sur un type d'objet (par exemple, l'objet Panier).

2. Pour cet objet, commencez par prendre la taille moyenne de l'objet sérialisé.

3. Ensuite, ajoutez 500 octets à la taille moyenne pour tenir compte des informations nécessaires pour la mise en cache.

4. Multipliez cette taille par le nombre maximal d'objectifs actifs. Vous obtenez ainsi les besoins en mémoire totaux pour la mise en cache de ce type d'objet.

5. Ajoutez un supplément estimé pour les structures de mise en cache internes (5 %).

6. Répétez ces étapes pour chacun des types d'objets identifiés.

7. Consolidez les résultats pour obtenir les besoins en mémoire totaux pour la mise en cache.

Dans ce processus, notez que vous devez ajouter environ 0,5 Ko par objet aux estimations de taille. Par ailleurs, d'autres structures de données internes ont besoin de mémoire dans le cache. Ainsi, les régions, balises et notifications nécessitent toutes de la mémoire supplémentaire. Dans nos exemples de calcul, nous ajoutons 5 % du total pour tenir compte de ces structures internes, mais ce pourcentage est susceptible d'être plus ou moins élevé selon l'utilisation que vous faites de ces fonctionnalités de mise en cache.

Arrivé à ce point, il convient d'envisager l'impact d'une fonctionnalité de mise en cache spécifique d'AppFabric, la haute disponibilité. Cette fonctionnalité crée des copies des éléments mis en cache sur des serveurs secondaires. Cela signifie qu'en cas d'arrêt d'un des serveurs de cache, le serveur de cache secondaire prend le relais, évitant ainsi la perte de données. Si vous décidez d'utiliser la haute disponibilité, vous devez doubler vos estimations en termes de mémoire. Vous devez également utiliser Windows Server 2008 Enterprise Edition ou une version plus récente. Il convient de noter que la fonctionnalité de haute disponibilité est disponible au niveau du cache nommé. Cela signifie que si vous deviez créer deux caches nommés dans le même cluster, vous n'utiliseriez pas nécessairement la haute disponibilité pour chacun des caches. L'application pourrait placer certains éléments dans le cache nommé avec haute disponibilité et certains dans le cache sans haute disponibilité. Cela peut vous aider à tirer le meilleur parti de ressources mémoire. Il est donc essentiel de savoir quelle décision vous prenez en matière de haute disponibilité, dans la mesure où elle double les besoins en mémoire des caches qui l'utilisent.

À titre d'exemple, voici un tableau qui évalue les besoins pour les données d'activité et de référence de la même application. Selon votre scénario, vous pourriez décider d'effectuer cette estimation au niveau objet ou application. Il vous suffit d'ajouter des colonnes à cet exemple et de les identifier de manière appropriée.

Objet à analyser :	Données d'activité	Données de référence
Taille moyenne des objets sérialisés :	250 Ko	60 Ko
Surcharge de cluster de cache par objet :	0,5 Ko	0,5 Ko
Taille moyenne ajustée des objets sérialisés :	250,5 Ko	60,5 Ko
Nombre max. d'objets actifs :	~35000	~68000
Besoins en mémoire pour la mise en cache :	8,4 Go	3,9 Go
Haute disponibilité activée ?	16,8 Go	Non
Surcharge pour les structures de données internes (5 %) :	0,8 Go	0,2 Go
Besoins totaux en mémoire :	17,6 Go	4,1 Go

La consolidation de ces estimations donne les besoins en mémoire initiaux pour le serveur de cache. Dans cet exemple, le total est 21,7 Go. Armé de cette estimation, vous pouvez maintenant commencer à envisager d'autres considérations, notamment l'infrastructure physique, les exigences du contrat de niveau de service (SLA) et les paramètres de configuration du cache d'AppFabric.

Étape trois : comprendre l'infrastructure physique et les ressources matérielles

Il est crucial de comprendre votre infrastructure physique et la disponibilité des ressources. Voici quelques questions courantes :

1. Pourrez-vous déployer des ordinateurs physiques ou des ordinateurs virtuels ?

2. Si vous avez du matériel existant, quelles sont les configurations des ordinateurs (par exemple, 8 Go de mémoire RAM, quadruple cœur) ?

3. Le cluster de cache sera-t-il situé dans le même centre de données que les serveurs d'applications ?

4. Quelles sont les capacités réseau ?

Si vous envisagez d'utiliser des ordinateurs virtuels pour les serveurs de cache, il convient de tenir compte de plusieurs considérations. Par exemple, vous devez envisager l'impact de l'exploitation de plusieurs ordinateurs virtuels sur le même ordinateur physique. Plusieurs ordinateurs virtuels peuvent partager la même carte réseau, ce qui augmente le risque de goulots d'étranglement. De même, il est possible que la haute disponibilité soit configurée entre des hôtes de cache principal et secondaire qui sont des ordinateurs virtuels sur le même ordinateur physique. Si cet ordinateur physique s'arrête, il ne reste plus aucune copie des données. Pour plus d'informations, consultez la page Guidance on running AppFabric Cache in a Virtual Machine.

Pour ce qui concerne les ordinateurs existants, il n'existe pas de spécifications recommandées. Toutefois, dans le cas de clusters de cache volumineux, des ordinateurs quadruple cœur dotés de 16 Go de RAM se sont avérés bien fonctionner. D'une manière générale, les deux éléments les plus importants à planifier correctement sont la quantité de mémoire physique et la charge réseau.

Tant pour les ordinateurs physiques que pour les ordinateurs virtuels, il convient de tenir compte de l'emplacement du cluster de cache par rapport aux serveurs d'applications ou Web qui utilisent le cache. S'ils se trouvent dans des centres de données séparés, assurez-vous que la latence entre ces centres de données n'aura pas d'incidence négative sur vos performances. À ce stade, il pourrait s'avérer tentant d'utiliser vos serveurs d'applications ou Web comme serveurs de cache. Bien que cette solution soit possible, elle n'est pas prise en charge. D'une part, toutes les pointes d'utilisation des ressources par des services comme IIS sur ces ordinateurs pourraient avoir un impact sur le cluster de cache. D'autre part, le service de mise en cache considère qu'il est sur un serveur dédié et peut, potentiellement, utiliser bien plus de mémoire que ce que vous spécifiez.

En ce qui concerne les capacités réseau, il convient d'évaluer votre charge réseau prévue et de la comparer à votre infrastructure. Pour commencer, vous devez savoir quelle quantité de données chaque serveur de cache devrait gérer et si les capacités de la carte réseau sont suffisantes. Si ce n'est pas le cas, il est possible que vous ayez besoin de plus de serveurs de cache. Par exemple, imaginez un scénario dans lequel la taille moyenne des objets mis en cache est de 500,5 Ko et où 240 opérations par seconde interviennent sur le cluster de cache. En utilisant un seul hôte de cache, les résultats seraient les suivants :

Nombre d'écritures/lectures d'objet par seconde :	240
Nombre d'ordinateurs dans le cluster de cache :	1
Nombre d'opérations de cache par ordinateur et par seconde :	240
Taille moyenne des objets :	500,5 Ko
Taille des données transmises par seconde :	240 * 500,5 = 117,3 Mbits/s

Si chaque ordinateur est doté d'une carte réseau 1 Gbps, le débit maximal est d'environ 119 Mbits/s. La valeur calculée de 117,3 Mbits/s dépasserait probablement les capacités d'un seul serveur. Il est donc plus que probable que le réseau deviendrait un goulot d'étranglement. En revanche, si trois ordinateurs étaient utilisés dans le cluster de cache, une distribution uniforme des demandes de cache se traduit par l'attribution de 1/3 de cette charge à chaque serveur.

Tenez également compte de l'utilisation du réseau par les serveurs d'applications qui accèdent au cluster de cache. S'ils échangent un volume important de données avec d'autres systèmes, il convient d'envisager de créer un réseau dédié entre les serveurs d'applications et le cluster de cache. Cela nécessite le montage d'une carte réseau supplémentaire sur chaque serveur d'applications à cette fin.

Le dernier élément à prendre en compte consiste à vérifier si le réseau peut gérer la charge requise à tous les niveaux. Il ne suffit pas que chaque serveur soit équipé d'une carte réseau 1 Gbps. Le commutateur et d'autres points du réseau doivent également être à même de gérer la charge. Travaillez en collaboration avec les équipes opérationnelles pour répondre à cette exigence.

Étape quatre : finaliser le contrat de niveau de service (SLA) en matière de performances pour toutes les applications

Avant de prendre une décision quant à la configuration définitive, vous devez également comprendre toutes les exigences métier, y compris les contrats de niveau de service (SLA) en matière de performances et de fiabilité. Dans la pratique, cette étape influence la décision relative au nombre de clusters de cache et au nombre d'hôtes de cache dans chaque cluster.

Par exemple, si vous avez une application stratégique qui utilise un cluster de cache, il se peut que vous souhaitiez isoler ce dernier d'autres applications de moindre priorité. Ces dernières pourraient utiliser plus de ressources mémoire, réseau ou processeur, ce qui aurait une implication négative sur l'application stratégique.

Voici des facteurs spécifiques qui influencent cette décision :

• La sécurité est gérée au niveau du cluster de cache. Si un utilisateur a accès au cluster de cache, il peut potentiellement accéder à toutes les données qui s'y trouvent (en supposant que cet utilisateur connaisse le nom du cache et la clé). Si vous avez besoin de différents paramètres de sécurité selon les types de données, des clusters de cache séparés prennent tout leur sens. Pour plus d'informations, consultez la page Gestion de la sécurité.

• L'élimination d'éléments non expirés se produit lorsque la mémoire atteint la limite supérieure. La sous-estimation de la quantité de mémoire pour un cache pourrait affecter tous les caches du cluster. Lorsqu'une éviction se produit en raison du niveau de sollicitation de la mémoire, elle intervient dans tous les caches, même si un seul est responsable de la sursollicitation de la mémoire. Il est possible d'atténuer quelque peu ce phénomène en créant des caches sans possibilité d'éviction, mais il convient de le faire avec prudence. Pour plus d'informations, consultez la page Expiration et éviction.

• La gestion peut s'avérer plus aisée avec des clusters de cache séparés. Vous ne souhaiterez certainement pas gérer des clusters séparés pour 100 caches différents. Toutefois, il peut se révéler pratique d'avoir des clusters de cache séparés pour 2 grands caches différents et de pouvoir ainsi les gérer, les moduler et les surveiller séparément.

Pour terminer, certaines exigences peuvent impliquer la prise en compte de la latence et du débit. Pour prendre cette décision, reportez-vous aux recommandations et aux résultats de tests du livre blanc de Grid Dynamics. Vous pouvez, par exemple, comparer vos besoins en termes de débit pour le cluster de cache avec les résultats de tests publiés dans le document de Grid Dynamics. Leur étude pourrait indiquer que vous disposez d'un nombre insuffisant de serveurs pour vos objectifs de débit. Il faut être conscient que cette étude peut ne pas correspondre exactement à vos types et tailles d'objet ni à votre infrastructure physique et logique ; elle présente néanmoins toujours des résultats de tests qui peuvent vous aider à prendre une décision informée.

Étape cinq : identifier les fonctionnalités et les paramètres de configuration appropriés d'AppFabric

Cette partie du processus envisage des paramètres de configuration spécifiques de la mise en cache d'AppFabric, ainsi que l'architecture d'un cluster de cache AppFabric. Même en ayant collecté toutes les données métier et empiriques correctes, il est toujours possible de commettre des erreurs de planification en ignorant ces paramètres de mise en cache d'AppFabric.

Le tableau suivant répertorie diverses fonctionnalités de mise en cache d'AppFabric et les considérations associées pour la planification de la capacité.

Régions	Il est possible de créer plusieurs régions, mais chacune n'existe que sur un seul hôte de cache. Pour tirer avantage du cache distribué, les applications doivent utiliser plusieurs régions. Il convient de noter que tous les appels qui ne spécifient pas de régions utilisent automatiquement les régions par défaut en interne. Chaque hôte de cache du cluster de cache doit pouvoir accueillir la taille maximale de la région la plus grande.
Notifications	Les caches peuvent activer des notifications que peuvent recevoir les clients du cache. Cela augmente le trafic réseau et l'utilisation du processeur du côté serveur. L'effet varie en fonction de l'intervalle des notifications et du nombre de notifications envoyées. L'envoi d'un grand nombre de notifications à des intervalles très courts pourrait avoir un impact sur les performances et l'évolutivité. Il n'existe pas d'indications claires permettant d'estimer cet impact qui devra donc être observé au cours des tests.
Cache local	Le cache local améliore les performances en mettant en cache des objets sur les clients ainsi que le serveur. Tenez compte de l'impact sur la mémoire des ordinateurs clients lors de l'utilisation d'un cache local. Cette fonctionnalité n'a aucune incidence sur la planification de la capacité côté serveur en termes de mémoire, puisque tous les éléments mis en cache localement existent également sur le serveur. En revanche, si des notifications sont utilisées pour l'invalidation du cache local, le côté serveur pourrait être affecté par le traitement des notifications.
Conception et configuration des applications côté serveur	La conception des applications côté serveur peut affecter les performances globales. Par exemple, il convient de stocker tous les objets DataCacheFactory que vous créez à des fins de réutilisation plutôt que de les recréer pour chaque appel. Il peut également s'avérer avantageux de créer un objet DataCacheFactory par thread. Si vous partagez un seul objet DataCacheFactory pour plusieurs threads, pensez à augmenter le paramètre MaxConnectionsToServer. Cela accroît le nombre de connexions aux serveurs de cache par DataCacheFactory.
Haute disponibilité	Comme indiqué précédemment, les caches qui utilisent la haute disponibilité impliquent de doubler les besoins en mémoire calculés. Toutefois, cette fonctionnalité exige également un minimum de trois serveurs. Si un serveur s'arrête, il doit rester deux serveurs pour prendre en charge les copies principale et secondaire de chaque élément après une défaillance. Notez que cette fonctionnalité exige également Windows Server 2008 Enterprise Edition ou une version supérieure sur tous les serveurs.
Caches nommés	À l'heure actuelle, il peut y avoir jusqu'à 128 caches nommés. Cela devient une décision de planification de la capacité lorsque vous avez des applications qui exigent un nombre de caches nommés supérieur à cette limite. Dans ce cas, vous avez besoin de plusieurs clusters de cache ou vos applications doivent être conçues pour utiliser moins de caches. Une autre stratégie consiste à créer par programmation des régions au sein même de caches nommés.
Magasin de configuration XML	Lorsque vous utilisez un emplacement réseau partagé pour le magasin de configuration de votre cluster de cache, le cluster doit comprendre au moins trois serveurs qui sont tous désignés comme hôtes principaux. Pour plus d’informations sur les raisons, consultez la page Mise à jour des serveurs de cache.

Il ne surprendra personne de savoir que l'un des éléments les plus importants à comprendre concerne les paramètres de mémoire sur chaque hôte de cache. Vous pouvez consulter les paramètres de mémoire par défaut de chaque hôte de cache à l'aide de la commande Get-CacheHostConfig de Windows PowerShell.

Notes

Pour plus d'informations sur l'utilisation des commandes Windows PowerShell de mise en cache, consultez la page Tâches courantes de gestion d'un cluster de cache.

La capture d'écran suivante illustre le résultat de Get-CacheHostConfig sur un ordinateur équipé de 4 Go de mémoire RAM.

Par défaut, la quantité de mémoire réservée au cache sur un serveur donné est de 50 % du total de la mémoire RAM. Dans cet exemple, la moitié de la mémoire RAM est 2 Go. Le reste de la mémoire est alors disponible pour le système d'exploitation et les services. Même sur des ordinateurs équipés de bien moins de mémoire, il est recommandé de conserver ce paramètre par défaut. Comme mentionné précédemment, le service de mise en cache suppose qu'il fonctionne sur un ordinateur dédié et est susceptible d'utiliser plus de mémoire que ce qui est alloué au cache. Bien que ce mode d'utilisation de la mémoire soit en partie lié à la conception interne du service de mise en cache, il découle aussi partiellement de la gestion et du nettoyage de la mémoire .NET. Même lorsque la mémoire est libérée dans une application .NET, il faut attendre le nettoyage de la mémoire. Ce processus nécessite un tampon de mémoire physique pour prendre en compte la nature non déterministe du nettoyage de la mémoire.

Une fois appréhendé l'impact du nettoyage de la mémoire, il est possible de comprendre que les charges de travail avec un haut pourcentage et une fréquence élevée d'écritures nécessiteront un tampon de mémoire plus important pour les cycles de nettoyage de la mémoire. Cette considération ne s'applique pas aux charges de travail essentiellement en lecture seule. Dans ce cas, il convient d'envisager l'augmentation de la quantité de mémoire réservée à la mise en cache. Par exemple, sur un ordinateur équipé de 16 Go de mémoire RAM, vous pourriez réserver 12 Go au paramètre de taille du cache (au lieu des 8 Go par défaut), ce qui offre 4 Go supplémentaires pour le système d'exploitation et les services. Cela repose sur l'hypothèse que l'ordinateur est dédié au service de mise en cache, ce qui est actuellement la seule configuration prise en charge. Dans cet exemple, il convient de tester cette configuration mémoire avec votre charge prévue. Si l'allocation de mémoire est trop agressive, les tests révèleront cette erreur au travers de problèmes liés à la mémoire, comme l'éviction ou la limitation. Pour plus d'informations, consultez la page Résolution des problèmes affectant les serveurs (mise en cache de Windows Server AppFabric). L'exemple suivant utilise la commande Set-CacheHostConfig pour fixer la taille du cache à 12 Go sur un serveur nommé Server1:

Set-CacheHostConfig -HostName Server1 -CachePort 22233 -CacheSize 12288

Il convient également d'observer les valeurs limites dans le résultat de Get-CacheHostConfig. La valeur LowWatermark est par défaut de 70 % du paramètre Size du cache. Lorsque la mémoire cache atteint LowWatermark, le service de mise en cache commence l'éviction des objets qui ont déjà expiré. C'est parfait, puisque ces objets sont de toute manière inaccessibles.

La valeur HighWatermark est par défaut de 90 % du paramètre Size du cache. Au niveau HighWatermark, l'éviction d'objets intervient, qu'ils aient expiré ou non, et ce jusqu'à ce que la mémoire soit de retour au niveau LowWatermark. De toute évidence, cela risque de pénaliser les performances et, éventuellement, de se traduire par une expérience négative.

Il est recommandé de planifier l'utilisation du cache au niveau LowWatermark afin d'éviter la possibilité d'atteindre le niveau HighWatermark. Pour une description plus détaillée, consultez la page Expiration et éviction.

Conseil

Des cycles complets de nettoyage de la mémoire peuvent entraîner un léger retard, qui se traduit souvent par des erreurs de nouvelle tentative. De ce fait, il est recommandé de veiller à ce que chaque hôte de cache dispose de 16 Go de mémoire ou moins. Les ordinateurs équipés de plus de 16 Go de mémoire RAM peuvent enregistrer des pauses plus longues pour les cycles complets de nettoyage de la mémoire. Cela dit, rien n'empêche d'utiliser plus de mémoire par hôte de cache. Une charge de travail qui est plus largement en lecture seule est susceptible de connaître des cycles complets de nettoyage de la mémoire moins fréquents. Il est préférable de le déterminer par le biais d'un test de charge.

Dans un exemple précédent, nous avons calculé une estimation de 21,7 Go pour nos besoins totaux de mémoire de mise en cache. Étant donné que nous souhaitons bénéficier de la haute disponibilité, au moins trois serveurs sont nécessaires. Supposons que chaque serveur soit doté de 16 Go de mémoire RAM. Dans cet exemple, nous conserverons le paramètre Size par défaut du cache de 8 Go sur chaque serveur. Comme mentionné précédemment, la valeur LowWatermark (70 %) doit être la mémoire cible disponible sur chaque serveur. Cela signifie que chaque serveur de cache dispose d'une estimation de 5,6 Go de mémoire. Avec ces facteurs, le tableau suivant montre que les quatre serveurs fourniraient 22,4 Go de mémoire de mise en cache et respecteraient l'exigence de 21,7 Go.

Besoin total en mémoire	21,7 Go
Mémoire initiale (hôte de cache)	16 Go
Paramètre Size du cache (hôte de cache)	8 Go
Limite inférieure (hôte de cache)	70%
Cible de mémoire ajustée par hôte de cache	5,6 Go
Mémoire totale sur le cluster de cache (3 ordinateurs)	5,6 Go * 4 serveurs = 22,4

Une fois encore, rappelez-vous que vous pouvez utiliser les résultats publiés dans le livre blanc de Grid Dynamics pour vérifier cette estimation par rapport aux objectifs de débit et de latence. Ces résultats de tests pourraient vous amener à modifier légèrement cette estimation initiale, par exemple en ajoutant un serveur de cache supplémentaire. L'essentiel ici est d'utiliser les ressources disponibles comme celle-ci pour prendre une décision informée.

Outil de planification de la capacité

Une feuille de calcul constitue un outil logique pour les étapes de planification de la capacité des sections précédentes. Nous avons créé un exemple de feuille de calcul que vous pouvez télécharger ici. Les entrées marquées d'un astérisque sont celles que vous devez modifier sur la base de votre planification et de vos ressources. Les autres calculs sont effectués par la feuille de calcul.

La première partie de la feuille de calcul spécifie la configuration du serveur pour chaque hôte de cache. Notez que vous pouvez effectuer des modifications dans le cadre du processus de planification et observer les différences dans les calculs finaux. La capture d'écran suivante illustre cette première section.

Important

À moins d'utiliser les valeurs d'installation par défaut, c'est à vous qu'il incombe d'utiliser la commande Set-CacheHostConfig sur chaque hôte de cache pour appliquer les paramètres CacheSize et LowWatermark.

La deuxième section vous permet d'entrer des estimations pour les différents types d'objets. Dans l'exemple de feuille de calcul, seules deux sections sont utilisées pour « Données d'activité » et « Données de référence ». La feuille de calcul comprend ensuite une série de colonnes vides. Vous pouvez renommer ces colonnes en fonction du niveau de granularité que vous utilisez dans votre planification (objet, catégorie, application, etc.). La capture d'écran suivante illustre cette deuxième section.

La troisième section estime les besoins en matière de réseau. Vous remplissez les tailles moyennes d'objets en lecture/écriture et le nombre maximum d'opérations de lecture/écriture par seconde. Cette section calcule la bande passante maximale requise pour ce type d'objet. Elle peut être utilisée pour avoir une idée approximative de la capacité de votre groupement d'ordinateurs et de cartes réseaux à gérer la charge. Comme indiqué dans les sections précédentes, vous analyserez également la bande passante sur l'ensemble du chemin réseau. La capture d'écran suivante illustre cette troisième section.

La dernière section consolide les exigences des sections consacrées à la mémoire et au réseau. Elle utilise ensuite la configuration d'ordinateur spécifiée dans la première section pour effectuer le calcul du nombre de serveurs. Le champ « Additional Servers » (serveurs supplémentaires) vous permet, au besoin, d'augmenter ce total calculé. Par exemple, si les calculs indiquent que seulement deux serveurs sont nécessaires, vous pouvez ajouter un serveur supplémentaire au total final afin de bien prendre en charge la haute disponibilité. Les captures d'écran suivantes illustrent cette dernière section.

Notes

Les captures d'écran ci-dessus utilisent des valeurs similaires à l'exemple de ce document, mais le nombre estimé de serveurs est trois au lieu de quatre. Il en est ainsi parce que la feuille de calcul définit la valeur Cache Size Setting(Set-CacheHostConfig) sur 12 GB pour illustrer ce paramètre personnalisé. Le remplacement de cette valeur par 8 GB produirait des résultats similaires à ceux présentés dans les sections précédentes de ce document.

Étapes suivantes de la planification de la capacité

La section précédente vous a présenté une méthodologie visant à déterminer une estimation initiale du nombre de clusters de cache, du nombre d'hôtes de cache dans chaque cluster et de la configuration de ces hôtes de cache. Vous devez toutefois être conscient qu'il s'agit là d'une estimation qui est susceptible de changer en fonction des tests et de la surveillance continue.

Si vous décidez d'avancer dans vos projets d'utilisation de la mise en cache d'AppFabric, vous pouvez créer une validation technique afin d'avoir une idée du fonctionnement de la mise en cache d'AppFabric dans votre solution. Ensuite, vous configurerez un cluster de cache de test afin d'exécuter des tests dans votre environnement. En fonction des résultats des tests, vous apporterez peut-être d'autres modifications à votre configuration afin de répondre aux exigences en matière de capacité, de performances et d'évolutivité. La section suivante aborde des mesures continues spécifiques que vous pouvez examiner en cours de test et en production.

Surveillance des exigences continues de capacité de mise en cache

La planification de la capacité de mise en cache n'est jamais une science exacte. Bon nombre des chiffres qui figurent dans les conclusions sont eux-mêmes des estimations. De même, l'utilisation des applications et les schémas peuvent évoluer dans le temps. De ce fait, il convient de surveiller les indicateurs de performances afin de s'assurer que le cluster de cache répond aux exigences de capacité. Une planification réussie de la capacité est un processus permanent qui continue tant dans les environnements de test que de production.

L'outil Analyseur de performances est la meilleure solution pour surveiller la capacité de manière continue. Sur chaque hôte de cache, il est recommandé de surveiller les compteurs suivants :

Catégorie de surveillance	Compteurs de surveillance des performances
Mémoire	Mise en cache d'AppFabric:Hôte\Taille totale des données en octets Mise en cache d'AppFabric:Hôte\Nombre total d'objets exclus Mise en cache d'AppFabric:Hôte\Nombre total d'exécutions d'éviction Mise en cache d'AppFabric:Hôte\Mémoire totale exclue Mise en cache d'AppFabric:Hôte\Nombre total d'objets Mémoire CLR .NET(DistributedCacheService)\Nombre de nettoyages gén. 0 Mémoire CLR .NET(DistributedCacheService)\Nombre de nettoyages gén. 1 Mémoire CLR .NET(DistributedCacheService)\Nombre de nettoyages gén. 2 Mémoire CLR .NET(DistributedCacheService)\Nombre d'objets épinglés Mémoire CLR .NET(DistributedCacheService)\% temps de nettoyage Mémoire CLR .NET(DistributedCacheService)\Taille du tas des objets volumineux Mémoire CLR .NET(DistributedCacheService)\Gen 0 Heap Size Mémoire CLR .NET(DistributedCacheService)\Gen 1 Heap Size Mémoire CLR .NET(DistributedCacheService)\Gen 2 Heap Size Mémoire\Mégaoctets disponibles
Réseau	Interface réseau (*)\Octets reçus/s Interface réseau (*)\Octets envoyés/s Interface réseau(*)\Bande passante actuelle
Processeur	Processus(DistributedCacheService)\% temps processeur Processus(DistributedCacheService)\Nombre de threads Processus(DistributedCacheService)\Jeu de travail Processor(_Total)\% temps processeur
Débit	Mise en cache d'AppFabric:Hôte\Nombre total de demandes de client Mise en cache d'AppFabric:Hôte\Nombre total de demandes de client/s Mise en cache d'AppFabric:Hôte\Nombre total de demandes Get Mise en cache d'AppFabric:Hôte\Nombre total de demandes Get/s Mise en cache d'AppFabric:Hôte\Nombre total de demandes Get Mise en cache d'AppFabric:Hôte\Nombre total de demandes Get/s Mise en cache d'AppFabric:Hôte\Nombre total de demandes GetAndLock Mise en cache d'AppFabric:Hôte\Nombre total de demandes GetAndLock/s Mise en cache d'AppFabric:Hôte\Nombre total de demandes de lecture Mise en cache d'AppFabric:Hôte\Nombre total de demandes de lecture/s Mise en cache d'AppFabric:Hôte\Nombre total d'opérations d'écriture Mise en cache d'AppFabric:Hôte\Nombre total d'opérations d'écriture/s
Divers	Mise en cache d'AppFabric:Hôte\Pourcentage des absences dans le cache Mise en cache d'AppFabric:Hôte\Nombre total d'objets expirés Mise en cache d'AppFabric\Nombre total de notifications remises

Bon nombre des compteurs répertoriés ici sont directement liés au processus de planification de la capacité. Il y a, par exemple, plusieurs compteurs de mémoire. « Mémoire\Mégaoctets disponibles » indique la quantité de mémoire physique disponible restante sur l'ordinateur en mégaoctets. Si ce compteur descend sous 10 % du total de la mémoire physique, le risque de limitation est grand. Pour plus d’informations, consultez la page Résolution des problèmes de limitation. D'autres compteurs sont spécifiques aux fonctionnalités de mise en cache. « Mise en cache d'AppFabric:Hôte\Nombre total d'exécutions d'éviction » indique le nombre d'évictions de la mémoire. Lorsque les niveaux de mémoire passent la limite supérieure, ce compteur pointera sur ces exécutions d'éviction jusqu'à ce que la mémoire soit ramenée à la limite inférieure. De même, les autres compteurs sont associés au processus de planification de la capacité présenté dans les sections précédentes de ce document.

Notez que les compteurs des processus du service, DistributedCacheService, et le compteur Processeur de l'ordinateur sont également capturés. Une utilisation élevée du processeur peut affecter négativement les performances du cluster de cache. Si vous détectez des périodes d'utilisation élevée du processeur, il est important d'identifier si elles sont liées au service de mise en cache (DistributedCacheService.exe) ou à un autre processus de l'ordinateur.

En plus de l'outil Analyseur de performances, vous pouvez utiliser les commandes Windows PowerShell qui sont installées avec AppFabric. Bon nombre de ces commandes peuvent être utilisées pour analyser le fonctionnement et l'état du cluster de cache. Pour plus d'informations, consultez les pages Outils d'analyse du fonctionnement et Logging and Counters in AppFabric Cache.

Voir aussi

Autres ressources

Installation de Windows Server AppFabric
Fonctionnalités de mise en cache de Windows Server AppFabric
Développement d'un client de cache
Configuring an ASP.NET Session State Provider
Options de stockage de la configuration du cluster
Guide de gestion et de déploiement des fonctionnalités de mise en cache de Windows Server AppFabric
Windows Server AppFabric and Windows Azure AppFabric Links and Resources

  2011-12-05