Alguém pode explicar as diferenças, no IIS, entre pools de aplicativos, processos de trabalho e domínios de aplicativo? Além disso, como eles funcionam juntos? Eu li alguns artigos, mas ainda é um pouco confuso.
Respostas:
Tento dizê-los com outras palavras.
Em um servidor, você pode ter muitos sites asp.net que funcionam juntos. Cada site é um domínio de aplicativo .
Você deve atribuir a cada um deles um pool de aplicativos . Muitos domínios de aplicativos (sites) podem ter o mesmo pool de aplicativos e, como têm o mesmo pool, são executados nos mesmos processos e na mesma conta - e têm as mesmas configurações do pool. Se este pool for reiniciado, todos os sites sob esse pool serão reiniciados.
Agora, cada pool pode ter um ou mais processos de trabalho . Cada processo de trabalho é um programa diferente que executa seu site, tem suas próprias variáveis estáticas, eles iniciam chamadas de parada diferentes, etc. Processos de trabalho diferentes não se comunicam juntos, e a única maneira de trocar dados é de arquivos comuns ou de um banco de dados comum. Se você tem mais de um processo de trabalho e um deles faz cálculos demorados, o outro pode cuidar das chamadas pela internet e mostrar o conteúdo.
Quando você atribui muitos processos de trabalho a um único pool, então você cria o web garden chamado e seu site pode ser executado em mais de um computador se um computador for uma máquina de processamento.
Cada processo de trabalho pode ter muitos threads.
Como o processo de trabalho mais afeta você:
Quando você tem um processo de trabalho, tudo é mais simples, em seu aplicativo todas as variáveis estáticas são as mesmas e você usa o lockpara sincronizá-las.
Quando você atribui mais de um processo de trabalho , você ainda continua a usar o lockpara variáveis estáticas, as variáveis estáticas não são diferentes entre as muitas execuções do seu site e se você tiver algum recurso comum (por exemplo, a criação de uma miniatura no disco) então você precisa sincronizar seu processo de trabalho com Mutex.
Mais uma nota. Parece que quando você cria mais processos de trabalho , pode ter carregamentos de página assíncronos mais suaves. Há um pequeno problema com o manipulador de sessão do asp.net que é bloquear todo o processo para o carregamento de uma página - isso é bom e não é bom dependendo se você conhece e trata disso - ou altere-o.
Então, vamos falar sobre um site apenas com muitos processos de trabalho. Aqui você enfrenta o problema com o qual precisa sincronizar sua mudança de recurso comum Mutex. Mas as páginas / manipuladores que usam a sessão não são assíncronos porque a sessão os bloqueia. Isso é bom para começar porque você evita fazer essa sincronização de muitos pontos você mesmo.
Algumas perguntas sobre este tópico:
Aplicativo da Web bloqueado durante o processamento de outro aplicativo da Web no compartilhamento da mesma sessão. As
chamadas jQuery Ajax para serviço da Web parecem ser síncronas.
Servidor ASP.NET não processa páginas de forma assíncrona
Substituindo inteiramente a sessão do ASP.Net
Agora, este bloqueio de sessão não afeta sites diferentes.
Entre diferentes sites, o processo mais trabalhado pode ajudar a não um site bloquear o outro com processo de longa execução.
Também entre sites diferentes, mais pools também podem ajudar, porque cada pool tem pelo menos um processo trabalhado, mas lembre-se e veja por você mesmo usando o explorador de processos, cada processo de trabalho ocupa mais memória do seu computador e um grande servidor com 16G de memória e um servidor SQL não pode ter muitos processos de trabalho diferentes - por exemplo, em um servidor com 100 sites compartilhados, você não pode ter 100 pools diferentes.
O significado para os desenvolvedores ASP.NET: para tornar seu site escalonável, não use sessão in-proc e não use bloqueio de variável de classe estática para sincronização.
Sim, embora nem todo aplicativo seja um site. Você pode ter um aplicativo aninhado em um site.
Sim, cada aplicativo deve ter um processo de trabalho (pool de aplicativos), embora um pool de aplicativos possa servir a vários aplicativos. Um único aplicativo da web pode ser distribuído (web garden / farm), o que significa que será executado em vários processos.
Cada processo será executado em seu próprio domínio de aplicativo (cada pool de aplicativos é um domínio de aplicativo separado).
Do MSDN.
Um aplicativo é um agrupamento de conteúdo no nível raiz de um site ou um agrupamento de conteúdo em uma pasta separada no diretório raiz do site.
Um pool de aplicativos define um grupo de um ou mais processos de trabalho, definidos com configurações comuns que atendem a solicitações para um ou mais aplicativos atribuídos a esse pool de aplicativos. Como os pools de aplicativos permitem que um conjunto de aplicativos da Web compartilhe um ou mais processos de trabalho configurados de forma semelhante, eles fornecem uma maneira conveniente de isolar um conjunto de aplicativos da Web de outros aplicativos da Web no computador servidor. Os limites do processo separam cada processo do trabalhador; portanto, os problemas de aplicativo em um pool de aplicativos não afetam sites ou aplicativos em outros pools de aplicativos. Os pools de aplicativos aumentam significativamente a confiabilidade e a capacidade de gerenciamento de sua infraestrutura da web.
Do link de origem: -http: //weblogs.asp.net/owscott/archive/2007/09/02/application-vs-appdomain.aspx
Um aplicativo é um termo do IIS, mas é usado pelo ASP.NET. Basicamente, ele cria uma caixa de areia, ou um conjunto de limites para separar diferentes sites, ou partes de sites, dos outros.
Um AppDomain é um termo .NET. (No IIS7, AppDomains desempenham um papel maior dentro do IIS, mas na maior parte é um termo ASP.NET)
O processo de trabalho é usado para processar a solicitação do aplicativo da web.