Escalabilidade vertical com vários pools de aplicativos

Question

Estamos executando um aplicativo ASP.Net que também está chamando alguns objetos COM herdados. Estamos nos deparando com um problema em que, com o aumento do número de usuários, o objeto COM está criando um gargalo, pois está executando no mesmo thread / processo que o pool de aplicativos.

Atualmente, temos um balanceador de carga de hardware e usamos sessões fixas para equilibrar a carga entre dois servidores. Infelizmente isso não parece ser suficiente. Fizemos alguns testes usando vários pools de aplicativos, cada um executando o mesmo aplicativo, e o desempenho parece melhorar significativamente.

Eu tenho algumas perguntas.

1. É aconselhável adicionar vários pools de aplicativos, todos apontando para os mesmos arquivos físicos?
2. Ainda usaríamos o balanceador de carga de hardware. Todas as solicitações que chegam ao app.xxxxxx.com são redirecionadas para, por exemplo, app1.xxxxxx.com, app2.xxxxxx.com, app3.xxxxxx.com, app4.xxxxxx.com. Cada um sendo um pool de aplicativos no mesmo servidor. Isso é uma prática comum?
3. O servidor tem 16 núcleos. Definir a afinidade do processador faz sentido, dedicar cada pool de aplicativos a ser executado em 4 núcleos?
4. Estamos presos usando sessões InProc. Por causa disso, não estamos nem considerando o uso do Web Garden. Além disso, pelo que eu li, o Web Garden é mais para melhorar a disponibilidade do que o desempenho.

Eu sou um desenvolvedor por profissão e foi minha responsabilidade pesquisar / executar essas tarefas e muito disso foi um processo de aprendizado para mim.

Obrigado

    

Answer 1

Você tem uma situação bastante única em que o COM se torna um gargalo para que você não possa simplesmente expandir. Idealmente, melhorar o desempenho com os objetos COM ou substituí-los por código gerenciado aumentaria ainda mais, mas você está no caminho certo para uma solução alternativa de desempenho de COM.

1. O IIS é capaz de lidar com centenas de pools de aplicativos, portanto, isso não é um problema. Ele adicionará alguns MB de RAM a cada pool de aplicativos, mas sem sobrecarga de desempenho extra.

2. Claro. Por pool de aplicativos, presumo que cada um seja um site completo com seu próprio pool de aplicativos. Tudo bem.

3. Se não for necessário, não altere a afinidade do processador, pois isso significa que você precisa mantê-lo e alterá-lo para sempre. Se a utilização da CPU é bastante plana, então você é bom com os padrões. Se você tiver outros aplicativos no servidor ou se houver um grande desequilíbrio, considere a afinidade do processador. O IIS faz um bom trabalho ao utilizá-los na maioria das vezes, por isso é melhor deixar o trabalho pesado se possível.

4. Como você diz, as sessões fixas lidam com isso, então você é bom. Web gardens podem ter resolvido seus problemas de COM se você não tivesse o estado de sessão InProc com o qual se preocupar. Como um lado, você pode considerar o uso do servidor de estado do ASP.NET. Faça com que cada servidor use o servidor de estado local e faça com que o balanceador de carga use sessões fixas com uma ligação por servidor. Isso resolveria o estado da sessão (contanto que tudo fosse serializado, o que geralmente acontece) e permitirá que você jogue facilmente com as configurações do jardim da Web sem ter que mexer com o balanceador de carga.