Vue d’ensemble de la mise en cache dans ASP.NET Core

Par Rick Anderson et Kirk Larkin

Mise en cache en mémoire

La mise en cache en mémoire utilise la mémoire du serveur pour stocker les données mises en cache. Ce type de mise en cache convient pour un seul serveur ou plusieurs serveurs utilisant l’affinité de session. L’affinité de session est également connue sous le terme de sessions permanentes. L’affinité de session signifie que les demandes d’un client sont toujours routées vers le même serveur pour traitement.

Pour plus d’informations, consultez Mettre en cache en mémoire dans ASP.NET Core et Résoudre les problèmes d’affinité de session Azure Application Gateway.

Cache distribué

Utilisez un cache distribué pour stocker des données en mémoire lorsque l’application est hébergée dans un cloud ou une batterie de serveurs. Le cache est partagé entre les serveurs qui traitent les demandes. Un client peut envoyer une requête gérée par n’importe quel serveur du groupe si les données mises en cache pour le client sont disponibles. ASP.NET Core fonctionne avec les caches distribués SQL Server, Redis et NCache.

Pour plus d’informations, consultez Mise en cache distribuée dans ASP.NET Core.

Tag Helper de cache

Mettez en cache le contenu d’une vue ou d’une Razor page MVC avec le Tag Helper de cache. Le Tag Helper cache utilise la mise en cache en mémoire pour stocker les données.

Pour plus d’informations, consultez assistance des balises de cache dans ASP.NET Core MVC.

Tag Helper Cache distribué

Mettez en cache le contenu à partir d’une vue MVC ou d’une Razor page dans des scénarios cloud distribué ou de batterie de serveurs web avec le tag Helper du cache distribué. Le Tag Helper du cache distribué utilise SQL Server, Redis ou NCache pour stocker des données.

Pour plus d’informations, consultez assistance distribuée des balises de cache dans ASP.NET Core.

Mise en cache des réponses

L’intergiciel de mise en cache des réponses :

• Active la mise en cache des réponses du serveur en fonction des en-têtes de cache HTTP. Implémente la sémantique de mise en cache HTTP standard. Caches basés sur des en-têtes de cache HTTP comme les proxys.
• N’est généralement pas bénéfique pour les applications d’interface utilisateur telles que Razor Pages, car les navigateurs définissent habituellement des en-têtes de requête qui empêchent la mise en cache. La mise en cache de sortie, disponible dans ASP.NET Core 7.0 et versions ultérieures, bénéficie aux applications d’interface utilisateur. Avec la mise en cache de sortie, la configuration détermine ce qui doit être mis en cache indépendamment des en-têtes HTTP.
• Peut être utile pour les demandes d’API GET ou HEAD publiques provenant de clients pour lesquels les conditions de mise en cache sont remplies.

Pour tester la mise en cache des réponses, utilisez Fiddler ou un autre outil qui peut définir explicitement des en-têtes de requête. La définition explicite d’en-têtes est recommandée pour tester la mise en cache. Pour plus d’informations, consultez la page Dépannage.

Mise en cache de la sortie

L’intergiciel de mise en cache de sortie permet la mise en cache des réponses HTTP. La mise en cache de sortie diffère de la mise en cache des réponses des manières suivantes :

• Le comportement de mise en cache est configurable sur le serveur.

  Le comportement de mise en cache des réponses est défini par les en-têtes HTTP. Par exemple, lorsque vous visitez un site web avec Chrome ou Edge, le navigateur envoie automatiquement un Cache-control: max-age=0 en-tête. Cet en-tête désactive efficacement la mise en cache des réponses, car le serveur suit les instructions fournies par le client. Une nouvelle réponse est retournée pour chaque requête, même si le serveur a une nouvelle réponse mise en cache. Avec la mise en cache de sortie, le client ne remplace pas le comportement de mise en cache que vous configurez sur le serveur.

• Le support de stockage du cache est extensible.

  La mémoire est utilisée par défaut. La mise en cache des réponses est limitée à la mémoire.

• Vous pouvez invalider par programmation les entrées de cache sélectionnées.

  La dépendance de la mise en cache des réponses vis-à-vis des en-têtes HTTP vous laisse peu d’options pour invalider les entrées de cache.

• Le verrouillage des ressources atténue le risque de tamponnement du cache et de troupeau tonitruant.

  L’horodatage du cache se produit lorsqu’une entrée de cache fréquemment utilisée est révoquée et qu’un trop grand nombre de demandes tentent de remplir à nouveau la même entrée de cache en même temps. Le troupeau tonitruant est similaire : une rafale de demandes pour la même réponse qui n’est pas déjà dans une entrée de cache. Le verrouillage des ressources garantit que toutes les requêtes pour une réponse donnée attendent que la première demande remplisse le cache. La mise en cache des réponses n’a pas de fonctionnalité de verrouillage des ressources.

• La revalidation du cache réduit l’utilisation de la bande passante.

  La revalidation du cache signifie que le serveur peut retourner un code d’état HTTP 304 Not Modified au lieu d’un corps de réponse mis en cache. Ce code statut informe le client que la réponse à la requête est inchangée par rapport à ce qui a été reçu précédemment. La mise en cache des réponses ne fait pas de revalidation du cache.