Infra-estrutura da Web

ASP.NET Cache Spurs desempenho e escalabilidade

Iqbal Khan

Em uma visão geral:

• Redução drástica afunilamento
• Cache de Web estática e dinâmica
• Recursos deve ter: banco de expirações, dados dependência, PDF conteúdo parcial, mais
• Especiais benefícios para organizações globais
• Clusters de servidor da Web-cache
• Soluções gratuitas e comerciais

O problema: ASP.NET afunilamentos
A solução: Cache do ASP.NET
Recursos deve ter no cache de Web
Expirações
Recarregar páginas em vencimentos
Cache de página parcial
Dependência de banco de dados
Dependência de arquivo
Conteúdo parcial do PDF
Cache de ViewState
Compactação gzip
Cluster de cache de Web escalonável e dinâmica
Distribuição geográfica do cache
Permanecer fora do banco de dados
Diretrizes

Aplicativos baseados no ASP.NET, estrutura de aplicativo da Web da Microsoft, estão fazendo inroads maiores para a empresa. Ao mesmo tempo, afunilamentos resultantes do crescimento números de usuários e transações continuam a solicitar profissional de TI para chamar para melhorar o desempenho e escalabilidade.

O problema: ASP.NET afunilamentos

Afunilamentos podem ocorrer em aplicativos ASP.NET para uma variedade de motivos. O mais óbvio: tecnologia de armazenamento de dados não é tão escalonável como arquitetura de aplicativos da Web. Qualquer lugar em um aplicativo ASP.NET que lida com armazenamento de dados ou acesso a dados imediatamente se torna um logjam quando você tenta escala seu aplicativo. Duas áreas onde isso acontece são dados de armazenamento e aplicativo de estado da sessão de um banco de dados relacional ou mainframe (veja a Figura 1 ).

Figura 1 áreas comuns de desempenho afunilamentos em aplicativos ASP.NET.

Outro gargalo ocorre se seu aplicativo ASP.NET estiver fazendo orientada a serviço-SOA (arquitetura) chamadas para serviços da Web. Aqui, a diminuição acontece porque os serviços da Web tem os mesmos problemas de seu aplicativo ASP.NET (ou seja, no armazenamento de dados e acesso). As chances são que um farm de serviços da Web está sendo compartilhado em vários aplicativos e, portanto, sendo estresse muito mais do que qualquer um aplicativo ASP.NET, criando o gargalo de escalabilidade.

Afunilamentos também podem ocorrer entre o navegador do usuário e a farm da Web do ASP.NET. Esses clogs são relacionados ao fato que páginas ASP.NET precisam ser executada repetidamente em tempo de envolvendo processamento intensivo de CPU. Esse processo também envolve o envio dados pesado elementos (imagens, documentos, etc.) para o usuário novamente e novamente.

Em um anterior TechNet Magazine artigo, abordei problemas de desempenho e escalabilidade do ASP.NET, enfocando o estado da sessão e dados de aplicativo (consulte" Fornecer escalabilidade para aplicativos ASP.NET"Junho de 2009). Esse artigo, abordei como esses problemas, incluindo os motivos que o estado de sessão ASP.NET se torna um logjam um Web farm à medida que cresce. Abordei o fato de que distribuídos na memória cache é uma alternativa superior para a Microsoft é existentes a opção de armazenamento de estado da sessão ASP.NET. Descrevi como dados de aplicativo provenientes de um banco de dados podem causar afunilamentos de desempenho. Eu também detalhadas resolve cache distribuído como esses afunilamentos de armazenamento estado da sessão ASP.NET com a Ajuda das topologias de cache diferentes que cada oferece recursos diferentes, mas todos os endereços escalabilidade e garantir tempo de atividade de 100 por cento.

Finalmente, eu genericamente perfilados as diferentes opções disponíveis no mercado de cache distribuído. Algumas opções são gratuitas com recursos limitados, enquanto outros são produtos comerciais mais robustos e rico. No entanto, para obter melhor desempenho e escalabilidade, é prudente considerar produtos comerciais da parte superior de linha.

A solução: Cache do ASP.NET

Com essa definição de problema como um plano de fundo, foco principal deste artigo é desempenho e escalabilidade afunilamentos entre o navegador do usuário e o servidor Web ou Web farm. O ideal é que você deseja reduzir o número de vezes que a própria página da Web executa. Se a página da Web é executada uma vez e sua saída não está alterando mesmo rapidamente, em seguida, por que executá-lo novamente? Por que não apenas cache a saída? Em seguida, na próxima vez que um usuário pode apenas buscar saída da página diretamente do cache, em vez de re-executing-lo. Re-Executing a página envolve a CPU, consome memória e usa outros recursos de servidor Web — e, claro, há os problemas de gargalo de escalabilidade do armazenamento de dados.

Saída de uma página ASP.NET pode ser armazenada no próprio servidor Web; a Microsoft fornece o mecanismo de cache de saída do ASP.NET para permitir que você fazer isso e funciona bem. No entanto, tenho duas questões sobre o cache de saída do ASP.NET.

Primeiro, ele requer que você alterar seu código ASP.NET e, no mínimo, colocar marcas nessas páginas para indicar que você deseja armazenar em cache sua saída. Que sempre não é possível para uma pessoa IT que está gerenciando tanto desenvolvidos internamente e externamente comprados aplicativos ASP.NET. Além disso, sempre que você alterar o código do aplicativo, você deve passar por esforços de controle de qualidade para Certifique-se de que nada interrompeu no processo de. Isso aumenta o custo de incorporação de cache.

Em segundo lugar, o cache de saída ASP.NET armazena em cache saída da página local para cada servidor Web e, na verdade, dentro de cada processo do operador do ASP.NET. Isso cria problemas principais em termos de consistência e a escalabilidade se você tiver um ambiente Web (ou seja, vários processos em um servidor Web) ou um Web farm com balanceamento de carga. Nesses casos, você tem várias cópias desconectadas do cache; alto tráfego de sites, isso pode se tornar um pesadelo de gerenciamento. No ASP.NET 4.0, Microsoft é promissor uma estrutura de armazenamento em cache extensível que permitirá que você manter o cache em um processo separado ou camada incorporando um cache distribuído de terceiros.

Sabendo desse desenvolvimento, eu preferir cache de saída da página não no servidor Web, mas em um servidor cache da Web separado que se situa entre usuários e sua Web farm (tipo de como um proxy reverso; consulte a Figura 2 ). Se muita de solicitações do usuário não torná-lo para o farm da Web e é servida de um cache entre em vez disso, está reduzindo a carga em sua Web farm e aumentando a escalabilidade do farm da Web. Buscando a saída de uma página da Web do cache e retorná-lo para o usuário requerem consideravelmente menos recursos que realmente executar essa página da Web. Isso ocorre porque o cache é um armazenamento na memória de alto desempenho e escalonável, ao contrário de qualquer armazenamento em disco que pode ter problemas de desempenho e escalabilidade.

Figura 2 servidores de cache da Web colocada entre usuários e servidores Web.

Nesse contexto, discutirei como o armazenamento em cache a saída de páginas da Web pode resolver afunilamentos e aumentar consideravelmente a escalabilidade e desempenho. Um servidor de cache de Web pode executar uma função importante no atingir essas metas.

Um servidor de cache de Web intercepta as solicitações http feitas pelos usuários para páginas da Web e verifica para ver se de saída essas páginas já existe no cache. Em caso afirmativo, o servidor de cache da Web retorna que a saída para o usuário. A solicitação do usuário nunca mesmo facilita para os servidores Web. Porque está sendo procurada do cache, o retorno é extremamente rápido. E porque está na memória e a página não precisa ser re-executed, muita de processamento de CPU é salvo como bem.

Um servidor de cache de Web pode trabalhar com qualquer plataforma de tecnologia da Web de back-end. Desde que eles são todos os talking HTML e JavaScript, não importa se o aplicativo da Web é desenvolvido em Java,. NET, PHP ou alguma outra linguagem. No entanto, um servidor de cache de Web pode incluir alguns recursos específicos de plataforma, para que recursos diferem de uma solução para a solução.

Há dois tipos de soluções de cache Web. Um principalmente armazena em cache dados relativamente estáticos, que significa que todas as páginas sejam armazenados em cache é provável que ele ser totalmente estática ou para alterar intervalos previsíveis. A página inteira é armazenada em cache por um determinado período de tempo, após o qual expira e é removida do cache. O outro tipo é para o cache dinâmicos, que é mais apropriado para sites da Web dinâmicos ou aplicativos da Web.

Se seu aplicativo Web ou site da Web for dinâmico, onde dados são alterados com freqüência e imprevisível, em seguida, você deve optar por cache dinâmicos. Esses dias, a maioria dos sites alterar pelo menos alguns dos seus conteúdos com freqüência. Você deve ser capaz de armazenar em cache algo como pouco como 15 a 30 segundos, mas normalmente para qualquer lugar de alguns minutos a algumas horas — e, em alguns casos, para dias ou até mesmo semanas.

Cache da Web oferece uma vantagem importante para grandes empresas em todo o mundo: a capacidade de geograficamente dispersar servidores cache Web. Em uma organização global, seu aplicativo do site principal pode ser hospedado em são Paulo, mas ter usuários em todo o mundo — em são Francisco e Londres e Tóquio e Sydney e Dubai. Agora é relativamente fácil para que servidores cache Web geograficamente localizados em cada uma dessas áreas. Todas as solicitações provenientes Europa passará pelo servidor de cache de Web Europa antes de eles visita seu site da Web. Dessa forma, eles não precisam cruzar Oceano Atlântico e incorrer em que a latência 100 milissegundos que cada pacote deve percorrer. Eles basicamente podem obter uma cópia de um cache próximo.

Vamos dar outro exemplo. Você tem um servidor em Dubai servindo as regiões do Oriente Médio e Ásia do Sul e você tem centenas de milhares de usuários atingindo seu site da Web simultaneamente. Com cache Web, o tráfego para o Centro de dados principal em são Paulo cairá significativamente. Não todo o tráfego é interrompido porque não cache tudo, e o cache também é removido do cache (que é, invalidado) em momentos. Mas, dependendo da natureza de seu aplicativo, você provavelmente já reduzido o tráfego em 30 a 50 por cento.

Recursos deve ter no cache de Web

Com o passar do tempo, sites ter transformado de mostrar somente conteúdo estático para se tornar aplicativos Web totalmente interativos com dados dinâmicos que muda com freqüência. Isso significa que, hoje em dia, um cache da Web deve atender todos os requisitos de um site dinâmico. O objetivo é cache tantos do site da Web conteúdo possível, enquanto ao mesmo tempo garantir que o conteúdo em cache esteja correto e não obsoletos ou fora de sincronização com os dados subjacentes no banco de dados. Para tratar de tudo isso, o cache da Web precisa certos recursos para evitar problemas de integridade de dados ao aumento de desempenho e escalabilidade.

Uma solução de cache da Web típica inclui os seguintes recursos.

Expirações

Capacidade de expiração permite que você especificar regras sobre quais páginas da Web para cache e por quanto tempo. E permite que você expirar páginas em tempo absoluto ou deslizante. Hora absoluta significa que você vai expirar algo em um determinado momento, se é meia-noite hoje ou 10 minutos de agora. Deslizar tempo depende se uma determinada página constantemente está sendo acessado. Se uma página não estiver sendo acessada — se ele não está sendo usado em todos os — talvez você queira expirá-lo. Um tempo ocioso deve expirar uma página se ele não usado por mais de um determinado período de tempo — por exemplo, 10 ou 20 minutos.

Absoluto-tempo de expiração é provavelmente o mais importante tempo de expiração para páginas da Web. Produtos de armazenamento em cache da Web permitem que você especificar regras e escolher quais padrões de URL (conhecido como "URI") para armazenar em cache. Cache de Web permite que você especificar que determinadas URLs devem nunca ser armazenada em cache. Ele permite que você especificar determinados tipos de URLs para cache para um determinados comprimentos de tempo.

Ele também deve permitem que você especificar quando expirar várias URLs baseados nas informações fornecidas nos cabeçalhos HTTP que vem com a saída de URL. Cabeçalho HTTP de cada página pode conter informações sobre quanto tempo ele pode ser armazenado em cache, quando ele expirar e quando foi alterado pela última vez. Esses são os itens do cache pode verificar para monitorar se um conteúdo da página foi alterado e se ele precisa carregar o novo conteúdo no cache de Web. Sem esse recurso, você não tenha uma maneira para invalidar e remover dados obsoletos.

Recarregar páginas em vencimentos

Outro recurso importante é poder recarregar automaticamente uma página quando ela expira por qualquer motivo, se devido à expiração absoluta ou tempo ocioso. Por exemplo, você pode dizer: "Esta página é bom para os próximo 20 minutos." Após 20 minutos, o cache de Web re-fetches automaticamente a página para que ele sempre tenha a cópia mais recente.

Dessa forma, você não esperar para a próxima solicitação do usuário para essa página. Isso ocorre porque quando a solicitação chega, você não deseja que o usuário passar o atraso para buscar novamente a página de Web farm. Porque você pode buscá-lo no plano de fundo, talvez seja necessário você 5 a 10 segundos para buscá-lo do servidor Web executando primeiro. Mas que tudo bem, porque quando que o usuário obtém a ele, você será capaz para retorná-lo com tempo de resposta sub-second, dependendo como distante o usuário é.

Cache de página parcial

Algumas das páginas que aparecem em um navegador contêm vários itens que cada um tem suas próprias URLs. Portanto, para uma página a ser processado, o navegador da Web deve chamar várias URLs. Isso obtém o mesmo resultado como uma página parcial — mas ele não é chamado "página parcial" porque no lado do servidor, cada URL representa uma página separada e cada página é armazenada em cache independentemente e para uma duração diferente, dependendo da natureza de seu conteúdo.

Em outras situações, uma Web única página é desenvolvida como uma maneira que seu conteúdo é dividido em seções. Algumas seções são estáticas e não são alterados; algumas partes são dinâmicos, com cada parte alterar após um intervalo diferente. Na verdade, seções de página caches cache de página parcial baseiam se eles são estáticos ou dinâmicos e para quanto eles deverão ficar em cache, em vez de apenas cache a página inteira.

ASP.NET permite que você faça cache de página parcial por dois meios: cache de controle e substituição pós-cache. Ambas exigem que você modificar as páginas ASP.NET específicas onde você deseja fazer esse cache. Que talvez não seja possível se você não tem seus próprios recursos de desenvolvimento e você não desenvolver este aplicativo de ASP.NET interno. No entanto, segue uma descrição de cada tipo de cache de página parcial no ASP.NET.

Você pode fazer cache de página parcial no ASP.NET, criando controles de usuário para conter o conteúdo em cache e marcando os controles de usuário "armazenáveis em cache." Isso permite que você cache algumas partes da página como controles de usuário para que quando a página é re-executed, essas partes são simplesmente obtidos do cache e não re-executed. Somente as partes da página que não estão designadas como controles de usuário e não são marcadas como "armazenáveis em cache são re-executed."

Com a substituição pós-cache, a página é armazenada em cache, mas algumas partes ou fragmentos dentro dela serão marcados "dinâmico" ou "não armazenáveis em cache." Em seguida, quando esta página está re-executed, somente as partes dinâmicas ou não armazenáveis em cache, na verdade, são executadas. O restante da página é obtido do cache e partes em cache e dinâmicos são combinados para retornar a saída da página.

Curiosamente, cache de página parcial só pode ser executado no servidor Web. Por esse motivo, é necessária alguma programação. No caso do ASP.NET, cache de página parcial é feito por programação em páginas ASP.NET para determinar o que — e que não — para armazenar em cache. Mas esse cache é executado no próprio servidor Web e ainda executa a página ASP.NET, pelo menos partes dele.

No ASP.NET, cache de página parcial é implementado com base em especificação da Microsoft, mas na plataforma Java, uma página parcial cache padrão chamado borda serviço inclui (ESI) surgiu. ESI define uma linguagem de marcação simples baseada em XML que define armazenáveis em cache e não armazenável componentes de página da Web que podem ser agregados, montados e entregue na borda de rede, se estiver em uma rede de entrega de conteúdo, o navegador do usuário final ou um servidor de cache da Web que atua como um proxy reverso entre navegadores dos usuários e o servidor Web.

Assim, o cache de página parcial é específico da plataforma altamente — e, obviamente, para o ASP.NET, você deve usar abordagem da Microsoft.

Dependência de banco de dados

Outro recurso de chave é a dependência de banco de dados, que permite que uma página de saída sejam invalidados do cache quando correspondente dados as alterações de banco de dados. De saída as páginas com freqüência é gerada com base nos dados no banco de dados. Os dados que eles são ilustrando vêm de uma ou mais linhas em uma ou mais tabelas de banco de dados. Portanto, se alterar as linhas, essas páginas devem ser removidas do cache. Por esse motivo, a sincronização do banco de dados é um recurso importante. Isso significa que quando dados são alterados no banco de dados, de saída essas páginas deve ser invalidada e deve ser removida do cache. Esse recurso permite que você determinar automaticamente quando determinadas páginas devem ser removidas do cache.

Uma maneira de criar essa dependência é especificando uma instrução "select" SQL (ou uma chamada de procedimento armazenado que contém uma instrução select) que corresponde à página em questão, em seguida, mapeamento de alguns dos parâmetros página GET/POST com parâmetros na instrução SQL. Em tempo de execução, os parâmetros de página da Web são usados para executar a instrução SQL e um SqlCacheDependency é criada em relação a um SQL Server 2005/2008 ou Oracle 10 g R2 ou posterior do banco de dados. Em seguida, quando a linha correspondente no banco de dados é alterado, o servidor de banco de dados dispara um evento .NET que é capturado pelo servidor de cache da Web. Em seguida, a página da Web correspondente é removido do cache de saída (consulte a Figura 3 ).

Figura 3 página removido do cache da Web se banco de dados linha alterações.

Dependência de arquivo

Outro recurso de chave é a dependência de arquivo. Você pode associar uma saída de página com um arquivo no sistema com as instruções: "Se este arquivo já é atualizado ou removido, por favor invalidar esta página." Em seguida, o cache de Web monitora nesse arquivo, que é mantido em uma pasta compartilhada. Se esse arquivo nunca é atualizado ou removido, o cache de Web invalida automaticamente a URL correspondente do cache. Isso permite atualizar que o arquivo em qualquer lugar em seu sistema, se ela envolve a outro aplicativo ou até mesmo um disparador no servidor de banco de dados com base em quando alguns relacionados a alterações de dados. Por exemplo, se seus dados estiverem armazenados em um mainframe em vez de em bancos de dados Oracle ou SQL 2005/2008, você pode usar uma dependência de arquivo para invalidar uma cache de página.

Todos os isso lhe permite notificar o cache quando invalidar se certas coisas ocorrem no seu armazenamento de dados ou no seu ambiente, que não estão diretamente acessíveis pelo cache Web.

Conteúdo parcial do PDF

Agora, muitas pessoas acessar arquivos PDF on-line. O padrão de uso comum é que eles leia uma página por vez, passar pelo arquivo PDF inteiro página por página. Algumas pessoas baixar um PDF inteiro e lê-lo localmente; mais lê-lo em seus navegadores. Quando eles estiver exibindo as informações dessa maneira, eles normalmente não leiam todo o documento; eles abandonar depois de obter por meio de parte dele.

Assim, que atende o PDF inteiro geralmente é um desperdício de recursos; na verdade pode ser o fator de diferenciação entre desempenho aceitável e inaceitável durante horários de pico. Por esse motivo, a manipulação de conteúdo parcial do PDF é um recurso importante em um cache da Web. Ela reduz a carga de largura de banda no servidor Web e melhora a escalabilidade geral.

Cache de ViewState

Entre os recursos mais importantes do ASP.NET é a capacidade para declarar controles que são executados no servidor e post-back para a mesma página. Antes para ASP.NET, no ASP clássico, você terminou a criação de várias páginas para manipular operações diferentes que pertenciam logicamente, a uma página — por exemplo, carregar dados, salvar os dados ou executar outras ações. Mas no ASP.NET, você não precisará fazer isso. Campos de formulário e outros controles agora podem ser declarados a executar o servidor e o servidor simplesmente envia a página para si mesmo.

Para lidar com esses post-backs, um ViewState é criado que lembra a identidade de qualquer informação dinâmica atribuídos a esses controles e os controles. Em essência, ViewState preserva o estado dos controles da página entre várias postagens.

ViewState é importante para aplicativos ASP.NET. Essencialmente, ele informações enviadas pelo servidor Web para o navegador para que o navegador possa enviar as mesmas informações de volta para o servidor o próximo usuário tempo faz uma postagem para a mesma página.

Por exemplo, você pode carregar um cliente na página customer.aspx. Em seguida, você faça algumas alterações nos dados de cliente e clique em "Salvar". No botão Save chama novamente customer.aspx, mas também envia o ViewState para que o customer.aspx sabe como manipular esse post-back. O ViewState contém as informações que customer.aspx tinha enviadas para o navegador e o post-back contém os dados novos que o usuário talvez tenha modificado. Que permite que customer.aspx determinar o que foi alterado e o que fazer sobre ele. Isso é apenas um exemplo simples; ViewState também pode conter outros dados criados dinamicamente para cada controle na página.

Embora ViewState seja extremamente útil no ASP.NET, ele também executa custo de transferência de dados e para trás de um servidor Web para o navegador do usuário. Esse custo poderia ter um desempenho e escalabilidade impacto durante os picos de carga do aplicativo e quando os usuários são longe do servidor Web e através de uma lenta conexão de Internet.

Mas o ViewState geralmente não precisa passe todo o caminho para o navegador se ele pode ser armazenado no cache de Web. Nesse caso, somente uma marca ou uma identificação exclusiva poderia ser enviada para o navegador para que se o navegador voltar, o cache de Web seria novamente um ViewState e dá-lo de volta para o servidor Web com base na identificação exclusiva. Todos os uma Web requer o servidor é que na próxima vez que o navegador envia a solicitação, ele contém o ViewState desde o momento anterior. Não importa se o ViewState atinge o navegador porque o navegador usa essas informações nunca — apenas o servidor Web faz.

Em termos técnicos, um ViewState é usado para post-back, se você fizer nunca post-backs, será necessário um ViewState, e um cache de Web pode armazenar um ViewState em cache. Que também economiza largura de banda considerável, porque um ViewState pode ser apenas algumas KB em tamanho.

Compactação gzip

Esses dias, a maioria dos navegadores pode descompactar conteúdo compactado gzip. Mas não todos os servidores Web são configurados para compactar automaticamente a saída de páginas de Web. E mesmo se a compactação está ativada, ele consome muita desnecessária CPU em cada servidor Web, que já está sendo estresse pelo tráfego de alto. No entanto, se a compactação é feita por um servidor de cache Web proxy intermediário, fica mais escalonável.

É mais fácil compactar dados estáticos que nunca é alterada. No entanto, a maioria das páginas em um aplicativo ASP.NET são dinâmicos e seu conteúdo deve ser compactado somente se a saída da página não estiver alterando sempre. Caso contrário, a compactação deve colocar uma carga inaceitável na CPU, talvez dwarfing ganhos no uso de largura de banda. Mas como um cache de Web já é inteligente sobre descobrir qual saída de páginas dinâmicas é armazenáveis em cache (significado que não altere pelo menos um breve período de tempo), também é capaz de compactar automaticamente as páginas de cache. Em seguida, essas páginas em cache são fornecidas para os clientes várias vezes na forma compactada e reduzido consideravelmente o uso de largura de banda.

Uma típica gzip a compactação reduz o conteúdo em quase 80 %, a menos que o conteúdo já está compactado (por exemplo, PDF, JPEG, TIFF, etc.). Um boa cache da Web deve permitir que o usuário especifique quais URLs para compactar e que a ignorar para compactação.

Cluster de cache de Web escalonável e dinâmica

Um cache da Web é um servidor que fica na frente de um farm da Web do ASP.NET (quase como um dispositivo). Hoje em dia, farms da Web ASP.NET podem crescer de dois servidores para 100-plus servidores com um balanceador de carga. Portanto, um único servidor de cache da Web é incapaz de manipular a carga de um Web farm crescente. Uma boa regra prática é que para cada cinco servidores de Web no farm, você deve ter um servidor de cache de Web.

Ter vários servidores de cache da Web não somente melhora a escalabilidade, mas também permite que o cache de Web para replicar para que se qualquer um servidor for desligado ou é levado para baixo, o cache não é perdido e não há nenhuma degradação de desempenho (consulte a Figura 4 ).

Figura 4 cluster de cache de Web dinâmico (Adicionar ou remover servidores em tempo de execução).

Um bom servidor de cache da Web deve ser capaz de criar um cluster de servidores de cache de Web para manipular confiabilidade através da replicação e a escalabilidade por meio de vários servidores. No entanto, muitos cache-servidores Web estão envolvidos, ele ainda é considerado um cache de Web lógico. Mesmo se houver várias cópias do cache do cluster, eles sempre está mantidos sincronizados. Em resumo, com um cluster de servidores de cache de Web permite que você dimensionar mantendo a correção lógica do cache.

Quando você tiver um cluster de cache, um cache de Web boa deve permitem que você especificar diferentes opções armazenar em cache, também conhecidas como cache topologias. As topologias principais incluem cache replicado, cache particionado e cache de cliente.

Replicado cache significa que todo o cache é copiado para cada servidor de cache no cluster. Como resultado, cada servidor de cache tem todo o cache. Todas as operações "get" sempre são locais para essa caixa e, conseqüentemente, são muito rápidas. No entanto, as atualizações são feitas em vários servidores de cache e se houver mais de dois servidores no cluster, o custo de atualização cresce.

Por outro lado, cache particionado quebras de (ou partições) cache, o armazenamento de cada partição em um servidor diferente do cache. O número de partições é igual o número de servidores de cache. Isso permite que você aumente a capacidade de armazenamento de cache adicionando mais servidores de cache, que você não pode fazer no cache replicado. Cache de partição também permite criar backups de cada partição em um servidor de cache diferentes para que se qualquer um desses servidores falhar, você não perca o cache. Cache de partição é a topologia de cache mais escalonável para armazenamento e transações por segundo.

Finalmente, o cache de cliente é uma topologia que é combinada com particionados ou cache replicado (especialmente se o cache real estiver hospedado em um servidor diferente do servidor de cache da Web). Cache de cliente mantém um pequeno subconjunto do cache dentro do processo de cliente para que os dados usados com freqüência estejam sempre disponíveis feche por. O que é mantido no cache de cliente depende de que esse cliente obtido recentemente. Você pode especificar um tamanho máximo para o cliente de cache para quando ela atinge esse tamanho, ele começa a remover (ou remover) itens antigos para liberar espaço para novos. Dessa forma, o cache de cliente nunca consome mais memória que você determinou é viável.

Se você usar vários servidores de cache da Web sem criar um cluster de cache, você acabará com várias cópias desconectadas do cache. Esse resultado pode ser aceitável se seu site é relativamente estático, mas para sites da Web dinâmicos e aplicativos ASP.NET, que podem causar problemas de integridade de dados. Além disso, você acabará enviando a solicitação do usuário para o servidor Web, mesmo que outro servidor de Cache Web possui a saída desta página no cache, aumentando assim a carga na farm da Web do ASP.NET.

Distribuição geográfica do cache

Muitos aplicativos ASP.NET sites da Web hoje têm usuários em todo o mundo, mesmo que o site próprio é hospedado em um único local. Geralmente, é impossível para o site a ser localizado em vários locais geográficos devido a complexidade e o custo de sua infra-estrutura. Por exemplo, um farm da Web do ASP.NET também deve ter um servidor de banco de dados no mesmo local; servidores de banco de dados não são geralmente ideais para distribuição geográfica quando eles envolvem aplicativos altamente transacionais. Como resultado, os usuários finais enfrentar desempenho lento devido a latência da wide area network (WAN, rede de longa distância).

Uma maneira para corrigir esse problema é colocar servidores de cache da Web em cada localização geográfica, circular, em seguida, todo o tráfego a partir dessa área através do servidor mais próximo do cache da Web (consulte a Figura 5 ). Em seguida, se um servidor de cache da Web não tiver uma página já armazenada em cache, ele diretamente envia a solicitação ao Centro de dados principal, onde outro conjunto de servidores de cache da Web está localizado.

Figura 5 geograficamente distribuídos servidor de cache da Web no ambiente.

Portanto, um boa cache da Web deve ter a capacidade de criar uma hierarquia de servidores para que cada cache de Web sabe onde rotear a solicitação, mesmo se não tiver a página armazenada em cache.

Permanecer fora do banco de dados

Conforme discutido no meu artigo de junho de 2009, dados não alterar sempre; ele permanece constante. Infelizmente, sem cache distribuído, você vai por meio de ciclos desnecessários para reproduzir esses mesmos dados repetidamente. Mas você não precisa ir para o banco de dados o tempo todo. É que os mesmos dados, portanto, por que vá existe? Por que não colocá-lo do cache?

Aqui está um exemplo para realçar o problema. Página da web principal de uma companhia aérea não estiver alterando muito; ele pode ser armazenado em cache por um longo tempo. Um cliente visita para procurar vôos. As informações é constantemente deslocando porque como outros usuários catálogo assentos, altera as informações no back-end.

Se o cliente está procurando, digamos, um vôo de Nova York a San Francisco, a disponibilidade de estação determina os resultados. Estação disponibilidade se baseia o número de pessoas já reservados com reservas acontecendo constantemente. Uma executiva harried pode complicar, inserindo informações incorretas ou escolhendo várias entradas para garantir que uma atribuição de estação.

O usuário recebe resultados indicando que um determinado vôo está disponível, com essas informações alterando no cache a cada cinco minutos. Mas depois que o cliente realmente deseja reservar uma estação, uma verificação em tempo real é realizada no banco de dados. Isso ocorre porque para cada 1.000 pessoas Verificar disponibilidade de vôo, provavelmente somente cerca de 10, na verdade, faça uma reserva. É ótimo Mostrar disponibilidade de vôo para esses visitantes, mesmo que as informações fornecidas não podem ser totalmente corretas. Em tais situações, você pode cache dessa página, mesmo se for altamente dinâmico.

Mas você pode armazenar cache com a idéia de que é aceitável para fornecer informações com algum risco que não é completamente preciso. No entanto, na página reservas no banco de dados, é importante garantir que todas as informações sejam precisos e atualizados. O ponto aqui é que cada aplicativo tem informações comuns que podem ser armazenados em cache e um usuário do site da Web não precisa ser enviadas para banco de dados a companhia aérea cada vez.

O estágio mais fácil é quando você deseja armazenar em cache todas as imagens. Você não alterar o logotipo da empresa ou o presidente imagem ou documentos padrão que você tem disponíveis para pessoas ler. Mas há outras partes que são mais dinâmicos. Isso é onde você pode especificar regras e digamos, por exemplo, "deseja armazenar em cache esta página para essa longa."

Com outras páginas, você pode dizer, "não é possível saber quanto tempo vai ser armazenada em cache, para o qual Desejo vinculá-lo para o banco de dados. Se esta linha nessa tabela for alterado, Quero que esta página para ser invalidado." Isso significa que removê-lo do cache e recarregar a ele, fazer uma nova cópia. Cada categoria de página é diferente. Desde que um cache de Web permite que você determine como você deseja em páginas de cache, você está criando uma situação em que quanto mais você armazenar em cache, a menos você vá para a Web farm.

Diretrizes

Na maioria dos casos, você pode obter benefícios significativos ao implantar o cache da Web. Se você tem apenas um servidor Web, provavelmente que você não tem suficiente tráfego para experimentar esses tipos de problemas. Mas se você tem 1.000 ou mais usuários, você provavelmente já ter uma Web farm com balanceamento de carga. Nesse caso, você é um candidato para explorando maneiras de otimizar o desempenho e escalabilidade.

Planeje com antecedência. Não espere problemas ocorrem porque quando isso acontecer, você vai estar no modo panic. O melhor momento é quando não estão enfrentando problemas principais — mas nesse ponto, você deve ser capaz convencer gerenciamento superior sobre por que você precisar de financiamento para tal um projeto. Uma boa maneira de atingir esse objetivo: gerenciamento de fazer o que ele pode custo sua empresa se seu site da Web fornecido tempos de resposta lento lamentavelmente durante horários de pico (upward de 30 a 60 segundos por clique). E se o seu site da Web foi desativado para 30 a 60 minutos? Considerar essas perguntas pode ajudar a convencer os executivos da sua organização sobre a necessidade de um cache da Web.

Como observado anteriormente, livre e comercialmente cache Web opções estão disponíveis. Com popularidade crescente do ASP.NET entre os desenvolvedores, comerciais opções de cache de Web que oferecem suporte a .NET são agora emergentes. No entanto, quando este texto, a maioria dos produtos de cache Web oferecem suporte Java e PHP. A maioria é baseado em software, mas algumas opções de dispositivo de hardware também estão disponíveis.

Como você considerar as opções, permanecem concentrado na sua organização e site. Como dinâmico é o site? Como muitos usuários você tem? Quanto cache será realmente ajudá-lo?

Em seguida, considere que recursos de cache que você precisa. À medida que discutimos, cache faz transações blazingly rápidas e escalonáveis. Mas ele às vezes pode dar aos usuários informações desatualizadas. Tenha que saldo em mente como você considerar várias soluções.

Iqbal Khan é o presidente e especialista de tecnologia de Alachisoft. Alachisoft fornece NWebCache, que é um cache ASP.NET à esquerda para acelerar o desempenho e escalabilidade. Iqbal recebeu um M.S. grau em Ciências da Universidade de Indiana, Bloomington, em 1990. Você pode entrar no iqbal@Alachisoft.com.