Como funciona uma aplicação ASP.Net no IIS 6.0?
Por: Marcelo Menezes Neves
[Entre em contato com o autor ]
Especialista em desenvolvimento e Microsoft Certified Professional com mais de 10 anos de experiência.
Atualmente arquiteta e desenvolve web e mobile applications utilizando tecnologia Microsoft.
Fonte: http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=878
Como funciona uma aplicação ASP.Net no IIS 6.0?
Publicado em: 12/12/2005
Já aconteceu de você instalar uma aplicação ASP.Net no IIS e ela não funcionar? Já aconteceu de você chamar uma página de sua aplicação e o IIS responder com uma dúzia de mensagens esquisitas? Pois bem, antes de tomar qualquer ação você precisa, ao menos, entender o que se passa com sua aplicação, você precisa entender como ela funciona quando está hospedada no IIS. E é sobre isso que iremos falar: como funciona uma aplicação ASP.Net no IIS 6.0.
Visão Geral
Antes de mais nada é bom que você saiba que o projeto original da Microsoft era desenvolver o ASP.Net para rodar com o IIS 6. Mas com o tempo, a Microsoft percebeu que o lançamento do IIS 6 não coincidiria com o lançamento do Visual Studio .Net 2002, daí ela decidiu lançar o ASP.Net antes do IIS 6 e, suportar o ASP.Net no IIS 5. Isso nos mostra o porquê do ASP.Net se comportar diferente no IIS 6.0 e no IIS 5.0. Neste artigo iremos tratar somente do comportamento de uma aplicação ASP.Net com IIS 6.0. Pra começarmos a entender como funciona o IIS, podemos dividí-lo da seguinte maneira:
- HTTP Protocol Stack (HTTP.sys)
- Application Pool
- Worker process
- Serviço WWW
- INETINFO.exe
- Meta dados do IIS
Estes são os principais componentes do IIS do ponto de vista de uma aplicação ASP.Net. Mas, antes de entendermos a função de cada componente você antes precisa entender o seguinte: o IIS 6.0 trabalha com 2 tipos de isolamento de aplicação.
Figura 1 - Application Pools
Mas o que é isolamento de aplicação? Significa isolarmos uma aplicação das demais, de forma que o funcionamento de uma aplicação não interfira no funcionamento de outras aplicações num mesmo servidor e, preferencialmente, cada aplicação possua seu próprio espaço de memória. Mas será que essa preocupação é válida? Sim e como! Pense num provedor que hospeda dezenas de aplicações num mesmo servidor IIS, onde cada aplicação compartilha os mesmos recursos. Será que dá para confiar que todos os desenvolvedores construíram suas aplicações de forma a utilizarem os recursos do sistema de forma eficiente? É claro que não! Por isso, a preocupação é mais do que válida. Para isolar uma aplicação e, garantir que nenhuma outra irá interferir no seu funcionamento, pode-se optar por instalar cada aplicação num diferente servidor IIS, o que chamamos de isolamento físico. Mas já pensou no custo desta solução? Inviável! Então para contornar esse problema, ou podemos dizer, esta necessidade, o IIS oferece um recurso, que até mesmo já existia em outros servidores web, e que se chama Application Pool, conforme pode ser visto na figura 1. Este recurso garante o isolamento lógico de uma aplicação, ou seja, várias aplicações podem ser instaladas no mesmo servidor onde cada uma delas possui o seu próprio espaço de memória.
Agora, entendido o que é isolamento de aplicação, veja abaixo os dois modelos de isolamento disponíveis no IIS 6.0:
- Worker process isolation mode (default)
- IIS 5.0 isolation mode
Qual a diferença? Embora nos dois modelos o HTTP.sys seja o HTTP listener, ou seja, o componente do IIS que recebe todos os requests, os modelos diferem na forma em que o IIS controla o isolamento da aplicação. No worker process isolation mode pode-se agrupar aplicações ASP.Net em application pools, que podem ser configurados, entre outras coisas, para reciclar de 12 horas em 12 horas todos as aplicações (sites e virtual roots) que fazem parte deste application pool, fazendo com que o worker process seja eliminado da memória (Veja a figura 2). Outra vantagem é que este modo de isolamento sofreu grandes modificações na versão 6.0 e, portanto, é superior em performance do que nas versões anteriores. No IIS 5.0 isolation mode o isolamento da aplicação é feito como na versão 5.0 do IIS:
- Low isolation (in-process)
- Medium isolation (pooled out-of-process)
- High isolation (out-of-process)
Figura 2 - Propriedades do application pool default
Uma das formas de conferir se o IIS 6.0 está rodando em Worker process isolation mode é examinar os processos que estão rodando na máquina onde roda o IIS, pode-se utilizar para isso a Task Manager, e então você conseguirá visualizar um ou mais processos W3wp.exe. Não se recomenda utilizar o IIS 5.0 isolation mode. O uso do IIS 5.0 isolation mode só é justificado quando a aplicação:
- Depende do worker process INETINFO.EXE
- Precisa rodar no ambiente da DLLHOST.EXE
Usando o Worker process isolation mode, além de ser o modo default, é o que oferece maior performance e permite que você aproveite todos os benefícios do IIS 6.0. Para visualizar o isolation mode corrente basta visualizar a propriedade IIs5IsolationModeEnabled, do metadados do IIS.
Componentes do IIS
Vamos agora entender a função de cada componente:
HTTP.sys - Responsável por receber os requests HTTP e encaminhá-los para o worker process da aplicação através da fila de requests. O HTTP.sys mantém um cache interno que otimiza o processamento dos requests. Requests que estão cacheados são atendidos pelo próprio HTTP.sys, não havendo a necessidade de encaminhá-los para o worker process.
Application Pool - Na prática, nada mais é que uma fila de requests. O HTTP.sys quando recebe o request verifica qual a fila de requests que atende a aplicação corrente e daí envia o request por essa fila para o worker process. Seu uso é de extrema importância, pois se definirmos uma application pool por aplicação, o mal comportamento de uma aplicação não afetará o desempenho das demais aplicações instaladas no mesmo servidor IIS. Além disso, pode-se configurar para cada application pool o comportamento do serviço WWW e o comportamento do worker process, entre outras coisas.
Worker Process - Componente responsável pelo processamento do request, ou seja, executa a página solicitada, faz todo o processamento necessário, e devolve o resultado para o HTTP.sys. Um application pool pode ter um ou mais worker processes. O arquivo executável responsável por suportar o worker process é o W3wp.exe quando o IIS roda em Worker Process isolation mode, ou inetinfo.exe, quando o IIS roda em IIS5 isolation mode.
Serviço WWW - Serviço responsável pelo gerenciamento do worker process. É ele quem verifica se existe um worker process para a aplicação, senão existir ele trata de criar um worker process. Ele também verifica se o worker process está operacional. Caso um worker process "trave", devido ao mal comportamento da aplicação, o serviço WWW providencia a criação de um novo worker process e trata de eliminar o worker process "travado". Quando o servidor IIS é iniciado pela primeira vez o serviço WWW consulta o IIS Metabase e inicializa o HTTP.sys.
Inetinfo.exe - Quando o IIS está configurado para rodar em Worker Process isolation mode o componente Inetinfo.exe carrega o IIS Metabase e disponibiliza o mesmo para as aplicações. Este componente pode ser visto, através da task manager, como o arquivo inetinfo.exe. O inetinfo.exe também é responsável por hospedar os serviços FTP, SMTP e NNTP.
IIS Metabase - É o repositório de metadados do IIS. Na verdade o Metabase nada mais é que a configuração do IIS. Na versão 6.0 o IIS Metabase é armazenado, em grande parte, em arquivos XML e, o restante, é armazenado no registry do Windows.
Passo a passo
Entendido quais os componentes que compõe o IIS, vamos agora descrever um passo a passo do que acontece a cada request feito a uma aplicação ASP.Net hospedada num servidor IIS. Note que alguns detalhes de processamento foram omitidos para simplificar e objetivar a explicação.
- Você digita o endereço da aplicação e pressiona <Enter>.
- O browser envia um request HTTP solicitando a página.
- No IIS, o componente HTTP.sys, recebe o request. Neste momento o HTTP.sys se comunica com o serviço WWW, que verifica a existência de um worker process ativo para a aplicação. Se não existir o serviço WWW cria o worker process. Ao criar o worker process é criado o AppDomain da aplicação.
- O HTTP.sys verifica se existe em seu cache dados para atender o request. Se já existe um resultado cacheado então este é retornado para o browser, senão o request é passado a frente.
- Utilizando uma routing table o HTTP.sys descobre qual é a fila de requests da aplicação e encaminha o request através desta.
- O worker process recebe o request, identifica a página ASPX solicitada, executa a página, faz todo o processamento necessário e devolve para o HTTP.sys.
- O HTTP.sys devolve o resultado para o browser.
- O browser mostra o resultado da página processada.
Espero que este artigo tenha melhorado sua compreensão sobre como funciona uma aplicação ASP.Net no IIS 6.0. Este assunto é bastante interessante e pode ser muito explorado.
Um boa dica, se você deseja se aprofundar neste assunto, é seguir o seguinte link: IIS 6.0 Architecture (IIS 6.0)
Bem, por hoje é só. Até a próxima!
