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

Question

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

1. Parece aconselhável ter um pool de aplicativos por site. Existem algumas ressalvas a esta abordagem? Um pool de aplicativos consumirá 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 baixa demais 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 privada e virtual?

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

Answer 1

1) It seems advisable to have an application pool per website. Are there any caveats to this approach? Can one application pool, for example, hog all the CPU, Memory, Etc...?

Esta é uma abordagem muito boa; não há boas razões pelas quais eu possa 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 mudar a forma como os aplicativos são agrupados não afetará muito isso.

2) When should you allow multiple worker processes in an application pool. When should you not?

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

3) Can private memory limit be used to prevent one application pool from interfering with another? Will setting it too low cause valid requests to recycle the application pool without getting a valid response?

a) Teoricamente

b) Sim, configurá-lo para 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) What is the difference between private and virtual memory limits?

Isso é muito complicado, aqui está uma postagem rápida que eu acho que pode ajudar: link

5) Are there compelling reasons NOT to run one application pool per site?

Mais uma vez, apenas o motivo pelo qual consigo pensar é que, se houver algum tipo de "recurso compartilhado" que os diversos aplicativos precisam, você poderá executá-los no mesmo processo.

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

**** ATUALIZAÇÃO ****

Em relação à sua solicitação de informações adicionais sobre o segundo lugar, você não deve fazer isso, a menos que tenha uma necessidade específica para isso. Mesmo com ações do servidor que demoram muito tempo, as solicitações são fornecidas usando vários encadeamentos e você desejaria usar "Solicitações Assíncronas" para manipular tarefas de execução longa (o que libera um encadeamento de encadeamento de encadeamentos para tratar de outras solicitações). Realisticamente, não consigo pensar em nenhum bom motivo para permitir vários processos para um único pool.

Uma vez que você começa a falar sobre múltiplos processos, você pode se deparar com coisas como: perder estado da sessão porque uma sessão está ativa no processo 1, mas a solicitação está sendo processada pelo processo 2. Ou pior ainda, como fazer alguma comunicação entre processos, que é uma verdadeira dor.

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

    

Answer 2

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

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 isso é mais um problema 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 um vazamento de memória consumir grandes quantidades de memória.

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