Aspnet DiskOutputCacheProvider
1.0.0
Um cache de disco persistente do sistema de arquivos para asp.net
Resumo de: https://www.codeproject.com/articles/12097/cache-management-in-asp-net
Use termos diferentes para explicar o mesmo conceito, ou seja, gerenciar dados. Algumas pessoas se referem a ele como gerenciamento de estado e outras se referem a ele como gerenciamento de cache. Eu gosto da palavra "cache". Mas conceitualmente, não há diferença entre esses dois.
Agora, vamos discutir diferentes aspectos do gerenciamento de cache (ou gerenciamento de estado) no ASP.NET.
Embora o gerenciamento de cache não seja um problema nos aplicativos do Windows, sempre foi um desafio no ambiente da web. Como o HTTP é um protocolo sem estado e um servidor da Web não reconhece os usuários entre diferentes solicitações, torna-se muito importante para reconhecermos um usuário específico entre diferentes solicitações e também armazenamos dados para que possam ser reutilizados entre diferentes solicitações. O ASP.NET fornece muitos recursos para armazenar dados tanto no cliente (navegador) quanto no servidor (servidor da web), mas às vezes nos confundimos com quando usar o quê. No ASP.NET, encontramos recursos como sessões, objetos de aplicação e cache, mas é importante entendermos a diferença entre eles para usá -los efetivamente em aplicativos da Web.
Neste artigo, abordarei as diferentes opções de gerenciamento de cache disponíveis no ASP.NET. Em um aplicativo da Web, às vezes precisamos armazenar dados no lado do servidor para evitar a operação de recuperação de dados dispendiosos de lojas de dados e lógica de formatação de dados que consome tempo para melhorar o desempenho do aplicativo, além de reutilizar os mesmos dados nas solicitações subsequentes entre usuários, aplicativos e máquinas. Portanto, para conseguir isso, precisamos armazenar dados (cache) no lado do servidor.
O cache nos ajuda a alcançar três aspectos importantes da QoS (Qualidade do Serviço):
O ASP.NET fornece um objeto chamado Objeto Aplicativo para armazenar dados acessíveis a todas as solicitações de usuário. A vida útil desse objeto está vinculada ao aplicativo e é recriada toda vez que o aplicativo inicia. Ao contrário do objeto de sessão do ASP.NET, esse objeto é acessível a todas as solicitações de usuário. Como esse armazenamento é criado e mantido em um espaço de domínio do aplicativo, isso não deve ser usado para armazenamento de dados em um cenário da fazenda da web. Esta opção é muito útil para armazenar dados como os metadados do aplicativo (dados de arquivos de configuração) que podem ser carregados no objeto do aplicativo durante a inicialização do aplicativo e podem ser usados durante a vida útil do aplicativo sem recarregá -lo sempre para cada solicitação do usuário. Mas se houver um requisito para invalidar os dados em cache sempre que houver alteração nos arquivos de configuração enquanto o aplicativo estiver em execução, essa opção não deve ser usada, pois não fornece nenhum recurso para expirar os dados em cache. Portanto, neste caso, outras opções, como o objeto de cache do ASP.NET, devem ser usadas, o que é explicado abaixo.
O ASP.NET fornece um objeto de pares de valor -chave - o objeto de cache que está disponível no espaço de nome System.Web.Caching. O escopo é o domínio do aplicativo e a vida útil está vinculada ao aplicativo. Ao contrário do objeto de sessão do ASP.NET, esse objeto é acessível a todas as solicitações de usuário.
Embora os objetos de aplicação e cache tenham a mesma aparência, a principal diferença entre eles são os recursos adicionados fornecidos pelo objeto de cache, como as políticas e dependências de expiração. Isso significa que os dados armazenados no objeto de cache podem ser expirados/removidos com base em algum limite de tempo predefinido definido pelo código do aplicativo ou quando a entidade dependente é alterada, enquanto esse recurso não está disponível no objeto de aplicativo.
Vamos discutir as diferentes políticas de expiração e as dependências suportadas.
Dependência significa que um item pode ser removido do cache quando uma entidade dependente é alterada. Portanto, um relacionamento dependente pode ser definido de um item cuja remoção do cache dependerá do dependente. Existem dois tipos de dependências suportadas no ASP.NET.
Exemplo: digamos no meu aplicativo, estou usando um arquivo XML para armazenar detalhes de erro (número de erro e mapeamento de mensagens de erro) que é usado para recuperar uma mensagem de erro para um determinado número de erro no tempo de execução. Portanto, em vez de ler o arquivo do disco cada vez que preciso de uma mensagem de erro, digamos que eu decida carregá -lo uma vez na inicialização do aplicativo e armazená -lo no cache ASP.NET para uso posterior. Portanto, se eu precisar alterar o arquivo de configuração para adicionar novas mensagens de erro ou alterar algumas das mensagens de erro existentes enquanto o aplicativo estiver em execução, o que acontecerá com meus dados em cache? Preciso interromper o aplicativo e iniciá -lo novamente para refletir as alterações do arquivo no aplicativo? A resposta é não. Os dados do cache podem ser invalidados sempre que o arquivo alterar usando a opção de dependência do arquivo.
A Política de Expiração define a política de como e quando um item no cache deve expirar.
O objeto Singleton Remoting .Net compartilha a mesma instância com vários clientes, para que os objetos singleton possam ser usados para armazenar e compartilhar dados entre diferentes invocações de clientes. Como o .NET remoto pode ser usado fora do processo e da máquina, essa opção é muito útil quando queremos cache dados e compartilhá -los entre servidores e usuários, particularmente em um cenário da fazenda na web. Nesta abordagem, podemos armazenar os dados como variáveis de membro do objeto Singleton Remoting e fornecer métodos para ler e salvar dados. Mas, ao implementar isso, precisamos garantir que o objeto remoto usado como cache não seja destruído pelo coletor de lixo. Para isso, teremos que definir o período de arrendamento do objeto de cache remoto como infinito, para que o período de arrendamento nunca se destaque. Podemos fazer isso substituindo o método InitializelifetimeService de MarshalbyRefobject e retornar NULL deste método. Mas o único problema com essa abordagem é o desempenho. Como diz a análise, o desempenho é muito ruim nessa abordagem quando comparado a outras abordagens. De qualquer forma, cabe aos designers/desenvolvedores de aplicativos analisar diferentes opções e usar o melhor que atenda ao requisito.
Todos vocês sabem o que é um arquivo mapeado de memória. É basicamente o mapeamento de um arquivo no disco para uma gama específica de endereços no espaço de endereço do processo do aplicativo. Esta opção permite que diferentes processos usem os mesmos dados, aumentando o desempenho do aplicativo. Como o uso do arquivo mapeado de memória não é muito popular entre os desenvolvedores .NET, eu pessoalmente não sugeriria essa abordagem como implementar isso envolve muitas complexidades e também a estrutura .NET não suporta isso. Mas se alguém estiver muito interessado em usar essa abordagem, terá que desenvolver sua própria solução personalizada conforme seu próprio requisito.
Utilizamos variáveis estáticas para armazenar dados ou objetos globalmente, para que possam ser acessados durante a vida útil do aplicativo. Da mesma forma, no ASP.NET, podemos usar objetos estáticos para cache de dados e também podemos fornecer métodos para recuperar e salvar dados no cache. Como as variáveis estáticas são armazenadas na área do processo, o desempenho é mais rápido. Mas como é muito difícil implementar políticas e dependências de expiração no caso de variáveis estáticas, geralmente prefiro o objeto de cache do ASP.NET sobre essa opção. Outro problema é que o objeto de cache estático personalizado deve ser seguro que deve ser implementado com cuidado.
Também podemos usar um banco de dados para armazenar dados e compartilhar os dados entre usuários e máquinas. Essa abordagem é muito útil quando queremos cache grandes quantidades de dados. Usar essa abordagem para armazenar pequena quantidade de dados não é uma boa idéia por causa do desempenho. Para armazenar uma pequena quantidade de dados, devemos optar por outros mecanismos de cache no processo ASP.NET. Como os dados precisam ser armazenados em um banco de dados, todos os objetos precisam ser serializados para XML para que seja mais fácil armazenar e recuperar. Também podemos usar outros tipos de formatos de serialização disponíveis na estrutura .NET.
Às vezes, em nossa aplicação, em algumas páginas, a saída geralmente não muda por um período específico de tempo. Por exemplo, em um site de RH, os detalhes do salário de um funcionário não mudam com muita frequência e isso muda apenas uma vez por mês. Geralmente, muda apenas no 1º dia de cada mês. Portanto, durante um mês, a página de detalhes do salário mostrará os mesmos detalhes para um determinado funcionário. Portanto, neste caso, não é uma boa ideia cache a página em algum lugar do servidor para evitar o processamento de cálculo de negócios, chamadas para o banco de dados e a lógica de renderização da página toda vez que o funcionário deseja ver seus detalhes de salário. Na minha opinião, sim! É uma ideia muito boa. Para conseguir isso, o ASP.NET fornece um recurso para armazenar a saída de uma página no servidor por um período específico de tempo. Ele também fornece recursos para armazenar um fragmento de uma página conhecida como cache de fragmento de página.
Às vezes, podemos precisar armazenar em cache dados ou páginas no lado do cliente para melhorar o desempenho do aplicativo. O uso desse mecanismo reduz a carga no servidor, mas esse mecanismo tem alguns problemas de segurança à medida que cache os dados no lado do cliente.
O Cookie é um armazenamento do lado do cliente enviado ao servidor para cada solicitação e também recebido como resposta de volta do servidor. Devido à sua limitação de tamanho, ele deve ser usado para armazenar uma pequena quantidade de dados. As políticas de validade podem ser definidas para os cookies invalidar os itens após um certo período de tempo.
ASP.NET ViewState é um conceito apenas em WebForms (não MVC), onde os dados relacionados às páginas e controles são armazenados na página gerada (lado do cliente). que retém os valores em várias solicitações para o servidor. O ViewState é implementado internamente como campos ocultos criptografados no ASP.NET. O ViewState não deve ser usado para armazenar grandes quantidades de dados, pois são passadas para o servidor para cada solicitação.
O campo oculto é semelhante a qualquer outro controle em uma página, mas o estado visível desse controle é sempre falso. Como o ViewState, não devemos usá -lo para armazenar grandes quantidades de dados. Os quadros ocultos podem ser usados para armazenar em cache os dados do lado do cliente, mas observe que os quadros ocultos não são suportados por todos os navegadores da Internet.
Os navegadores da Internet fornecem mecanismo de cache para armazenar em cache páginas do lado do cliente. Isso pode ser definido usando a diretiva Expires adicionada ao cabeçalho das páginas ou configurando -a manualmente no servidor da Web. Devemos usar essa opção para armazenar em cache páginas estáticas, scripts, CSs e imagens no lado do cliente.
Feito com ❤️ por Javier Cañon.
