6
votes

Sortie ASP.NETCache et post-retours

J'essaie de comprendre le mécanisme ASP.NET SortieCache.
J'ai construit une page de test avec une étiquette et un linkbutton.
Le texte de la marque est en cours d'initialisation sur le serveur avec la date de serveur actuelle sur chaque pageload: xxx

J'ai utilisé cette directive: <% @ de sortieCache Durée = "600" varybyparam = "Aucun "%>

Quand j'appuie sur le linkbutton la première fois que je reçois un nouveau texte dans l'étiquette, mais si j'appuie à nouveau sur le linkbutton, je ne reçois pas de nouveau texte.

Je suppose que cela est dû aux paramètres qui sont transférés sur le serveur qui sont les mêmes pour chaque publication.

Y a-t-il un moyen de travailler avec les contrôles de sortiecach et de publication?


0 commentaires

3 Réponses :


0
votes

Ce dont vous avez besoin est la substitution post-cache:

Mise à jour de manière dynamique des parties d'une page mise en cache


0 commentaires

3
votes

Vous êtes correct dans vos hypothèses.

Votre directive de sortieCache indique au mécanisme de mise en cache de sortie de mettre en cache la page entière rendu pour une URL spécifique, pendant 600 secondes.

Dans votre exemple simple, vous n'utilisez probablement aucune chaîne de requête, cependant, la déclaration de Varybyparam dans la directive vous permet de spécifier un paramètre de chaîne de requête garantissant que chaque valeur différente de ce paramètre est mise en cache séparément. Par exemple, si vous aviez: xxx

, ces trois URL différentes seront chacune mise en cache individuellement et modifiant la valeur du paramètre "Producteur" à quelque chose de non encore mis en cache garantirait que la page est traitée et rendue par l'exécution ASP.NET correctement: xxx

dans votre exemple, sur votre bouton, la page a déjà été précédemment rendue (et mise en cache) Et lorsque vous postez à nouveau de retour, aucune différence dans l'URL ne pose que le rechargement de la récupération et le rechargement efficacement, l'ASP.NET Runtime affichera la page mise en cache à vous sans passer le processus de re-rendu.

autre que par modification de la valeur d'un paramètre "VaryByByparam", la directive de sortieCache est un peu une approche "tout-ou-" tout "de la mise en cache de page. Il existe un "VarybyContol" attribu à la directive, cependant, qui ne peut être utilisé que dans les contrôles d'utilisateur ASP.NET, plutôt une page Web ASP.NET complète.

de votre question, cela ressemble plus Vous devez enquêter Caching de page partielle . Soit cela ou un mécanisme pour invalider le cache lorsque certains événements se produisent. Ceci est généralement fait en ajoutant une "dépendance au cache".

Pour cela, les liens suivants devraient aider:

portions de mise en cache d'une page ASP.NET
Conseil / Trick: Implémentez" Caching de beignet "avec la fonction de substitution de cache de sortie ASP.NET 2.0

Suppression de manière programmée une page à partir de la sortieCache


0 commentaires

7
votes

Droite, la chose est que vous n'êtes pas varié par aucun paramètre, donc la réponse de la première requête HTML est mise en cache et servie pendant les 10 prochaines minutes (en théorie). Si vous souhaitez mettre en cache Obtenir, mais traiter différents messages, vous devriez varier selon vos paramètres de poste.

Permettez-moi de vous donner un exemple. Vous avez une entrée de texte utilisée pour envoyer un courrier électronique avec son contenu sur Post. Si vous variables par ce nom d'entrée, chaque demande dans la période de mise en cache de la durée de mise en cache avec différentes valeurs de cette entrée de texte frapperait votre gestionnaire et processus en envoyant l'e-mail.

de l'autre côté, vous pouvez varier en *, mais vous perdriez la mise en cache en mode noyau.


3 commentaires

Pouvez-vous poster un exemple de chaud pour utiliser mes paramètres de poste en tant que Varybyparam?


Assurez-vous, <% @ SortieCache Durée = "600" VarybyParam = "Yourporosparam1, Yourporm2, (Toute get Params également), ..."%>


Je suis juste compris cela avant de trouver ce poste - nous avons eu un problème avec un déploiement en direct parce que nous avions VaryByparam réglé sur "Aucun" où les pages postaient elles-mêmes!