Pourquoi le processus de travail IIS recycle-t-il toutes les 29 heures et non toutes les 24 heures?

Lorsque vous configurez un site sur IIS, le processus de travail est recyclé par défaut toutes les 1740 minutes (29 heures). Pourquoi un nombre impair comme 29 heures et non, par exemple, 24 ou 48 heures?

À Tech Ed 2003, le présentateur a posé cette question, et la réponse était qu'ils voulaient un cycle irrégulier pour l'empêcher de se produire sur une frontière quotidienne (par exemple pour se distinguer des autres tâches quotidiennes planifiées sur le serveur / domaine).

Le site ici (lien mort) a spéculé:

... (29 est le) premier premier après 24, ce qui lui permet d'avoir le moins de chance de se produire de façon régulière avec tout autre processus serveur; faciliter l'enquête sur les problèmes

Un autre site semble le confirmer:

( Wade Hilmo ) a suggéré 29 heures pour la simple raison qu'il s'agit du plus petit nombre premier supérieur à 24. Il voulait un schéma décalé et non répétitif qui ne se produise pas plus d'une fois par jour.

OK, cela me dérangeait, alors j'ai fouillé et j'ai finalement trouvé cette publication d'un gars qui apparemment faisait partie de l'équipe IIS:

La raison pour laquelle IIS6 recycle toutes les 29 heures par défaut (et nous avions une raison

La raison pour laquelle IIS6 recycle toutes les 29 heures par défaut (et nous avions une raison de choisir 29 heures comme valeur par défaut) est que, plus probablement qu'autrement, l'application Web qui s'exécute sur elle n'est pas fiable et doit littéralement redémarrer fréquemment.

Ainsi, IIS6 est construit sur la prémisse (certes cynique) que l'application Web de l'utilisateur ne fonctionnera pas pendant plus de 24 heures contiguës, les fonctionnalités sont planifiées en conséquence et les valeurs par défaut choisies. Les processus de travail sont recyclés toutes les 29 heures, le démarrage et l'arrêt du processus sont surveillés, le processus est constamment ping pour s'assurer qu'il est en cours d'exécution, le descripteur du processus est suivi et signalé lorsqu'il se termine de manière inattendue, etc., etc.

Réalisant que le recyclage fait partie intégrante des opérations, IIS6 veille également à isoler ce recyclage de l'utilisateur final - la connexion TCP de l'utilisateur final ne se termine jamais pendant un recyclage, en raison d'une certaine magie en mode noyau. Combiné avec une application en mode utilisateur qui stocke hors processus l'état de session (comme ASP.Net Session State Service), une disponibilité fiable est pratiquement garantie sans perte de données visible par l'utilisateur, même si l'application Web se bloque après le traitement de chaque demande de l'utilisateur.

C'est à peu près aussi bon que IIS6 peut le faire - étant donné une application Web peu fiable, la faire paraître fiable pour l'utilisateur final et le faire sans nécessiter de correctifs de l'application Web non fiable.

Bien sûr, toutes les applications non fiables ne peuvent pas sembler fiables - si c'est le cas, alors nous sommes tous sans emploi! - mais IIS6 essaie certainement beaucoup plus d'être résilient.

Dans votre cas, il se trouve que la résiliation a un effet secondaire sur l'état utilisateur non persistant, mais elle peut être facilement ajustée.

En supposant que votre application Web n'a jamais de problème et reste avec l'état de session en cours, vous souhaiterez modifier ces valeurs par défaut: 1. Désactivez le recyclage périodique de 29 heures 2. Désactivez le délai d'inactivité de 20 minutes

Cela empêchera la perte inattendue de l'état de session.

Bien sûr, si vous utilisez une application avec un état de session hors processus, vous pouvez tout laisser comme paramètres par défaut et ne jamais remarquer de différence de fonctionnalité ou de fiabilité.