Quick Dev: Melhorando a performance de aplicações ASP .NET

Olá pessoal!

Quem nunca se incomodou com o tempo levado para a recompilação de aplicações ASP .NET já publicadas? Pois é, cada vez que um arquivo “top-level” é alterado em sua aplicação ASP .NET, por padrão, toda a compilação do site feita no seu primeiro acesso é invalidada, causando uma recompilação no próximo acesso. São considerados arquivos “top-level” os arquivos global.asax e todos os arquivos da pasta bin e app_code. Isso pode se tornar um problema para grandes aplicações, pois, o tempo de recompilação pode se estender além do desejável, podendo chegar a mais de dez minutos, dependendo do tamanho da aplicação, conforme registrado na documentação da Microsoft (veja o link no final deste post).

Para contornar este problema, a Microsoft incluiu um recurso no .NET que nos permite habilitar o que é chamado de compilação otimizada. Esta compilação é um pouco mais inteligente do que a padrão, de forma que, ao invés de recompilar o site inteiro quando um arquivo top-level é alterado, apenas os arquivos afetados pela sua alteração são recompilados, diminuindo o tempo total da recompilação e por consequência, o tempo de espera do primeiro acesso após a modificação.

Para ativar a compilação otimizada, basta incluir a configuração a seguir dentro do elemento system.web do arquivo web.config da sua aplicação. O recurso já está disponível no Windows 7, Windows Server 2008 Service Pack 2 e Windows Server 2008 R2. Para o Windows Vista Service Pack 1 e Windows Vista Service Pack 2, é necessário instalar o seguinte hot-fix: http://code.msdn.microsoft.com/KB967535.

Problema resolvido? Não totalmente. Com este recurso habilitado, é preciso ficar muito atento aos tipos de alteração que são feitas na aplicação. Isso porque, se apenas os arquivos afetados diretamente pela modificação são recompilados, podem ocorrer erros quando um arquivo da versão antiga precisar acessar algum recurso não mais compatível na versão nova. Por exemplo, imagine uma página que acessa um método de uma determinada classe, que teve sua assinatura alterada na modificação realizada. A classe publicada é recompilada, porém, a página não, o que causa um erro quando da sua execução.

Para mais detalhes sobre o assunto veja a documentação completa a respeito no artigo: Understanding ASP.NET Dynamic Compilation. Não deixe de considerar também a opção de utilização da pré-compilação: ASP.NET Precompilation Overview.

Posts Similares

  • Quick Dev: Formulários não-retangulares

    Olá pessoal! Este é o primeiro post de uma nova sessão denominada “Quick Dev”. O objetivo desta sessão é explorar rapidamente algumas abordagens de desenvolvimento simples, porém, úteis.    Se você está se perguntando neste momento: porque estamos abordando questões de desenvolvimento em um blog de arquitetura? Eu recomendo ler o texto de John Davies (não errei…

  • Quick Dev: Connection Pooling

    Olá pessoal!  Continuando a série Quick Dev, neste artigo vou falar um pouco sobre pooling de conexões em uma aplicação .NET.  Para começar, a seguir temos uma definição simples de pool de conexões: trata-se de um cache de conexões de banco de dados, mantidas de forma que possam ser reutilizadas quando futuras requisições são necessárias. Em uma aplicação .NET…

  • Quick Dev: Behind LINQ to SQL

    Você que já utiliza o LINQ to SQL já deve ter tido a curiosidade de saber como as suas consultas LINQ são transformadas em comandos SQL e principalmente, qual a estrutura destes comandos SQL. Como o LINQ to SQL gera um comando SQL para atualizar apenas um registro em uma tabela? Ele utiliza sua chave primária na clausula WHERE? Acredito que estas sejam questões muito importantes para nos embasarmos quando tivermos que decidir pela sua utilização ou estabelecermos os cenários em que podemos aplicá-lo. No artigo anterior dei um overview sobre o LINQ. Neste artigo conceituo o provider LINQ to SQL e demonstro como suas consultas LINQ são transformadas em comandos SQL.

Deixe um comentário