Práticas recomendadas para o pool de aplicativos do IIS 7.x

Estamos prestes a implantar vários sites em alguns novos servidores. Tenho as seguintes perguntas sobre pools de aplicativos:

1. Parece aconselhável ter um pool de aplicativos por site. Existem advertências para essa abordagem? Um pool de aplicativos monopolizará toda a CPU, Memória, Etc ...?

2. Quando você deve permitir vários processos de trabalho em um pool de aplicativos? Quando você não deveria?

3. O limite de memória privada pode ser usado para impedir que um pool de aplicativos interfira em outro? A configuração muito baixa fará com que solicitações válidas reciclem o pool de aplicativos sem obter uma resposta válida?

4. Qual é a diferença entre os limites de memória virtual e privada?

5. Existem razões convincentes para NÃO executar um pool de aplicativos por site?

1) Parece recomendável ter um pool de aplicativos por site. Existem advertências para essa abordagem? Um pool de aplicativos, por exemplo, pode monopolizar toda a CPU, Memória, Etc ...?

Essa é uma abordagem muito boa; não existem boas razões para pensar em ter "sites" (aplicativos) diferentes compartilhando o mesmo pool. A menos que eles precisem compartilhar um único recurso de algum tipo. Uma aplicação poderia teoricamente consumir muita CPU ou memória, mas alterar a forma como as aplicações são agrupadas não afetará tanto.

2) Quando você deve permitir vários processos de trabalho em um pool de aplicativos. Quando você não deveria?

É melhor deixar sozinho, usando as configurações padrão. A menos que você realmente saiba o que está fazendo, isso poderá afetar negativamente seu site / aplicativo.

3) O limite de memória privada pode ser usado para impedir que um pool de aplicativos interfira em outro? A configuração muito baixa fará com que solicitações válidas reciclem o pool de aplicativos sem obter uma resposta válida?

a) Teoricamente

b) Sim, defini-lo para mais baixo pode ter efeitos negativos. Novamente, a menos que você tenha necessidades específicas e saiba o que está fazendo, deixe-as em paz.

4) Qual é a diferença entre os limites de memória privada e virtual?

Isso é muito complicado, aqui está uma rápida publicação que achei que poderia ajudar: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/

5) Existem razões convincentes para NÃO executar um pool de aplicativos por site?

Novamente, a única razão pela qual consigo pensar é que, se houver algum tipo de "recurso compartilhado" de vários aplicativos, você poderá executá-los no mesmo processo.

Para aplicativos e sites de uso geral, o IIS está muito bem configurado com seus valores padrão.

****ATUALIZAR****

Em relação ao seu pedido de informações adicionais sobre o item 2, você não deve fazer isso, a menos que tenha uma necessidade específica de fazê-lo. Mesmo com ações do servidor que demoram muito tempo, as solicitações são atendidas usando vários encadeamentos e você deseja usar "Solicitações assíncronas" para lidar com tarefas de longa execução (que libera um encadeamento do conjunto de encadeamentos para manipular outras solicitações). Realisticamente, não consigo pensar em nenhum bom motivo para permitir vários processos para um único pool.

Depois que você começa a falar sobre vários processos, você potencialmente encontra coisas como: perdendo o estado da sessão porque uma sessão está ativa no processo 1, mas a solicitação está sendo tratada pelo processo 2. Ou, pior ainda, você precisa descobrir como faça alguma comunicação entre processos, o que é uma verdadeira dor.

Não importa o que você venha com relação a uma razão para vários processos, eu estaria disposto a apostar que há uma maneira melhor de lidar com isso (em vez de iniciar outro processo).

Eu sempre configuro um pool de aplicativos dedicado para um site. Os cenários de hospedagem de sites de baixo custo são onde fazer sentido um grande número de sites por pool de aplicativos.

Os limites de memória são realmente apenas limites de segurança primitivos para impedir que um site consuma todos os recursos do sistema. Observe que esse é mais um problema em potencial no Windows 2008 R2 x64 do que no IIS 6.0 x86, porque os aplicativos x86 tinham um limite de memória natural de 2 GB. É muito mais fácil no IIS 7.5 para um aplicativo com vazamento de memória consumir grandes quantidades de memória.

Também não sou muito fã de pools de aplicativos de reciclagem. Se eu tenho um pool de aplicativos e sou o único aplicativo em execução, se não houver nada de errado com nosso código, provavelmente não haverá necessidade de reciclar o pool de aplicativos. E se houver um defeito no aplicativo, a ação apropriada final seria corrigir o código.