Problemas de cache no SQL Server

Se você estiver recebendo uma mensagem do tipo:

O SQL Server encontrou %d ocorrência(s) de liberação de armazenamento em cache para o cache '%s' (parte do cache do esquema) devido à manutenção do banco de dados ou operações de reconfiguração.

ou

SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.

É porque, segundo a MSDN, ao limpar o cache do plano gera uma recompilação de todos os planos de execução subseqüentes e pode provocar uma queda repentina e temporária no desempenho da consulta. Para cada armazenamento em cache limpo no cache do plano, aparece a mensagem supracitada.

Para resolver isso, basta ir no banco correspondente, clicar com o direito sobre ele e escolher Properties (Propriedades). Entre em Options (Opções) e configure o Auto-Close (Fechamento Automático) para False.

Diferenças entre Aplicações Compiladas e Não-Compiladas

Quando programávamos (ou programamos) com aquelas linguagens do tipo PHP ou ASP Clássico apenas pegávamos o que foi implementado e jogávamos no servidor web para uso. Com a inovação das tecnologias e tipos de linguagens (compiladas, interpretadas, híbridas) algumas dúvidas nos cercam quando estamos publicando um certo projeto. Nesse caso, falemos do ASP.NET para as versões acima da 2.0.

Antes de mais nada, o ASP.NET é compilado. Mesmo que você jogue os fontes no IIS ele é compilado na primeira vez que é acessado (e/ou alterado). Você não vê, mas por trás é feito isso. Para quem nunca compilou uma aplicação web, há diversas formas para uma dada finalidade. Geralmente é usada a função Publish Web Site (compila e publica).

Mas o que muitos perguntam é: existe diferença de desempenho? Não! Muitos dizem que há um pouco, mas já trabalhei com várias aplicações e não notei qualquer diferença. Li vários artigos por aí na net e não achei qualquer um que demonstrasse e/ou notasse diferença brusca de desempenho. Então, elaborei a seguinte tabelinha abaixo com um pequeno resumo. Se tiver mais, favor avisar-me que atualizo:

	Compilada	Não-Compilada
Desempenho	Normal	Normal
Código-fonte	Protegido em DLL's	Visível
HTML	Sem mudança	Sem mudança
Atualização\Correção	Precisa compilar todo o projeto e publicá-lo (código-fonte) enquanto no design pode alterar normalmente	Pode alterar diretamente no problema (página)
Primeiro Acesso	Normal	Lento

Óbvio que toda regra tem sua exceção, então a depender dos casos supra-citados pode haver pequenos detalhes que mudam uma coisinha ou outra mas nada de tão drástico (de acordo com a tabela - exemplo, na compilação FULL você não altera sequer o HTML). Se quiserem conhecer mais sobre os tipos de compilação (Full, Pré ou Sob-Demanda) visite os links da MSDN e de Dennes Torres.

Melhorando o desempenho de aplicações ASP.NET que usam AJAX

Alguns dias atrás estava lendo alguns artigos sobre desempenho e achei um artigo interessante de LanceZhang na qual ele fez uma bateria de testes em um website que possuia controles ASP.NET AJAX. O artigo você lê na íntegra aqui. Mas, como se diz na web, "é old mas é gold!", aproveitei o artigo dele para resumir (tirar o quente) das configurações que ele aplicou e os colocarei aqui. Para quem sabe inglês o artigo é indispensável a leitura, pois lá ele mostra com detalhes os testes realizados bem como os gráficos de desempenho.

Bem, o que ele fez? Encheu uma página de controles AJAX e primeiramente mediu o tráfego na rede averiguando a quantidade de bytes que são carregados quando feito uma requisição, sendo ela quando dado um PostBack ou apenas no Load da página. Quem tem o Firefox, com certeza deve ter o plugin Firebug instalado. No Firebug tem uma sessão de monitoramento de Rede que analisa as chamadas realizadas.

A primeira coisa notada é o tamanho da página que estava muito grande. O uso do cache reduzia bruscamente o tamanho da página sem fazer novos carregamentos desnecessários. Juntamente com a compressão do ScriptResource que reduz ainda mais o tamanho dos scripts gerados.  Então, no web.config, devemos aplicar a seguinte configuração:

<system.web.extensions>
<scripting>
<scriptResourceHandler enableCompression="true" enableCaching="true" />
</scripting>
</system.web.extensions>

Faça um novo teste e notará a diferença! Outro aplicação de desempenho é a forma como o ScriptManager do AJAX é trabalhado. Então é sugerido usá-lo com a seguinte configuração:

<asp:ScriptManager ID="ScriptManagerAjax" runat="server" EnablePartialRendering="false" ScriptMode="Release" LoadScriptsBeforeUI="false">
</asp:ScriptManager>

Cuidado com o EnablePartialRendering! Faça o teste em sua aplicação com os valores false ou true porque a depender do que você usa em seu sistema isso muda muito no comportamento dos scripts. Por último, você pode usar o CompositeScript dentro do ScriptManager para agregar várias chamadas de scripts em uma só. Veja lá no site de LanceZhang como fazer, caso tenha interesse nessa parte e se isso ainda não foi o suficiente.

Agregado a isso, e fora do escopo, você pode usar a compressão/compactação do ViewState para minimizar o tamanho da página. Você pode encontrar artigos relacionados por aí na net, mas aconselho dar uma lida nesse aqui ou esse a depender de como queira utilizar. Muitas vezes eu prefiro desabilitar o ViewState... Mais rápido, só que com cautela!