Pourquoi IIS utilise-t-il par défaut le recyclage du pool d'applications toutes les 1740 minutes?

Pourquoi IIS par défaut recycle-t-il le pool d'applications après un certain temps? Y a-t-il une raison spécifique autre que peut-être que la plupart des applications Web ne gèrent pas la mémoire avec prudence? Étant donné que vous gérez correctement la mémoire de votre application, est-il sûr de continuer et de désactiver cette fonction? Quels sont les inconvénients potentiels, les avantages à désactiver le recyclage ou à le conserver?

Oui, la raison pour laquelle elle est par défaut une fois par jour est due au souci que l'application Web puisse avoir une fuite de mémoire. Le plus gros inconvénient du recyclage fréquent des pools d'applications IIS est qu'il entraînera la lecture de web.config, le chargement de l'assembly et une recompilation des pages asp.net et (si vous ne croyez pas en les précompilant) des codes derrière. C'est un processus assez lourd et il ne se produit pas jusqu'à la prochaine demande de page après le recyclage du pool d'applications, ce qui ralentit considérablement cette demande particulière. IIS7 dispose désormais d'un module que vous pouvez télécharger appelé Application Warm Up pour vous aider à "résoudre" ce problème.

Personnellement, je préfère utiliser des maximums basés sur la mémoire associés à la connexion au démarrage de l'application plutôt que de planifier mon recyclage. Cela me permet de supposer que mon application ne présente aucune fuite de mémoire et de se révéler erronée lorsque le pool d'applications est recyclé.

1740 minutes soit 29 heures:

À l'époque où IIS 6 était en cours de développement, qui est la version qui a introduit les pools d'applications, une valeur par défaut devait être définie pour l'intervalle de temps normal lorsque les pools d'applications sont automatiquement recyclés.

Wade 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. Selon les mots de Wade: «vous n'obtenez pas un motif résonnant». La valeur par défaut est de 1740 minutes (29 heures) depuis!

http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx

La fonctionnalité est une survivance des jours ASP classiques où tout fuyait de la mémoire et que vous deviez le faire. La plupart des gens avaient un redémarrage planifié sur le serveur Web pendant la nuit. IIS6 a automatisé cela avec des arrêts du pool d'applications toutes les 1740 minutes (ou si l'application est inactive pendant 20 minutes). IIS7 a poursuivi la tradition.

Le conseil que j'ai reçu de Microsoft à l'époque était que cela n'était pas nécessaire à moins que vous n'ayez une application héritée avec une fuite de mémoire connue. Donc, si vous exécutiez du code purement géré, vous seriez d'accord.

Arrêtez-le et surveillez les pools d'applications. La plupart des applications d'entreprise complexes utilisent beaucoup de code hérité et une grande partie de ce code est un peu perméable. Donc, pour la plupart des installations, le redémarrage occasionnel du pool d'applications n'est pas une mauvaise idée.

Il existe d'autres options comme la surveillance du temps d'inactivité qui peuvent être une meilleure solution pour votre situation.

Faire tourner un pool d'applications peut prendre un certain temps et rendre l'application moins réactive, donc les maintenir peut améliorer les performances.

En effet, il s'agit purement de nettoyer les fuites de ressources qui pourraient (être) présentes. Les 1740 minutes ne sont pas non plus le seul événement déclencheur. Cela se produit également après un nombre maximal spécifique de demandes ou après avoir dépassé une quantité spécifique de mémoire de processus de travail. Il est assez bien documenté dans la bibliothèque MSDN. Malheureusement, cette politique casse des choses comme l'état de session et la statique comme les singletons. Votre application devra être suffisamment robuste pour réauthentifier les utilisateurs et / ou réinitialiser les singletons selon les besoins afin d'éviter de perturber l'expérience de votre utilisateur. Cela nous a obligés à gérer les sessions authentifiées dans la base de données plutôt que dans la session ASP.NET. Sinon, nos utilisateurs ont été redémarrés sur notre page de connexion chaque fois que le serveur se recyclait en raison de l'un de ces déclencheurs.