Caching de page statique à long terme

Question

Je maintiens plusieurs sites clients qui n'ont aucune donnée dynamique, tout est statique asp.net avec C#.
Y at-il des pièges à la mise en cache de la page entière pendant des périodes extrêmes, comme une semaine? Kibee, Nous utilisons quelques contrôles sur les sites (ad rotator, certaines des extensions ajax) sur les sites. Ils pourraient probablement être complètement écrit en html, mais pour des raisons de commodité, je me suis contenté de ce que nous utilisons pour tous les autres sites.

Answer 1

Lorsque vous dites que vous n'avez aucune donnée, comment utilisez-vous même asp.net ou C#? Quelles fonctionnalités cela vous apporte-t-il par rapport au HTML pur? En outre, si vous planifiez la mise en cache, il est probablement préférable de mettre en cache dans un fichier, puis, une fois la requête effectuée, diffusez le fichier. Le système d'exploitation prendra soin de garder le fichier en mémoire afin que vous n'ayez pas à le lire tout le temps sur le disque.

Answer 2

Vous pouvez intégrer un mécanisme de mise à jour de cache si vous voulez le faire, juste pour vous assurer que vous pouvez vider le cache si vous devez faire une mise à jour du code. A part ça, il n'y a pas de problèmes auxquels je puisse penser.

Answer 3

Le seul écueil important pour les temps d'antémémoire longs se produit lorsque vous souhaitez mettre à jour ces données. Pour être sûr, vous devez supposer que cela prendra jusqu'à une semaine pour que la nouvelle version devienne disponible. Les hôtes intermédiaires, tels que les serveurs proxy de niveau ISP, effectuent souvent une mise en cache agressive, de sorte que ce délai se produira.

S'il existe des fichiers volumineux à mettre en cache, je m'assurerais que votre moteur de contenu prend en charge If-Modified-Since. Pour les fichiers plus petits (contenu de la page, CSS, images, etc.), où la réduction du nombre d'allers-retours est la clé, avoir une longue durée d'expiration (un an?) Et changer l'URL lorsque le contenu change est le meilleur. Cela vous permet de contrôler quand les agents utilisateurs vont chercher le nouveau contenu.

Yahoo! ont publié un article en deux parties sur reducing HTTP requests et browser cache usage. Je ne vais pas tout répéter ici, mais ce sont de bonnes lectures qui vous guideront sur ce qu'il faut faire. Mon sentiment est de choisir une période suffisamment élevée pour couvrir la plupart des utilisateurs des sessions simples, mais suffisamment faible pour ne pas causer trop d'inconvénients si vous souhaitez mettre à jour le contenu. Assurez-vous de prendre en charge If-Modified-Since si vous avez un Last-Modified pour tout votre contenu. Enfin, si votre contenu peut être mis en cache du tout et que vous devez maintenant sortir du nouveau contenu, vous pouvez toujours utiliser une nouvelle URL. Cette URL de contenu cachable final peut s'asseoir derrière une URL fixe HTTP 302 redirect si vous souhaitez publier un lien permanent vers la dernière version.

Answer 4

Nous avons un problème similaire sur un projet sur lequel je travaille. Il y a des données qui sont à peu près statiques, mais qui sont ouvertes au changement.

Ce que j'ai fini par faire est d'enregistrer les données dans un fichier local, puis de les surveiller pour les changements. Le serveur de base de données n'est alors jamais touché, sauf si nous supprimons le fichier, auquel cas il se déporte sur la base de données et régénère le fichier de données. Donc, ce que nous avons essentiellement un peu d'E/S disque lors du chargement/enregistrement, pas de trafic vers le serveur DB sauf si nécessaire et nous sommes toujours en contrôle (nous pouvons soit supprimer manuellement ou le script etc). J'ajouterais aussi que vous pourriez ensuite lier ceci au modèle de mise en cache du serveur web si vous vouliez réduire l'E/S du disque (nous n'en avions pas vraiment besoin dans notre cas).

Cela pourrait être tout à fait la mauvaise façon de s'y prendre, mais il semble fonctionner assez bien pour nous :)

Answer 5

Si elle est statique, vous seriez probablement mieux générer les pages une fois au large et servir ensuite la fichier HTML statique résultant directement.

Answer 6

Si c'est statique, pourquoi déranger du tout? Laissez IIS s'inquiéter à ce sujet.