Cosa succede ad altri utenti, se il processo di lavoro .NET si blocca?

Question

La mia conoscenza di come i processi sono gestiti dal processo di lavoro ASP.Net è del tutto inadeguato. Spero che alcuni degli esperti là fuori mi può compilare.

Se mi schianto il processo di lavoro con uno System.OutOfMemoryException, quale sarebbe l'esperienza utente sia per gli altri utenti che venivano serviti con lo stesso processo? Avrebbero ottenere uno schermo vuoto? 503 errore?

ho intenzione di tentare di testare questo scenario con alcune altre persone nel nostro laboratorio, ma ho pensato di fluttuare questa là fuori. I aggiornerà con i nostri risultati.

Aggiorna : I nostri risultati variavano. Se indotta artificialmente un'eccezione OOM (ad esempio caricando file PDF di dimensioni più grandi e nella memoria), altri thread serviti da quel processo di lavoro avrebbe "appendere" temporaneamente e poi completa, mentre altri apparentemente non avrebbero mai tornare. Grazie per le vostre risposte.

Answer 1

W3WP.exe è il processo

IIS viene eseguito tutte le applicazioni web in un processo di lavoro generica - w3wp.exe. Sia che si scrive in ASP.NET, o ISAPI, o qualche altro quadro, il processo che serve la richiesta web è w3wp.exe. Nel caso ASP.NET, w3wp.exe carica le DLL JIT-compilato ASP.NET e dei servizi le richieste attraverso di loro. In altri casi, funziona in modo diverso. Ma il punto chiave è, w3wp.exe è il processo. Questo modello è iniziato nel IIS6.0 e prosegue in IIS7.0.

guasti imprevisti

Se il W3WP.exe non riesce inaspettatamente, per qualsiasi motivo, tutte le transazioni è stato trattamento sarà probabilmente ottenere 500 errori (Errore del server). IIS inizierà un nuovo processo di lavoro al suo posto ( MS chiama questo "Health Monitoring"), che significa che il web app continuerà a funzionare. Gli utenti che non hanno una richiesta di essere servito dal processo in mancanza al momento del fallimento, saranno a conoscenza di tutto questo.

  

L'errore HTTP 500 che un cliente riceve in questo caso sarà indistinguibile da un errore 500 che il cliente riceve, nel caso di un errore di applicazione, diciamo un'eccezione non rilevata nel codice dell'applicazione ASPNET.

Per le richieste che erano nel processo di fallire, non c'è modo di recuperarli. Essi si tradurrà in 500 errori al browser. A 503 Server risultati occupato da IIS rifiutando attivamente il collegamento a causa di un valore soglia del numero di connessioni. A 503 non deriva da un errore dell'applicazione, quindi non si deve aspettare di vedere 503 per le transazioni in volo nello scenario out-of-memory-e-crash. In un sistema molto carico, è possibile vedere 503 di come il processo-crash-e-restart accade, come effetto secondario. Se questo è davvero quello che stai vedendo, è necessario un più ampio margine di sicurezza per gestire il carico in condizione di single-errore.

La richiesta Coda

IIS ha un approccio hand-off per le richieste . Arrivano sul livello di rete (Http.sys), essi sono posti in una coda, di essere prelevati da un processo di lavoro. Eventuali richieste in attesa nella coda IIS per essere gestite da un WP continuerà inalterato, anche se potrebbero vedere un leggero aumento temporaneo della latenza (tempo di servizio) a causa di conflitto di risorse, dal momento che un unico processo in meno è in esecuzione sul server. Tempo di attesa in questa coda è generalmente molto molto breve, in un sistema che è configurato correttamente.

E 'quando questa coda è piena che si vedrà 503 errori.

riavvio automatico del W3WP.exe

IIS ha un riavvio automatico (o "tata") struttura, attraverso il quale si riavvia i processi di lavoro dopo aver superato le soglie configurate , come ad esempio la dimensione della memoria, il numero di richieste, o il tempo-di-corsa. In tutti questi casi, IIS disattivare gradualmente e riavviare i processi di lavoro quando viene raggiunta la soglia configurata. Questi riavvio pro-attivi normalmente non provocano alcuna interruzione delle richieste. Quando IIS decide che un riavvio di un processo di lavoro è necessario, impedisce qualsiasi nuova richiesta di arrivare a quel WP to-be-inoperanti. richieste esistenti vengono drenati : tutte le transazioni in volo in quel WP sono autorizzati a completare normalmente. Quando tutte le richieste nel WP completo, allora il WP muore e IIS inizia uno nuovo al suo posto. Questo nuovo processo poi inizia immediatamente raccogliendo nuove richieste dalla coda spedizione. Questo è tutto trasparente per gli utenti o browser.

Lo dico normalmente , perché è possibile che la pro operaiocess è diventato veramente male al tempo stesso è stata raggiunta la soglia. In tal caso il w3wp.exe potrebbe non rispondere a IIS all'interno di la configurato "quiesce" timeout , e quindi IIS deve infine uccidere il processo, anche se non ha riferito che tutte le sue richieste in volo hanno completato. Questo dovrebbe essere estremamente raro, in quanto si tratta di due distinte condizioni eccezionali, ma succede. In questo caso, le richieste in-volo ancora una volta, ottenere 500 errori.

Web garden

Inoltre - IIS consente a più processi di lavoro su un unico server. chiamate MS questo un "web giardino", un gioco di parole da "web farm". Se avete un giardino web istituito, quindi le operazioni di essere servito da istanze w3wp.exe diverse dalla mancanza di uno, continuerà inalterato. "Insensibile" presuppone, però, che l'errore out-of-memoria è localizzato, e non un problema a livello di sistema.

Bottom Line

La linea di fondo è che non v'è alcun sostituto per il test proprio. Le opzioni di configurazione sono piuttosto ampio - da soglie di riavvio ai giardini web e così via. Anche le modalità di guasto tendono ad essere piuttosto complesso e variegato, che si tratti di memoria, timeout, troppo occupato, e così via. Avrai voglia di capire che cosa aspettarsi.

ps: questo Q & A appartiene davvero in serverfault.com !!

---

riferimenti:
http: // blog. iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx

Answer 2

Un nuovo thread di lavoro verrà avviato e l'utente non saprebbe nulla è accaduto. A meno che non si spegne completamente via rapida falliscono ( http: // technet.microsoft.com/en-us/library/cc779127(WS.10).aspx )

Answer 3

Se si tratta di un fuori situazione di memoria, IIS di solito solo ricicla il pool di app.

Answer 4

Come dicono le altre risposte, nella maggior parte dei casi, tutto solo riavvio, e la maggior parte degli utenti che non hanno avuto una richiesta in sospeso, al momento saranno non notare molto di più di un ritardo.

Tuttavia, se l'applicazione utilizza le variabili di sessione con In-Proc lo stato della sessione, tutte le variabili di sessione per tutti gli utenti saranno persi al riavvio del pool di app. Questo può o non può avere un effetto negativo sugli utenti, a seconda di quello che stai facendo con le variabili di sessione. È possibile evitare questo passando allo stoccaggio sessione StateServer o SQL Server.