Utiliser plusieurs instances de MemoryCache

Je suis récemment passé par là aussi. Considérer qu’un cache en mémoire est spécifique au processus (non partagé entre plusieurs instances d’un site Web ou d’une application métier native ou de plusieurs serveurs), il n’y a vraiment aucun avantage à avoir plusieurs instances de MemoryCache , sauf pour des raisons organisationnelles de code .

Le cache mémoire est destiné à être utilisé seul principalement en raison de ses capacités de gestion de la mémoire. En plus des compteurs de performance (qui ont une certaine surcharge), le MemoryCache peut également expirer des éléments quand il manque de mémoire allouée.

Si l’instance actuelle du cache dépasse la limite de mémoire définie par la propriété CacheMemoryLimit, l’implémentation du cache supprime les entrées de cache. Chaque instance de cache de l’application peut utiliser la quantité de mémoire spécifiée par la propriété CacheMemoryLimit.

à partir de la propriété MemoryCache.CacheMemoryLimit

En utilisant une seule instance de MemoryCache, il est possible d’appliquer cette gestion de la mémoire efficacement sur l’ensemble de l’instance d’application. Expirer les éléments les moins importants dans toute l’application. Cela garantit une utilisation maximale de la mémoire sans dépasser vos capacités matérielles. En limitant la scope d’un seul MemoryCache (comme une instance d’une classe), il ne peut plus gérer efficacement la mémoire de votre application (car elle ne peut pas tout voir). Si tous ces caches étaient “occupés”, vous auriez peut-être plus de mal à gérer la mémoire et ce ne serait jamais aussi efficace.

Ceci est particulièrement sensible dans les applications qui n’ont pas le luxe d’un serveur dédié. Imaginez que vous exécutiez votre application sur un serveur partagé sur lequel vous ne disposiez que de 150 Mo de RAM (hébergement à 10 $ / mois bon marché commun) sur lequel vous devez compter pour l’utiliser au maximum sans le dépasser. Si vous dépassez cette utilisation de la mémoire, votre pool d’applications sera recyclé et votre application perd tout en mémoire cache! (pratique d’hébergement bon marché commune) La même chose pourrait s’appliquer à une application non Web hébergée en interne sur un serveur d’entreprise partagé. Même accord, on vous dit de ne pas utiliser toute la mémoire de cette machine et de coexister pacifiquement avec d’autres applications professionnelles.

Cette limite de mémoire, le pool d’applications recyclées, la perte de caches est un «talon d’Achille» commun aux applications Web. Lorsque les applications sont les plus sollicitées, elles sont réinitialisées le plus souvent en raison des allocations de mémoire excédentaires, de la perte de toutes les entrées de cache et de la récupération des tâches qui auraient dû être mises en cache. Ce qui signifie que l’application perd réellement des performances à charge maximale au lieu de gagner.

Je sais que MemoryCache est la version non spécifique à Web de l’implémentation de System.Web.Caching.Cache, mais cela illustre la logique de l’implémentation du cache. La même logique peut s’appliquer dans un projet non Web si vous n’utilisez pas exclusivement le matériel. N’oubliez pas que si votre cache force la machine à effectuer des permutations de fichiers de pages, votre cache ne sera plus plus rapide que la mise en cache sur disque. Vous voudrez toujours une limite quelque part, même si cette limite est 2 Go ou quelque chose.

Dans mon cas, après avoir lu à ce sujet, je suis passé à l’utilisation d’un “MemoryCache statique public” dans mon application et j’ai simplement séparé les éléments mis en cache par leurs clés de cache. Par exemple, si vous souhaitez mettre en cache sur une instance, vous pourriez avoir une clé de cache comme quelque chose comme “instance- {instanceId} -resourceName- {resourceId}”. Considérez-le comme un nom espaçant vos entrées de cache.

J’espère que cela pourra aider!

J’en utilise plusieurs aussi. Généralement un par type.

En regardant le MemoryCache je constate qu’il se MemoryCache aux MemoryCache et gère les compteurs de performance. J’imagine que l’utilisation de plusieurs ressources (par exemple, CPU, compteurs et mémoire) est liée aux ressources et c’est pourquoi elle est déconseillée.