O que acontecerá com outros usuários se o processo de trabalho do .NET falhar?

Question

Meu conhecimento de como os processos são tratados pelo processo de trabalho do ASP.Net é terrivelmente inadequado.Espero que alguns dos especialistas possam me informar.

Se eu travar o processo de trabalho com uma System.OutOfMemoryException, qual seria a experiência do usuário para outros usuários que estavam sendo atendidos pelo mesmo processo?Eles receberiam uma tela em branco?Erro 503?

Vou tentar testar esse cenário com outras pessoas em nosso laboratório, mas pensei em divulgar isso.Vou atualizar com nossos resultados.

ATUALIZAR:Nossos resultados variaram.Se induzissemos artificialmente uma exceção OOM (por exemplo, carregando PDFs cada vez maiores na memória), outros threads atendidos por esse processo de trabalho seriam "travados" temporariamente e depois concluídos, enquanto outros aparentemente nunca retornariam.Obrigado por suas respostas.

Answer 1

W3wp.exe é o processo

O IIS executa todos os aplicativos da Web em um processo de trabalhador genérico - w3wp.exe. Se você escreve no ASP.NET, ou ISAPI ou alguma outra estrutura, o processo que serve a solicitação da Web é w3wp.exe. No caso ASP.NET, o W3WP.EXE carrega as DLLs compiladas do ASP.NET JIT e atende as solicitações através deles. Em outros casos, funciona de maneira diferente. Mas o ponto principal é que w3wp.exe é o processo. Este modelo começou no iIS6.0 e continua no iIS7.0.

Falhas inesperadas

Se o w3wp.exe falhar inesperadamente, por qualquer motivo, todas as transações que estava lidando provavelmente receberão 500 erros (erro do servidor). O IIS iniciará um novo processo de trabalhador em seu lugar (A MS chama isso de "monitoramento da saúde"), o que significa que o aplicativo da web continuará sendo executado. Os usuários que não tiveram uma solicitação sendo atendida pelo processo de falha no momento da falha, não terão conhecimento disso.

O erro HTTP 500 que um cliente recebe neste caso será indistinguível de um erro 500 que o cliente recebe no caso de um erro de aplicativo, digamos uma exceção não capturada no seu código de aplicativo ASPNET.

Para os pedidos que estavam em processo de falha, não há como recuperá -los. Eles resultarão em 500 erros no navegador. Um servidor 503 está ocupado resulta do IIS recusando ativamente a conexão devido a um limite sobre o número de conexões. Um 503 não resulta de uma falha no aplicativo; portanto, você não deve esperar ver 503 para transações em voo no cenário fora da memória e cruz. Em um sistema fortemente carregado, você pode ver os 503 à medida que o processo de travas de processo e restauração acontece, como um efeito secundário. Se é isso que você está vendo, você precisa de uma margem maior de segurança para lidar com a carga na condição de erro único.

A fila de solicitação

IIS tem uma abordagem de transferência para solicitações. À medida que chegam à camada de rede (http.sys), eles são colocados em uma fila, para serem apanhados por um processo de trabalhador. Quaisquer solicitações que aguardam na fila do IIS a serem tratadas por um WP continuarão não afetadas, embora possam ver um pequeno aumento temporário na latência (tempo de serviço) devido à contenção de recursos, uma vez que menos um processo está em execução no servidor. O tempo de espera nesta fila geralmente é muito curto, em um sistema configurado corretamente.

É quando esta fila estiver cheia, você verá 503 erros.

Reinicialização automática de w3wp.exe

O IIS tem uma instalação automática (ou "babá"), através da qual Ele reinicia os processos dos trabalhadores depois que eles excederam os limiares configurados, como tamanho de memória, número de solicitações ou tempo de execução. Em todos esses casos, o IIS fará e reiniciará os processos dos trabalhadores quando o limite configurado for atingido. Esses reinicializações pró-ativas normalmente Não resulte em nenhuma interrupção das solicitações. Quando o IIS decide que é necessária uma reinicialização de um processo de trabalhador, ele impede que novas solicitações cheguem a esse WP preenchido. Os pedidos existentes são drenados: Quaisquer transações a bordo, pois o WP pode concluir normalmente. Quando todos os pedidos no WP completaram, o WP morre e o IIS inicia um novo em seu lugar. Esse novo processo começa imediatamente a obter novas solicitações da fila de expedição. Tudo isso é transparente para usuários ou navegadores.

eu digo normalmente Porque é possível que o processo do trabalhador tenha ficado verdadeiramente doente ao mesmo tempo em que o limiar foi alcançado. Nesse caso, o w3wp.exe pode não responder ao IIS dentro o tempo limite "quiesce" configurado, e, portanto, o IIS deve eventualmente matar o processo, mesmo que não tenha relatado que todas as suas solicitações de bordo foram concluídas. Isso deve ser extremamente raro, porque são duas condições excepcionais distintas, mas acontece. Nesse caso, as solicitações de voo serão mais uma vez, receberão 500 erros.

Gardens da web

Além disso - o IIS permite vários processos trabalhadores em um único servidor. MS chama isso de "jardim da web", uma peça de palavras de "Web Farm". Se você tiver uma configuração de jardim da web, as transações sendo atendidas por instâncias w3wp.exe que não sejam a falha, continuarão não afetadas. "Não afetado" presume que o erro fora da memória está localizado, e não um problema em todo o sistema.

Resumindo

O ponto principal é que não há substituto para seus próprios testes. As opções de configuração são bastante amplas - desde os limites de reinicialização até os jardins da web e assim por diante. Além disso, os modos de falha tendem a ser bastante complexos e variados, seja memória, tempo limite, muito ocupado e assim por diante. Você vai querer entender o que esperar.

PS: Esta sessão de perguntas e respostas realmente pertence ao Serverfault.com !!

---

referências:
http://blogs.iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx

Answer 2

Um novo tópico de trabalhador será iniciado e o usuário não saberia que nada aconteceu. A menos que seja desligado completamente via falha rápida (http://technet.microsoft.com/en-us/library/cc779127(ws.10).aspx)

Answer 3

Se for uma situação fora da memória, geralmente apenas recicla o pool de aplicativos.

Answer 4

Como dizem as outras respostas, na maioria dos casos tudo simplesmente reinicia, e a maioria dos usuários que não tinham uma solicitação pendente naquele momento não perceberão muito mais do que um atraso.

No entanto, se seu aplicativo usar variáveis ​​de sessão com estado de sessão In-Proc, todas as variáveis ​​de sessão de todos os usuários serão perdidas quando o pool de aplicativos for reiniciado.Isso pode ou não ter um efeito negativo sobre os usuários, dependendo do que você está fazendo com as variáveis ​​de sessão.Você pode evitar isso mudando para o armazenamento de sessão StateServer ou SQL Server.