édition web.config - une cause d'arrêt?

Question

Sur un site, je travaille avec, nous avons deux classes de changements qu'ils peuvent demander. D'une part, ils ont des choses que je dois reconstruire et redéployer. Ils comptent ces changements comme « temps d'arrêt », parce que nous affichons un petit écran d'accueil agréable et nous testons le site à fond quand nous revenir.

D'autre part, ils nous demandent de faire un certain nombre de changements de texte, tournant ou désactiver des fonctionnalités, etc., que nous avons isolé le web.config. Nous vous proposons de faire ces soit à l'intérieur ou à l'extérieur des fenêtres de déploiement - nous suffit d'éditer le fichier, vérifiez que le changement est à droite, et revenir au travail

.

Mais l'un des gars intelligents sur le côté client a souligné que l'édition web.config recycle le pool d'application, et que les temps d'arrêt est là. Je ne l'avais jamais remarqué, mais je suppose que ce droit -. Tandis que la piscine de l'application est disponible, l'application est « down »

Mais pour combien de temps? Je ne vous demande pas de trier le niveau de confort avec des intervalles de temps d'arrêt du client, mais est-ce une perspective commune? Ou devrions-nous tout simplement pas craindre que l'édition web.config est accompagnée d'une ou deux secondes de temps d'arrêt de l'application?

Answer 1

IIS recycle le pool d'application lui-même normalement, et si ces recyclages ne vous préoccupe, cette fois ne faut pas non.

L'utilisateur ne doit pas recevoir toute sorte d'erreurs « de service non disponible », autant que je sache.

Answer 2

Tout a dit jusqu'à présent est correct.

Cependant, il y a un moyen d'éviter ce temps d'arrêt, tant que vos valeurs que vous tiriez ne sont pas mis en cache.

Vous pouvez partie port de votre fichier .config à un autre fichier, qui ne sera pas recylce la piscine app.

Il ressemblerait à quelque chose comme ça dans le fichier web.config:

<appSettings file="moresettings.config"></appSettings>

Ensuite, votre fichier extérieur ressemblerait à ceci:

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>   
<add key="SOMEKEY" value="MYVALUE"/>
</appSettings>

Answer 3

Si vous êtes préoccupé du tout avec les temps d'arrêt, et cela se produit beaucoup, j'envisager de déplacer ces paramètres dans la base de données.

Cela dit, le temps d'arrêt dans votre cas sera minime. La piscine d'application est recyclé lorsque vous enregistrez le fichier web.config, et nous parlons millisecondes.

Answer 4

Comme dit, IIS recycle en effet la piscine App. Ce n'est pas aussi mauvais que faire un plein iisreset bien - les utilisateurs ne devraient pas obtenir le « Service indisponible. » erreur que le serveur Web est toujours requsts en ligne et au service - il a juste d'attendre le AppPool pour redémarrer, ce qui signifie que le temps de réponse pour les utilisateurs qui accèdent à ce moment sont très élevés. Cela peut être un problème bien sûr si vous avez un site Web public et détourniez visiteurs.

Les autres effets secondaires du recyclage AppPool sont les mêmes comme iisreset: Il débusque une session InProc cache si je ne me trompe pas, et il exécute l'événement Application_Start

.

Donc, même si elle est relativement inoffensif, je traiterais encore comme temps d'arrêt.