Cela ressemble à l'un de ces cas où la simulation (ou l'accès au code source ...> soupir <) sera probablement le seul moyen de voir quel est le comportement avec un certain degré de confiance.
La documentation de l' entrée du journal des événements pour le recyclage des quotas de CPU parle de recyclage comme suit:
Par défaut, le recyclage du pool d'applications se chevauche, ce qui signifie que le processus de travail qui doit être arrêté est exécuté jusqu'à ce qu'un nouveau processus de travail soit démarré. Après le démarrage d'un nouveau processus de travail, de nouvelles demandes lui sont transmises. L'ancien processus de travail s'arrête une fois qu'il a fini de traiter ses demandes existantes ou après un délai configuré, selon la première éventualité. Ce mode de recyclage assure un service ininterrompu aux clients. Toutefois, si une application du pool d'applications ne peut pas exécuter plusieurs instances à la fois, la rotation qui se chevauche peut être désactivée.
Il me semble que, par définition, la fin d'un processus de travail en raison d'une consommation excessive de CPU signifierait que les demandes en attente ne seraient pas autorisées à être terminées (car elles épuisent le quota de CPU).
Pour parler de votre principale préoccupation: je ne vois rien qui me porte à croire qu'un nouveau processus de travail ne serait pas automatiquement lancé. L'instruction dans votre lien Stack Overflow me fait me demander si l'algorithme utilisé par IIS peut, en fait, lier le recyclage à la résolution du temporisateur utilisé pour mesurer l'épuisement des quotas de CPU. La meilleure façon que je connaisse pour déterminer ce serait d'écrire un composant côté serveur gaspillant le processeur, de le déployer dans un environnement de test et de voir comment son comportement de recyclage agit. Un simple composant qui reste en boucle pendant quelques secondes puis renvoie une chaîne connue, combiné avec un client exécutant un faisceau de test avec quelque chose comme un pool de processus "wget" parallèles peut suffire.
Compte tenu des commentaires dans l'autre réponse, j'ai fait mes propres tests, que je reproduirai ici.
Lors de mes tests, la limitation d'un pool d'applications (v4.0 Integrated) à une petite limite de processeur (0,01%) et à un petit intervalle (1 minute) avec l' action KillW3WP activée, le dépassement de cette limite tue le w3wp en arrêtant le pool d'applications .
Une fois la limite d'intervalle atteinte, le pool d'applications est automatiquement redémarré .
Changer l'action en Aucune action ne modifie pas le processus w3wp.
Dans les deux cas, un événement système 5025 est enregistré.
la source