Mise en cache de contenu statique

Question

Nous utilisons IIS7 et dotnet 3.5 dans notre société pour créer différentes applications Web utilisées par nos clients internes et externes. Il a été recommandé de commencer à utiliser la mise en cache de contenu statique pour mettre en cache les fichiers image et html. Ma compréhension est que dans le fichier web.config nous pouvons définir le cachecontrolmaxage pour spécifier le nombre de jours où les fichiers doivent être mis en cache. En outre, il a été recommandé d'appeler ces pages statiques en transmettant un argument dit myjsfile.js? Verfile = 1234 qui peut être modifié chaque fois qu'une nouvelle version du fichier est mise en production.

J'espère que je vais ci-dessus à droite? Maintenant, ce que je cherche est une meilleure façon de réaliser la deuxième partie, au lieu d'avoir à passer un nouveau numéro de version chaque fois qu'un nouveau fichier est créé, pouvons-nous le déployer d'une autre manière afin que les nouveaux changements au fichier statique dans l'environnement de production. Ce que je recherche est une façon simple de promouvoir plusieurs images et fichiers statiques en production sans avoir à changer de numéro de version.

Answer 1

Depuis IIS7, toutes les configurations IIS peuvent être appliquées via le fichier web.config, plus précisément le system.webServer section. Dans ce cas, vous devez vérifier au Caching Section et créer un custom profile (assurez-vous de définir l'attribut varyByQueryString sur true pour que le "? Version = xxx" fonctionne). Dans la question de déploiement, il est nécessaire que l'URL change puisque le client ne vérifie pas la présence d'une nouvelle version du fichier tant que le cache est valide (et vous pouvez définir des jours comme durée de cache).Un modèle commun est de générer automatiquement l'URL en fonction de la date de modification, par exemple, si votre ligne originale est:

<script src='functions.js' />

Vous pouvez changer à:

<script src='<%=GetFilenameWithModificationDate("functions.js")%>' />

La fonction doit obtenir le Fichier de modification DateTime et l'ajouter au fichier, donc si le fichier a été modifié pour la dernière fois le 2010-01-01 à 10:12:34 il devrait générer quelque chose comme ceci:

<script src='functions.js?version=201001011' />

De cette façon, chaque fois que vous modifierez le fichier, une nouvelle chaîne de requête sera incluse et le cache sera mis à jour. Puisque vous travaillez dans la mise en cache de vos fichiers statiques, je suppose que les performances sont un facteur à prendre en considération. Vous devriez donc considérer la pénalité de vérifier la date de modification pour chaque fichier et vous pouvez utiliser la mise en cache dans la fonction auxiliaire. ou quel que soit le mécanisme que vous décidez d'utiliser.

HTH

Answer 2

Oui, le bit sur l'utilisation de la chaîne de requête avec la version est correct et cela fonctionne. Cependant, je ne suis pas sûr si le changement de paramètre dans web.config s'appliquera réellement aux contenus statiques. La mise en cache des contenus statiques est gérée à IIS par la base d'administration IIS sur la recommandation du développeur à l'endroit où je travaille. À l'heure actuelle, je gère le numéro de version en un seul endroit et peut être contrôlé avec l'interface d'administration de l'application. L'inconvénient est qu'une fois le numéro de version modifié, le numéro de version de tous les fichiers statiques est modifié pour l'ensemble de l'application.

Alternativement, chaque fichier statique est nommé avec la version dans le nom du fichier, donc une fois le contenu déployé il n'y a rien à changer. Cependant, cela signifie également que le code qui fait référence au contenu statique doit également s'y référer en utilisant le nom de fichier complet et qu'il doit être modifié lorsque du contenu statique est modifié.

Espérons que cela vous aide. Gardez à l'esprit que IIS n'appellera que l'environnement d'exécution .NET pour les fichiers mappés à l'ISAPI asp.net.

Answer 3

Le contenu statique tel que .html, .jpg, etc. ne sera donc pas affecté par les paramètres web.config. Vous pouvez les mapper, mais vous perdrez les performances de cette façon. Probablement pas le meilleur itinéraire. Pour le code de script, j'utilise généralement un système comme airmanx dit ci-dessus. Paramètre global dans un fichier .config ajouté à l'URL et mis à jour lorsqu'il existe une nouvelle version. Vous pouvez automatiser cela en saisissant le numéro de version de l'application et le transmettre.

Pour un contenu statique, vous pouvez envisager de diffuser tout le contenu d'un domaine différent (par exemple, content.domain.com) et de gérer les en-têtes. dans IIS pour la mise en cache, l'expiration de contenu, etc. C'est une solution assez simple qui ne nécessite pas trop de frais généraux, bien que vous deviez impliquer vos employés si vous devez expirer du contenu. Ce n'est pas une solution entièrement automatisée, mais j'ai trouvé que cela fonctionnait assez bien sur la plupart des grands sites sur lesquels j'ai travaillé.