Mise en cache de sortie de la page
La mise en cache de sortie est une technique puissante qui augmente le débit de demandes/réponses en mettant en cache le contenu généré par des pages dynamiques. La mise en cache de sortie est activée par défaut, mais la sortie de toute réponse donnée n'est pas mise en cache, à moins qu'une action explicite soit effectuée en vue de permettre à la réponse d'être mise en cache.
Pour qu'une réponse puisse être mise dans le cache de sortie, elle doit posséder une stratégie d'expiration/validation valide et être visible dans le cache public. Dans ce but, utilisez soit l'API OutputCache de niveau inférieur, soit la directive @ OutputCache de niveau supérieur.
Lorsque la mise en cache de sortie est activée, une entrée de cache de sortie est créée lors de la première demande GET adressée à la page. Les demandes GET ou HEAD suivantes sont prises en charge à partir de l'entrée du cache de sortie jusqu'à ce que la demande mise en cache expire.
Le cache de sortie prend également en charge les variations de paires nom/valeur GET ou POST mises en cache.
Le cache de sortie respecte les stratégies d'expiration et de validation des pages. Si une page se trouvant dans le cache de sortie est marquée d'une stratégie d'expiration qui indique que la page expire 60 minutes après sa première mise en cache, la page est supprimée du cache de sortie une fois les 60 minutes écoulées. Si une autre demande est reçue après ce délai, le code de la page est exécuté et la page peut à nouveau être mise en cache. Ce type de stratégie d'expiration est appelé expiration absolue (absolute) (une page est valide pendant un certain temps).
L'exemple suivant illustre comment mettre facilement en cache de sortie des réponses à l'aide de la directive @ OutputCache. L'exemple affiche simplement l'heure à laquelle la réponse a été générée. Pour voir la mise en cache de sortie en action, appelez la page et notez l'heure à laquelle la réponse a été générée. Ensuite, actualisez la page et remarquez que l'heure n'a pas été modifiée, ce qui indique que la deuxième réponse est prise en charge à partir du cache de sortie.
La directive suivante active la mise en cache de sortie pour la réponse :
<%@ OutputCache Duration="60" VaryByParam="none"%>
Bien entendu, dans l'exemple précédent, seule une infime quantité de travail est enregistrée par le biais de la mise en cache de sortie. L'exemple suivant illustre la même technique de mise en cache de sortie, mais interroge une base de données et affiche les résultats dans une grille.
Dans le dernier exemple, l'application est légèrement modifiée pour permettre à l'utilisateur de rechercher les auteurs, de manière sélective, dans différents états. Cet exemple illustre la mise en cache de demandes dont les paires nom/valeur sont différentes dans la chaîne de requête, à l'aide de l'attribut VaryByParam de la directive @ OutputCache.
<%@ OutputCache Duration="60" VaryByParam="state" %>
Remarquez que la première fois que vous cliquez sur le lien correspondant à un état déterminé, il génère un nouvel horodatage au bas de la page. Ensuite, à chaque nouvel envoi d'une demande pour cet état dans la minute qui suit, vous obtenez l'horodatage d'origine, ce qui indique que la demande a été mise en cache.
Les applications qui souhaitent contrôler davantage les en-têtes HTTP liés à la mise en cache peuvent utiliser les fonctionnalités fournies par la classe System.Web.HttpCachePolicy. L'exemple suivant illustre le code équivalant aux directives de page employées dans les exemples précédents.
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60))
Response.Cache.SetCacheability(HttpCacheability.Public)
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
|
|
C#
|
VB
|
JScript
|
|
Pour en faire une stratégie d'expiration décalée (sliding), dans laquelle le délai d'expiration est réinitialisé à chaque demande de la page, définissez la propriété SlidingExpiration de la manière illustrée dans le code suivant.
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetSlidingExpiration(true);
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60))
Response.Cache.SetCacheability(HttpCacheability.Public)
Response.Cache.SetSlidingExpiration(True)
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetSlidingExpiration(true);
|
|
C#
|
VB
|
JScript
|
|
Remarque : Lorsque l'expiration décalée est activée (SetSlidingExpiration(true)), une demande adressée au serveur d'origine génère toujours une réponse. L'expiration décalée est utile en présence de caches aval susceptibles de satisfaire aux demandes des clients (si le contenu n'a pas encore expiré) sans demander le contenu au serveur d'origine.
Les applications provenant de ASP peuvent déjà définir la stratégie de cache à l'aide des propriétés ASP, telles que :
Response.CacheControl = "Public";
Response.Expires = 60;
Response.CacheControl = "Public"
Response.Expires = 60
Response.CacheControl = "Public";
Response.Expires = 60;
|
|
C#
|
VB
|
JScript
|
|
Ces propriétés sont prises en charge par ASP.NET et ont le même effet que les autres exemples mentionnés précédemment.
Résumé de la section
- La mise en cache de sortie met en cache le contenu généré par les pages ASP.NET.
- Si les pages ne possèdent pas une stratégie d'expiration ou de validation valide et si elles ne sont pas visibles dans le cache public, elles ne sont pas placées dans le cache de sortie.
|
Vérifiez
