ASP.NET Caching Escalabilidade e desempenho ao seu alcance

Cache de Fragmento

Em alguns casos usar o cache em toda a página não é a melhor solução. Páginas onde é preciso montar um menu baseado no perfil do usuário é um exemplo típico de cache em apenas uma parte da página. Já em áreas comuns a todos, por exemplo, notícias, é preciso fazer o cachê para toda a região. Este é o cenário ideal para o uso do fragment caching.

O cache de fragmentos consiste no cache de UCs (user controls - arquivos .ascx) e suporta os mesmos atributos do cache de repostas (com exceção, por motivos óbvios, do location). Esses UCs suportam também o atributo VaryByControl que define a existência de múltiplas versões no cache do mesmo user control, baseadas nos valores assumidos pelos controles membros (embutidos no UC), como, por exemplo, um DropDownList. Por padrão, cada user control é “cacheado” para cada página em separado, mas podemos definir, se for o caso, que todas as páginas hospedeiras (que embutem tais controles) tenham a mesma versão em cache. Para fazer isso, definimos o atributo shared como true (o valor padrão é false).

Se Varybycontrol é especificado, o atributo VaryByParam pode ser omitido:

Finalmente, vale lembrar que podemos utilizar o cache manipulando os métodos HttpCachePolicy.SetExpires e HttpCachePolicy.SetCacheability na propriedade HttpResponse.Cache. O código a seguir configura um tempo de expiração de 20 segundos:

Response.Cache.SetExpires(DateTime.Now.AddSeconds(20));

Cache de Objetos

Como podemos perceber na Figura 1, quando requisitamos algum recurso colocado no cache de respostas, não ocorre nenhuma execução de código. Já no cache de objetos, precisaremos tomar algumas decisões em tempo de execução. Os desenvolvedores web que estiverem lendo estas linhas se lembrarão dos objetos presentes no nosso dia-a-dia: Session e Application. O ASP.NET nos apresenta um novo objeto para acesso a pares chave/valor - o objeto Cache. Cabe lembrar que o escopo do cache do ASP.NET é o application domain, de modo que não podemos acessá-lo a partir de outras aplicações ou processos. Outro ponto relevante é que o objeto de Cache é recriado a cada reinicialização da aplicação, o que nos remete à certa similaridade com o objeto Application. A principal diferença entre esses dois reside no fato de que o objeto de Cache proporciona funcionalidades específicas, tais como dependências e políticas de expiração.

Suponhamos que o arquiteto da aplicação NW Traders especifique que a relação de categorias dos produtos comercializados pela empresa, que é relativamente pequena e que não é alterada com freqüência (uma vez por semana em média), deva ficar em cache o maior tempo possível, mas que essa relação expire tão logo sejam alteradas, removidas ou inseridas novas categorias no banco de dados. Esse cenário foi escolhido por apresentar uma das dificuldades encontradas pelo cache de objetos: não foi prevista nenhuma forma de se estabelecer uma dependência direta com o banco de dados. Podemos, no entanto, forçar uma dependência por meio de artifícios técnicos.

Quando adicionamos um item ao cache de objetos, definimos algumas dependências que poderão forçar a remoção desse item em determinadas circunstâncias. Vejamos a assinatura do método Insert:

public void Insert(string, object, CacheDependency, DateTime, TimeSpan, CacheItemPriority, CacheItemRemovedCallback);

Podemos, por meio do construtor, definir alguns comportamentos interessantes:

·         Dependências: invalida o item específico com base em alterações efetivadas em um ou mais arquivos no disco, diretórios ou mesmo em outros objetos no cache – expiração em cascata (tipo CacheDependency);

·         Expiração absoluta: momento no qual o item expira e é removido do cache (tipo DateTime);

·         Expiração deslizante: remove o item do cache se este não for acessado dentro de determinado período, se o item for acessado, o período será renovado (tipo TimeSpan);

·         Prioridade: quando a aplicação necessita de mais memória, os itens são removidos do cache para liberar recursos (processo conhecido como scavenging). Podemos, por meio da prioridade, definir quais itens serão removidos primeiro (Low, Normal - Default, High, NotRemovable, BelowNormal, AboveNormal);

·         CallBack: define um método de callback para notificar a aplicação de que determinado item foi removido. Em outras palavras, quando o item é removido, o método apontado é executado com o objetivo de repopular o cache.

Na Listagem 3, aperfeiçoamos o método RecuperaCategorias da página ProdutosPorCategoria.aspx de forma que ele controle a existência da relação de categorias (dataset) no cache de objetos.

Listagem 3. Método RecuperaCategorias, que define a expiração (no cache) da relação de categorias

private DataSet RecuperaCategorias()

{

       DataSet ds = new DataSet();

       if (Cache["dsCategorias"]==null)

       {

             SqlConnection cn = new SqlConnection("data source=servidorsql;

                         integrated security=true;initial catalog=northwind");

             SqlDataAdapter da = new SqlDataAdapter("SELECT * FROM [Categories]",cn);

             da.SelectCommand.CommandType = CommandType.Text;

             da.Fill(ds, "Categorias");

             System.Web.Caching.CacheDependency DepArq = new System.Web.Caching.CacheDependency(

                         @"\\servidorsql\rede$\Categorias.XML");

             Cache.Insert("dsCategorias", ds, DepArq, 

                        System.Web.Caching.Cache.NoAbsoluteExpiration,

                        System.Web.Caching.Cache.NoSlidingExpiration,

                        System.Web.Caching.CacheItemPriority.Normal, null);

       }

       else

       {

             ds = (DataSet)(Cache["dsCategorias"]);

       }

       return ds;

}

Na Listagem 3 vemos que no servidor web a relação de categorias é colocada em cache com uma dependência de arquivos apontando para um diretório na rede “\\servidorsql\rede$\Categorias.XML” - lembre-se de que devemos configurar o compartilhamento e as respectivas permissões[i], ou obteremos: “Failed to start monitoring changes to '\\servidorsql\rede$\'”.

Fica agora a questão: como instruir o banco de dados SQL Server a acessar esse diretório local e alterar o arquivo Categorias.xml (c:\rede\Categorias.xml)? Uma das soluções é usar uma aplicação console (Listagem 6) disparada a partir de um trigger (Listagens 4 e 5).

Listagem 4. Função InvalidaCache – UDF (User Defined Function) criada no catálogo Northwind (SQL Server)

CREATE FUNCTION InvalidaCache (@TableName VarChar(25))

RETURNS INT

AS

BEGIN

       DECLARE @CMDS VarChar(100)

       SET @CMDS = 'c:\rede\SQLDependency.exe ' + @TableName

       EXEC Master..xp_cmdshell @CMDS

       RETURN 0

END

Listagem 5. Gatilho InvalidaCache - Trigger criado na tabela Categories do catálogo Northwind (SQL Server) que chama a UDF da Listagem 3.

CREATE TRIGGER InvalidaCacheCat ON Categories

AFTER

       INSERT,

       DELETE,

       UPDATE

AS

BEGIN

       EXEC InvalidaCache 'Categorias'

END

Listagem 6. Aplicação console que irá alterar o arquivo local (deve estar no diretório “c:\rede\” - SQL Server)

Imports System

Imports System.IO

Namespace SQLDependency

    Module Invalidate

        Dim path As String = "c:\rede\"

        Sub Main(ByVal CmdArgs() As String)

            Try

                Dim _table As String = CmdArgs(0).ToString()

                Dim _r As New Random(Date.Now.Millisecond)

                Dim _value As String = "< MSDN><SQLDEPEND rnd='" + _r.Next(1111111, 9999999).ToString() + "' /> </MSDN>"

                     path = path & _table & ".xml"

                Dim _SWriter As New StreamWriter(New FileStream(path, FileMode.Open, FileAccess.Write))

                SWriter.Write(_value)

                SWriter.Close()

            Catch ex As Exception

                Throw ex

                'no futuro, quem sabe.....

            End Try

        End Sub

    End Module

End Namespace

Execute a aplicação console (Figura 4), passando como parâmetro o nome da tabela supostamente alterada: Categories. A aplicação irá alterar o arquivo com o nome da tabela no disco, o que, no nosso caso, invalidará o item no cache do servidor web. Um teste mais realista consiste em alterar o nome de uma das categorias e observar a alteração no arquivo c:\rede\Categorias.xml. Feito isto, o servidor web invalidará a relação de categorias (Dataset) colocada em cache por meio da dependência associada ao arquivo remoto \\SERVIDORSQL\REDE$\Categorias.xml.

Figura 4. Execução da aplicação de console

CONCLUSÃO

É importante dominar o funcionamento do caching no ASP.NET, uma vez que esse recurso pode nos garantir um aumento substancial na performance da aplicação, sem muito esforço.

Nosso objetivo aqui foi apresentar o assunto aos neófitos e oferecer um artifício técnico bastante útil aos iniciados. Existem diversos outros pontos a serem discutidos sobre o ASP.NET caching, mas deixaremos essa abordagem mais completa para outra oportunidade.