É OK para usar variáveis ??estáticas para informações de cache em ASP.net?

Question

No momento eu estou trabalhando em um aplicativo administrador do projeto em C # 3.5 em ASP.net. A fim de reduzir acessos ao banco de dados, eu estou cache uma grande quantidade de informações utilizando variáveis ??estáticas. Por exemplo, uma lista de usuários é mantida na memória em uma classe estática. A classe lê todas as informações do banco de dados na inicialização, e irá atualizar o banco de dados sempre que forem feitas alterações, mas nunca precisa ler a partir do datebase.

Os pings de classe outros servidores web (se existirem) com informações atualizadas ao mesmo tempo como uma gravação ao banco de dados. O mecanismo de ping é um serviço do Windows para que os registros de cache de objetos usando uma porta disponível aleatória. Ele é usado para outras coisas também.

A quantidade de dados não é tão grande. No momento eu estou usando-o apenas para armazenar em cache os usuários (hashes de senha, permissões, nome, e-mail etc.) Ele só salva uma pilha de chamadas que estão sendo feitas para o banco de dados.

Eu queria saber se há qualquer armadilhas para este método e / ou se existem melhores maneiras de armazenar em cache os dados?

Answer 1

Uma armadilha: campo estático A tem como escopo por domínio de aplicativo, e aumento de carga fará com que o servidor gerar mais domínios de aplicação na piscina. Isso não é necessariamente um problema se você apenas lê a partir da estática, mas você vai ter dados duplicados na memória, e você vai ter um sucesso cada vez que um domínio de aplicativo é criado ou reciclado.

Melhor usar o objeto Cache -. É destinado para coisas como esta

Edit: Acontece que eu estava errado sobre AppDomains (como fora apontado em comentários) - Mais instâncias do Aplicação será gerado sob carga, mas todos eles vão correr no mesmo AppDomain. (Mas você ainda deve usar o objeto de cache!)

Answer 2

Enquanto você pode esperar que o cache nunca vai crescer a um tamanho maior do que a quantidade de memória disponível, está tudo bem. Além disso, certifique-se de que haverá apenas uma instância desta aplicação por banco de dados, ou os caches nas diferentes instâncias do aplicativo poderia "cair fora de sincronia."

Onde eu trabalho, temos um homegrown O / RM, e nós fazer algo semelhante ao que você está fazendo com certas tabelas que não são esperados para crescer ou mudar muito. Então, o que você está fazendo não tem precedentes, e de fato em nosso sistema, é experimentado e verdadeiro.

Answer 3

Outra armadilha que você deve considerar é a segurança do thread. Todas as suas solicitações de aplicativos estão em execução no mesmo AppDomain mas pode vir em diferentes threads. Aceder a uma conta variável deve estático para ele ser acessado a partir de vários segmentos. Provavelmente um pouco mais sobrecarga do que você está procurando. objeto de cache é melhor para esta finalidade.

Answer 4

Hmmm ... O método "clássico" seria o cache do aplicativo, mas desde que você não atualizar as variáveis ??estáticas, ou compreender os problemas de bloqueio se o fizer, e você entender que eles podem desaparecer a qualquer momento com um restart appdomain seguida Eu realmente não vejo o mal em usar um estático.

Answer 5

Eu sugiro que você olhar para formas de ter um cache distribuído para a sua aplicação. Você pode dar uma olhada em NCache ou indeXus.Net

A razão eu sugeri que é porque você rolou a sua própria maneira ad-hoc de atualização das informações que você está caching. Variáveis ??estáticas / referências são bons, mas eles não atualizar / refresh (assim você vai ter que lidar com o envelhecimento em seu próprio país) e você parece ter uma configuração distribuída.