Qu'est-ce qui arrive à d'autres utilisateurs si le processus de travail .NET se bloque?

Question

Ma connaissance de la façon dont les processus sont gérés par le processus de travail ASP.Net est nettement insuffisant. J'espère que certains des experts là-bas peut me remplir.

Si je crash le processus de travail avec un System.OutOfMemoryException, qu'est-ce que l'expérience utilisateur soit pour les autres utilisateurs qui étaient desservis par le même processus? Seraient-ils obtenir un écran blanc? 503 erreur?

Je vais tenter de tester ce scénario avec d'autres personnes dans notre laboratoire, mais je pensais que je flotterait ce là-bas. Je mettrai à jour avec nos résultats.

UPDATE : Nos résultats ont varié. Si nous artificiellement induit une exception OOM (par exemple en chargeant des fichiers PDF plus en plus grandes dans la mémoire), d'autres fils étant desservis par ce processus de travail serait « bloquer » temporairement et complète, tandis que d'autres semblent ne jamais revenir. Merci pour vos réponses.

Answer 1

W3WP.exe est le processus

IIS exécute toutes les applications Web dans un processus de travail générique - w3wp.exe. Si vous écrivez dans ASP.NET, ou ISAPI, ou un autre cadre, le processus qui sert la demande Web est w3wp.exe. Dans le cas d'ASP.NET, w3wp.exe charge les DLL compilé JIT-ASP.NET et services les demandes à travers eux. Dans d'autres cas, cela fonctionne différemment. Mais le point clé est, w3wp.exe est le processus. Ce modèle a commencé à IIS6.0 et continue à IIS7.0.

Les échecs inattendus

Si le W3WP.exe échoue de façon inattendue, pour une raison quelconque, toutes les transactions qu'il a été handling probablement une erreur 500 (erreur de serveur). IIS va commencer un nouveau processus de travail à sa place ( MS appelle cette « de surveillance de la santé »), ce qui signifie que l'application Web continuera à fonctionner. Les utilisateurs qui ne disposent pas d'une demande desservie par le processus défaillant au moment de l'échec, seront pas au courant de tout cela.

  

L'erreur HTTP 500 qu'un client reçoit dans ce cas, sera impossible à distinguer d'une erreur 500 que le client reçoit dans le cas d'une erreur d'application, disons une exception dans votre code uncaught d'application ASPNET.

Pour les demandes qui étaient dans le processus défaillant, il n'y a aucun moyen de les récupérer. Ils se traduiront par 500 erreurs au niveau du navigateur. A 503 serveur IIS Résultats de disponibilité à partir de refuser activement la connexion en raison d'un seuil sur le nombre de connexions. A 503 ne résulte pas d'un échec de l'application, vous ne devriez pas vous attendre à voir 503 pour les transactions en cours dans le scénario hors de la mémoire et l'accident. Sur un système très chargé, vous pouvez voir 503 est comme le processus de plantage et de redémarrage se produit, comme un effet secondaire. Si cela est vraiment ce que vous voyez, vous avez besoin d'une plus grande marge de sécurité pour gérer la charge dans la seule condition d'erreur.

La file d'attente demande

IIS a une approche intercellulaire pour les demandes . Comme ils arrivent sur la couche de réseau (Http.sys), ils sont placés dans une file d'attente, pour être pris en charge par un processus de travail. Toute demande en attente dans la file d'attente d'IIS à traiter par un WP continuera pas affecté, mais ils pourraient voir une légère augmentation temporaire de la latence (temps de service) en raison de conflits de ressources, car un processus moins est en cours d'exécution sur le serveur. Le temps d'attente dans cette file d'attente est généralement très très court, sur un système qui est configuré correctement.

Il est quand cette file d'attente est pleine que vous verrez 503 erreurs.

redémarrage automatique de W3WP.exe

IIS a une installation de redémarrage automatique (ou "nounou"), à travers laquelle il redémarre les processus de travail après qu'ils ont dépassé les seuils configurés , tels que la taille de la mémoire, le nombre de demandes, ou temps de marche. Dans tous les cas, IIS et redémarrez quiesce les processus de travail lorsque le seuil configuré est atteint. Ces redémarrages pro-actifs normalement ne donne pas lieu à une interruption des demandes. Lorsque IIS décide qu'un redémarrage d'un processus de travail est nécessaire, il empêche toute nouvelle demande d'arriver à ce point d'être mis au repos WP. Les demandes existantes sont drainées : toutes les transactions en cours dans ce WP sont autorisés à remplir normalement. Lorsque toutes les demandes dans le GT complet, le GT meurt et IIS démarre un nouveau à sa place. Ce nouveau processus commence alors immédiatement la cueillette de nouvelles demandes de la file d'attente d'expédition. Tout cela est transparent pour les utilisateurs ou les navigateurs.

Je dis normalement , car il est possible que le pro des travailleursCESS est devenu vraiment malade en même temps que le seuil a été atteint. Dans ce cas, le w3wp.exe ne peut pas répondre à IIS dans les le délai d'attente configuré « quiesce » , et donc IIS doit tuer finalement le processus même si elle n'a pas rapporté que toutes ses demandes ont terminé en vol. Cela devrait être très rare, car il est deux conditions exceptionnelles distinctes, mais il arrive. Dans ce cas, les demandes en vol seront encore une fois, une erreur 500.

Jardins Web

En outre - IIS permet des processus de travail multiples sur un seul serveur. appels MS ce « jardin Web » , un jeu de mots de la « ferme Web ». Si vous avez un jardin Web mis en place, étant alors servi les transactions par des instances w3wp.exe autres que celui ne, continuera pas affecté. « Insensible » suppose cependant, que l'erreur hors mémoire est localisée, et non un problème de système.

Bottom Line

La ligne de fond est qu'il n'y a pas de substitut à vos propres tests. Les options de configuration sont assez large - de seuils de redémarrage aux jardins Web et ainsi de suite. De plus, les modes de défaillance ont tendance à être assez complexes et variées, que ce soit la mémoire, délai d'attente, trop occupé, et ainsi de suite. Vous aurez envie de comprendre ce qu'il faut attendre.

ps: ce Q & A appartient vraiment serverfault.com !!

---

références:
http: // blogs. iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx

Answer 2

Un nouveau thread de travail sera lancé et l'utilisateur ne sait pas quoi que ce soit arrivé. A moins qu'il ne se arrête complètement via rapide échouent ( http: // technet.microsoft.com/en-us/library/cc779127(WS.10).aspx )

Answer 3

Si c'est une situation hors de la mémoire, iis généralement recyclages juste la piscine app.

Answer 4

Comme les autres réponses disent, dans la plupart des cas tout redémarre juste, et la plupart des utilisateurs qui ne disposent pas d'une demande en attente au moment ne remarqueront pas beaucoup plus qu'un retard.

Toutefois, si votre application utilise des variables de session avec l'état de session In-Proc, toutes les variables de session pour tous les utilisateurs seront perdus lors du redémarrage du pool d'applications. Cela peut ou peut ne pas avoir un effet négatif sur les utilisateurs, en fonction de ce que vous faites avec les variables de session. Vous pouvez éviter cela en passant au stockage de la session StateServer ou SQL Server.