Por que o IIS usa como padrão a reciclagem do pool de aplicativos a cada 1740 minutos?

Por que o IIS padrão para reciclar o pool de aplicativos após um determinado tempo? Existe algum motivo específico que talvez a maioria dos aplicativos da Web não esteja gerenciando a memória com prudência? Dado que você está gerenciando a memória do aplicativo corretamente, é seguro prosseguir e desativá-lo? Quais são algumas desvantagens potenciais, além de benefícios de desativar ou manter a reciclagem?

Sim, o motivo pelo qual o padrão é uma vez por dia é a preocupação de que o aplicativo Web possa ter um vazamento de memória. A maior desvantagem da reciclagem frequente de pools de aplicativos do IIS é que ele causará leitura do web.config, carregamento de montagem e uma recompilação de páginas asp.net e (se você não acredita em pré-compilá-las) atrasos de código. Esse é um processo bastante pesado e não ocorre até a próxima solicitação de página após a reciclagem do pool de aplicativos, diminuindo bastante a velocidade dessa solicitação específica. Agora, o IIS7 possui um módulo que você pode baixar chamado Application Warm Up para ajudar a "lidar" com esse problema.

Pessoalmente, prefiro usar valores máximos baseados em memória, juntamente com o logon no início do aplicativo, em vez de agendar minha reciclagem. Isso permite que eu assuma que meu aplicativo não tem vazamento de memória e que se prove errado quando o pool de aplicativos é reciclado.

1740 minutos são 29 horas:

Na época em que o IIS 6 estava sendo desenvolvido - que é a versão que introduziu os pools de aplicativos - era necessário definir um padrão para o Intervalo de tempo regular quando os pools de aplicativos são reciclados automaticamente.

Wade sugeriu 29 horas pela simples razão de que é o menor número primo entre 24 . Ele queria um padrão escalonado e não repetitivo que não ocorra com mais frequência do que uma vez por dia. Nas palavras de Wade: "você não consegue um padrão de ressonância". O padrão é 1740 minutos (29 horas) desde então!

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

O recurso é uma reserva dos dias clássicos do ASP, quando tudo vazava memória e você precisava fazer isso. A maioria das pessoas teve um reinício programado no servidor da noite para o dia. O IIS6 automatizou isso com desligamentos do pool de aplicativos a cada 1740 minutos (ou se o aplicativo estiver inativo por 20 minutos). O IIS7 continuou a tradição.

O conselho que recebi da Microsoft naquela época era que isso era desnecessário, a menos que você tivesse um aplicativo herdado com um vazamento de memória conhecido. Portanto, se você estivesse executando um código puramente gerenciado, estaria bem.

Desligue-o e monitore os pools de aplicativos. Os aplicativos corporativos mais complexos usam muito código legado e grande parte desse código é meio que vazando. Portanto, para a maioria das instalações, reiniciar o pool de aplicativos ocasionalmente não é uma má idéia.

Existem outras opções, como monitorar o tempo de inatividade, que podem ser uma solução melhor para sua situação.

A rotação de um pool de aplicativos pode levar algum tempo e tornar o aplicativo menos responsivo, mantendo-os atualizados para ajudar no desempenho.

De fato, isso é puramente para limpar os recursos vazados que (podem) estar presentes. Os 1740 minutos também não são o único evento desencadeador. Isso também ocorre após um número máximo específico de solicitações ou após exceder uma quantidade específica de memória do processo do operador. Está muito bem documentado na biblioteca do MSDN. Infelizmente, essa política quebra coisas como estado da sessão e estática, como singletons. Seu aplicativo precisará ser robusto o suficiente para autenticar novamente os usuários e / ou reinicializar singletons conforme necessário, para evitar perturbar a experiência do usuário. Isso nos forçou a gerenciar sessões autenticadas no banco de dados, e não na sessão do ASP.NET. Caso contrário, nossos usuários voltarão à nossa página de login sempre que o servidor for reciclado devido a um desses gatilhos.