Turbine sua aplicação ASP.Net - Parte 2

Você sabia que o tempo de resposta de sua aplicação ASP.Net pode aumentar muito quando se utiliza o Kernel Mode Caching? Você sabe o que é isso? Saiba neste artigo.

por Marcelo Menezes Neves

Você sabia que o tempo de resposta de sua aplicação ASP.Net pode aumentar muito quando se utiliza o Kernel Mode Caching? Você sabe o que é isso? De que forma você atualiza uma aplicação ASP.Net? Copia as páginas que mudaram para o diretório da aplicação e pronto? Cuidado! Continuando a falar sobre performance, hoje irei falar sobre kernel mode caching e como atualizar uma aplicação ASP.Net.

Kernel Mode Caching

Antes de falarmos de como podemos nos beneficiar do Kernel Model Caching precisamos antes entender algumas mudanças que ocorreram no IIS. Antes da versão 6 do IIS, o componente responsável por receber os requests HTTP era o Windows Sockets API (Winsock), que operava em user-mode. A partir da versão 6 do IIS, o HTTP listener foi implementado como kernel-mode, agora core component do sistema operacional, chamado HTTP Protocol Stack (HTTP.sys).

Na versão 6, a vantagem não só é o HTTP.sys rodar em kernel-mode, mas também possuir um cache que pode armazenar até 64GB de informação, na plataforma x86. Agora, com a implementação de um HTTP listener, que é parte central do sistema operacional, e que portanto roda em kernel-mode, não há necessidade de sempre encaminhar o request até o worker process para ser atendido. Em certas situações, o HTTP.sys se utiliza do seu próprio cache para atender aos requests HTTP, o que certamente agiliza bastante o tempo de resposta da aplicação.

O processo natural de quando você solicita uma página aspx no browser é o seguinte: o browser envia um request para o IIS, este ativa seu HTTP listener, que na versão 6 é o HTTP.sys. Este recebe e encaminha para uma fila de requests até chegar no worker process e ser atendido pelo mesmo. Lembre-se que cada application pool corresponde a uma fila de requests, portanto se sua aplicação estiver configurada para um application pool que somente ela usa, isto garantirá melhor isolamento, como também garantirá melhor performance. O grande overhead deste processo é que para o HTTP.sys enviar a request para o worker process, o processador tem que obrigatoriamente alternar de kernel-mode para user-mode.

Quando o Kernel-Mode Caching está habilitado, o HTTP.sys sempre irá consultar seu cache e, se disponível, irá devolver o conteúdo cacheado sem ter que passar a operar no modo user-mode, que é custoso. Por default ele já vem habilitado e, você pode verificar isso por abrir o arquivo machine.config, e verificar o elemento httpRunTime que deve estar configurado da seguinte maneira: <httpRunTime enableKernelOutputCache="true" />

Agora se o Kernel Mode Caching já vem habilitado por default, por que estou dando tanta importância a esse assunto? Simples, para aproveitar as maravilhas deste recurso você tem que prestar atenção as seguintes diretrizes:

• A página tem que ser obtida utilizando-se HTTP GET request.
• Query string é desconsiderada no cache.
• A página deve possuir o header Expires.
• A página não deve ter restrições de segurança, ou seja, o request deve ser anônimo e não precisar de autenticação.
• A página não deve possuir VaryByParams e VaryByHeaders.

Atualizando uma aplicação ASP.Net

Como você costuma atualizar sua aplicação ASP.Net? Simplesmente copia as páginas aspx para o diretório da aplicação? Então você está comprometendo a performance de sua aplicação. Veja abaixo o porquê:

Imagine que sua aplicação possui 4 páginas:

Quando a primeira página é solicitada ocorre a Batch Compilation, ou seja, todas as páginas são compiladas num único assembly (DLL), conforme mostrado abaixo:

Assembly1.dll

Suponha que você alterou a página pagina1.aspx e que você copiou a página para o diretório da aplicação. Neste momento o código da pagina1.aspx será recompilado e teremos assim o seguinte cenário:

Assembly1.dll (pagina1.aspx, pagina2.aspx, pagina3.aspx, pagina4.aspx)
Assembly2.dll (pagina1.aspx)

Se uma segunda página, pagina3.aspx por exemplo, for atualizada teremos o seguinte cenário:

Assembly1.dll (pagina1.aspx, pagina2.aspx, pagina3.aspx, pagina4.aspx)
Assembly2.dll (pagina1.aspx)
Assembly3.dll (pagina3.aspx)

Perceba que este tipo de comportamento comprometerá a performance de sua aplicação. Para que isto não ocorra, ao atualizar uma aplicação ASP.Net proceda da seguinte maneira:

1. Remova o servidor de rotation
2. Reinicialize o IIS
3. Delete todos os arquivos do diretório temporário do ASP.NET
4. Chame a aplicação no browser, para forçar a batch compilation
5. Coloque o servidor em rotation

Seguindo o procedimento acima, você garantirá que a Batch Compilation será executada com sucesso. Mas, ainda existe um outro porém, nunca misture páginas VB com páginas C# num mesmo diretório de aplicação. O DotNet framework criará um assembly para as páginas VB e outro assembly para as páginas C#.

Nomeando controles

Uma dica muito simples e que poucos se apercebem da importância é quanto ao nome dos controles (grid, text boxes e etc.). Você é daqueles que não se preocupa com o nome dos controles e procura nomeá-los de maneira que se tornem bem claros de serem identificados? Cuidado! Os nomes dos controles são utilizados pelo DotNet para gerar os HTML unique names. Um grid que possui um nome com tamanho de dez caracteres, pode facilmente chegar a um HTML unique name com tamanho de 40 caracteres. Portanto, aqui vale a regra: quanto menor o tamanho do nome, melhor!

Na próxima semana tem mais! Até lá!