Estamos no processo de implantação de um novo aplicativo em seu ambiente ativo.
Os servidores de aplicativos estão executando um aplicativo .NET hospedado no IIS que usa EntityFramework e faz inúmeras chamadas para um aplicativo não .NET COM+.
Conseguimos afetar o desempenho do código .NET puro modificando o número máximo de processos de trabalho dentro do pool de aplicativos do IIS, mas minha pergunta é como o número de processos de trabalho está relacionado ao tamanho do pool dos pools de aplicativos nos serviços de componentes ? Coisas como:
- deveríamos buscar uma relação de 1 para 1 entre esses 2 valores?
- devemos evitar vários threads de trabalho?
Qualquer insight recebido com gratidão ...
Responder1
O número de processos de trabalho nos dois pools não está diretamente relacionado. O que você precisa estabelecer é o tempo de permanência em cada pool. Portanto, se os trabalhadores do IIS estiverem ocupados e apenas uma pequena proporção do tempo total for gasto no aplicativo COM, os threads COM provavelmente não causarão gargalos no desempenho.
Tente medir o número de threads ativos em uma situação de estresse para determinar como controlar os tamanhos dos pools individuais.
Considere também que os processos de trabalho do IIS também são reciclados com base em critérios diferentes da utilização do processador. Isto pode afetar substancialmente sua capacidade de compartilhar dados entre invocações e pode subverter tentativas de afetar fortemente o desempenho direto.
Seria melhor reduzir o custo de fazer a ponte .NET para COM, considerando um wrapper COM fino que pode agregar várias solicitações de uma única consulta .NET. Isso também pode ter o efeito colateral de consolidar vários métodos COM em um único thread do pool.