Infra-estrutura da Web
Fornecer escalabilidade para aplicativos ASP.NET
Iqbal Khan
Visão geral:
- Afunilamentos de desempenho em aplicativos ASP.NET
- Opções de armazenamento de estado de sessão
- Topologias de armazenamento em cache disponíveis
- Recursos de cache distribuído necessário
Conteúdo
Onde estão os problemas
Por que esses problemas existem
Qual é a resposta?
Topologias de cache
Opções diferentes
O mundo real
A popularidade do ASP.NET, a estrutura de aplicativo da Web da Microsoft, continua a crescer por leaps e limites dentro do desenvolvedor, empresa e classificações IT. Há uma área de dificuldade, no entanto: dimensionamento aplicativos ASP.NET fora da caixa simplesmente não é possível.
Escalabilidade tem dois significados neste contexto. Primeiro, você precisará ser capaz de manipular efetivamente picos de carga de usuário porque cada aplicativo passa por picos e vales em termos de número de usuários registrados em qualquer ponto no tempo. Quando você cria a infra-estrutura, você deseja criar o aplicativo para que ele pode manipular picos de carga como com eficiência e tão rápido como nonpeak cargas.
Segundo, você precisa conseguir aumentar a capacidade total do sistema. Hoje talvez seja necessário apenas 5,000 usuários. Seis meses, um ano para baixo de viagem, talvez seja necessário 10.000 15.000 ou 20.000, e em alguns anos você poderia terminar com 100 mil usuários. Ser capaz de crescer com o número de usuários sem retificadores o aplicativo parar é que escalabilidade todos sobre. Isso significa que você não conseguir adicionar mais usuários sem afetar negativamente o desempenho de qualquer forma notável ou, se houver qualquer degradação, deve ser em um intervalo aceitável.
Um aplicativo ASP.NET comum é implantado em um ou mais servidores Web que estão vinculados juntos em um Web farm, com um balanceador de carga que distribui o tráfego para todos os servidores da Web. Em teoria, os servidores Web mais adicionar, as solicitações de mais será capaz de processar por segundo. A arquitetura de uma Web farm tem como objetivo fornecer escalabilidade para ASP.NET. Isso é a teoria; a realidade é um pouco diferente.
O problema para aplicativos ASP.NET é que enquanto tecnologia da Web fornece uma arquitetura elegante de Web farms e balanceadores de carga, tecnologias de armazenamento de dados não têm mantidos até. Certamente, você pode dimensionar em um aplicativo da Web adicionando mais servidores ou aumentando o nível de servidores individuais com mais memória e potência da CPU.
Mas como você faz que, armazenamento de dados não é capaz de escala nas mesmas proporções. Dimensionar, mas não como bem como a camada de aplicativo da Web. Conseqüentemente, nada no seu aplicativo ASP.NET associado a armazenamento de dados ou o acesso a dados é um gargalo de escalabilidade potencial. Mais para o ponto, um servidor de banco de dados não é dimensionada para dados de sessões ou aplicativos.
Onde estão os problemas
Vamos dar uma olhada nas ações acesso ou armazenamento diferentes que ocorrem dentro de um aplicativo ASP.NET, começando com o armazenamento de sessão. Para cada solicitação de usuário, uma sessão é ler o armazenamento no início e gravada novamente o armazenamento no final da resposta. No início da solicitação do usuário, a página tem que executar e, para isso, ele precisa os dados da sessão. Os dados de sessão inteira, chamados "objeto de sessão", são carregados para que a página, enquanto ele é executado, pode consultar os dados. A página lerá alguns dos dados do objeto de sessão. Ele colocará alguns dados mais para o objeto de sessão. Tudo isso acontece no processo do ASP.NET e sem viagens de armazenamento de sessão estão sendo feitas.
Quando a página é feita em execução, alguns resultam precisa ser enviado novamente para o usuário. A sessão provavelmente é atualizada durante esse tempo para que agora sessão tem sejam salvos de volta para o armazenamento. Ele será mantido armazenados até a próxima solicitação do usuário para a mesma sessão e o mesmo processo se repete.
Da perspectiva de um usuário, clique em um link; quando que o usuário visualiza a página que resulta nesse link, uma sessão foi lida e uma sessão foi escrita volta para o armazenamento de uma vez. Portanto, há dois viagens para um armazenamento de sessão que fez o aplicativo ASP.NET.
Agora você pode fazer o cálculo. Se você tem 10.000 usuários todas as páginas de acesso ao mesmo tempo, você terá talvez 1.000 solicitações por segundo. Todos os usuários serão clicar algo cada poucos segundos, portanto, a cada segundo que você terá menos de 1.000 e provavelmente mais as solicitações vai o farm da Web.
Digamos que 1.000 ou mais solicitações forem Web farm e cada solicitação vai os resultados de servidor da Web em dois viagens para o armazenamento de sessão. Da perspectiva da Web, que significa 2.000 viagens para o armazenamento de sessão. Você pode ver rapidamente como a carga pode aumentar. Este é um local que pode acontecer um gargalo de escalabilidade.
Afunilamentos de desempenho também podem acontecer enquanto uma página está sendo executado e precisa ler ou gravar alguns dados de aplicativo. Vamos usar companhia aérea vôo disponibilidade como exemplo. O usuário clica em uma página para procurar vôos de um local para outro, que podem resultar em várias viagens de leitura para o banco de dados do aplicativo. Em seguida, obviamente, o usuário quer fazer uma reserva de vôo, que requer alguns dados ser colocados no banco de dados. Esses dados são chamados "dados de aplicativo" e ele é armazenado no banco de dados; essa operação de salvamento pode fazer várias viagens de banco de dados para armazenar vários elementos de dados.
Assim, você poderá, no final, eólica backup com o número de viagens de banco de dados sendo 5, 10, 15 ou 20 vezes mais do que o número real de solicitações do usuário. Portanto, a sobrecarga no banco de dados é que muito mais e isso pode ser um afunilamento principal.
Um gargalo de escalabilidade terceiro vem sobre se você estiver usando um ambiente de SOA (arquitetura orientada por serviços) e seu aplicativo está fazendo chamadas para outra camada de serviço, que pode ser em seu data center ou em um centro de dados diferentes.
A arquitetura de camada do servidor normalmente envolve um farm de servidores e, portanto, é escalável da mesma maneira que é arquitetura de aplicativos da Web. Mas a camada de serviço tem os mesmo afunilamentos de escalabilidade do aplicativo porque ele depende de seu próprio banco de dados.
Portanto, seu aplicativo tem dependências em outros serviços, que têm dependências em seus bancos de dados, que por sua vez têm afunilamentos de desempenho, e a cadeia só é tão forte quanto seu vínculo mais fraco. Se um serviço não se adapta devido a seu banco de dados, seu aplicativo não é possível dimensionar (veja a Figura 1 ).
A Figura 1 O banco de dados se tornará um afunilamento de Web farm à medida que cresce.
Realmente não importa se o banco de dados é um mainframe ou um banco de dados relacional. O acesso a dados ou o armazenamento de dados simplesmente não é capaz de escala, e ele não é possível manter ritmo com a escalabilidade da tecnologia da Web. E essas gargalos no armazenamento de dados impedir que aplicativos ASP.NET de dimensionamento.
Por que esses problemas existem
Por que o armazenamento de dados não é possível dimensionar? Vamos primeiro lidar com as três opções de armazenamento de estado de sessão a Microsoft fornece: InProc, StateServer e SqlServer. InProc tem limitações. Ele foi projetado para ser usado em um ambiente de servidor único, o único processo, e ele não funciona em um ambiente de ASP.NET multi-servidor ou multi-process. A sessão não é retida.
Eis o que acontece. O usuário inicia em um servidor e a sessão é criada. Se o balanceador de carga, em seguida, enviar o usuário para um servidor diferente, o aplicativo não encontrar a sessão; ele será acha que o usuário está iniciando nova e pergunte a fazer logon novamente. Sempre que um usuário clica sobre qualquer tema, ela terá que fazer logon para que ela não possa continuar. O aplicativo não funcionará.
Uma maneira é possível resolver isso é usando o recurso "sessões de auto-adesivas", que permite que você sempre roteiro a solicitação do usuário de volta para o mesmo servidor para que o aplicativo irá encontrá a sessão no servidor.
Você também pode manipular InProc limitações, não criar um ambiente Web no servidor. Um ambiente Web é quando seu aplicativo tiver vários processos do operador ASP.NET em execução no mesmo servidor. Se você evitar usando um ambiente Web, há somente um processo e que permite que menos InProc a ser usado em uma Web farm.
Essas duas soluções são longe de ideal, no entanto. Sessões de auto-adesivas podem causar um gargalo de desempenho principais porque a carga em alguns servidores aumenta mais do que outros usuários porque a duração de uma sessão de usuário não é uniforme. Alguns usuários logon por apenas um minuto, outras pessoas para 20 minutos. Alguns servidores terá muita de sessões, mas os será praticamente vazio livre ou ocioso. Mesmo se você adicionar mais caixas, é não necessariamente melhorar a taxa de transferência.
Além disso, InProc tem limitações de memória. Cada sessão do processo de ASP.NET requer memória. À medida que você aumenta o número de sessões, os requisitos de memória do processo de operador aumentar significativamente. Em uma plataforma de 32 bits, no entanto, há um limite de memória de 1 GB para que um processo de trabalho, e que é um problema. Você não é possível aumentar os dados da sessão fora o que couber em uma memória de processo de trabalho de um gigabyte, junto com outro código de dados e aplicativos. Portanto, InProc faz afunilamentos. E mais usuários que você tem, quanto mais você encontrará esses problemas.
StateServer armazena o estado da sessão em um processo que é separado do processo de trabalho do ASP.NET, mas também tem limitações. Você pode configurá-lo para que cada servidor da Web contém seu próprio StateServer ou você pode dedicar uma caixa separada e manter o estado completamente nessa caixa.
Com a primeira opção, o problema é que ainda é necessário usar sessões de auto-adesivas. Sempre que a sessão foi criada, é onde você sempre precisará voltar para ele. Esta primeira opção apenas reduz a limitação de ambiente Web InProc. Ele não resolver o problema sessões de auto-adesiva pode deixar você com caixas adicionais que não usadas, mesmo enquanto outras pessoas estão obstruídas. O efeito líquido para o usuário é que seu tempo de sessão e a resposta se tornar extremamente lento.
Essa opção de configuração a outra desvantagem é que se qualquer servidor Web for desligado, o StateServer em que caixa de servidor da Web também ficar inativo, para que você perca essas sessões. True, você não perderá todas as sessões em um site da Web, mas você perder todas as sessões armazenadas nessa caixa de, e isso não é aceitável. O ideal é que você nunca deseja perder todas as sessões.
Se você escolher a outra configuração de ofertas de StateServer — uma caixa StateServer dedicada — você não precise usar uma sessão de auto-adesiva, pois cada servidor da Web vai para a mesma caixa dedicada. Mas agora você tem um problema maior: se essa caixa já for desligado, o farm de Web inteiro é o para baixo porque cada servidor Web está tentando obter sua sessão de caixa.
Isso não é tudo. Esta caixa StateServer dedicada fica sobrecarregada conforme são adicionados mais servidores Web e transações por segundo aumentem. Conseqüentemente, rapidamente torna um gargalo de escalabilidade. Portanto, o problema de desempenho não é resolvido com StateServer, não com qualquer configuração.
Agora estamos venha SqlServer, que armazena o estado da sessão em um banco de dados do SQL Server e pode ser considerados um StateServer dedicado. Este é servidor de banco de dados principal da Microsoft projetado para ambientes de alta transação. É mais escalonável que um StateServer porque você pode criar um cluster de servidores de banco de dados.
Conectar-na configuração do SqlServer, todos os servidores da Web, na verdade, se a uma dedicado SqlServer caixa onde todas as sessões são armazenadas. É como se cada um dos servidores da Web estivesse conectado a uma caixa StateServer dedicada. O conceito por trás isso é que SqlServer sejam mais escalonável que um StateServer. Mas SqlServer não é tão rápido quanto um servidor de estado porque um StateServer é um armazenamento de dados na memória e da mesma forma, possui desempenho aceitável. Por outro lado, SqlServer não é um armazenamento de dados na memória. Ele é um armazenamento de dados baseados em disco. Todos os bancos de dados são mantidos no disco porque eles crescem tão grandes que a memória insuficiente armazenar o banco de dados inteiro. Portanto, um banco de dados armazena os dados no armazenamento persistente, que é um disco. Devido a armazenamento em disco, o desempenho do SqlServer não é mais rápido, resultando em uma queda de desempenho.
SqlServer pode vir em várias configurações. Em uma configuração autônoma, que é o mais comum, há apenas um servidor de banco de dados que falar com todos os servidores da Web e à medida que aumentar o tamanho do Web farm e adicionar mais servidores Web, você colocar mais carga no banco de dados (consulte a Figura 2 ).
A Figura 2 sessões ASP.NET ainda um gargalo e o banco de dados também não fullyscalable
Além disso, você tem um problema de desempenho porque SqlServer não esteja baseado em memória, e você tem um problema de escalabilidade porque não é possível dimensionar o máximo. Você pode dimensionar, tornando o hardware mais poderoso adicionando CPUs dessa caixa, mas você não pode manter adicionando mais caixas de servidor do banco de dados à medida que crescem o farm da Web. Você talvez pode ir de um a dois ou de duas a três servidores para que SqlServer fornece um banco de dados agrupamento recurso, que dimensionado para ter mais de um StateServer, mas também tem suas limitações.
O outro problema SqlServer tem armazenamento é que todas as sessões são mantidas em uma única tabela. A contenção de bloqueio de acesso simultâneo e atualizações simultâneas dos dados de sessão se torna óbvia assim que você dimensionar backup. Que você tenha mais e mais transações por segundo, você tem mais e mais atrasos de bloqueio porque tudo o que é mantido em uma tabela.
Portanto, enquanto SqlServer dimensiona mais de estado-Server, ele entrega é um problema de desempenho e não dimensionar suficientemente. Além disso, ele não se adapta linearmente. Você é deve para ser capaz de crescer uma Web farm de um 5-ao farm de 50 a 100 servidores e o Web farm se deve a crescer muito suavemente; no entanto, o acesso a dados não aumentar correspondentemente. Como observei anteriormente, um banco de dados é como uma os acessos de armazenamento de dados que não aumentar, para armazenamento de sessões em um banco de dados não faz alguma melhoria importante. É apenas uma melhoria incremental sobre um ambiente de servidor de estado. Além disso, um SqlServer se torna um gargalo para dados de aplicativo bem como para dados de sessões. Portanto, um servidor de banco de dados não se adapta para dados de sessões ou aplicativos.
Qual é a resposta?
A solução é um mecanismo de armazenamento na memória, portanto, ele pode ser extremamente rápidas e tão rápido quanto um StateServer. No entanto, ele deve ser praticamente linear escalonável. Escalabilidade linear significa que à medida que você adiciona mais servidores, você está quase multiplicar a capacidade. Por exemplo, se você pode manipular 10.000 transações por segundo, com uma caixa, adicionar uma segunda caixa deve fornecer você próximo ao 20.000 transações por segundo total. Observe que "praticamente linear" não significa exatamente 20.000 — pode ser 19,000; ele no entanto, não é 12.000 ou 15.000. E esse é o que precisamos: armazenamento que pode crescer quase linearmente e ele também devem estar na memória.
Devido a essas necessidades de dois, estamos não falando armazenamento persistente, que tem outros requisitos e é destinado a longo prazo. Um banco de dados é destinado a armazenamento a longo prazo, enquanto armazenar na memória é sempre temporário e temporários. Mas nossas necessidades são temporárias. Só precisamos armazenar dados neste armazenamento temporário durante uma sessão de usuário ou talvez para a duração de um aplicativo, algumas horas para alguns dias, ou talvez algumas semanas em mais. Em seguida, os dados podem ir imediatamente porque não há sempre permanente armazenamento mestre, que é o banco de dados onde é possível carregar os dados de novamente.
Portanto, com todos os isso em mente, nós podemos pensar um mecanismo de armazenamento chamado "distribuído cache de," um conceito que se tornou popular porque ele fornece os benefícios citados acima, como A Figura 3 mostra.
A Figura 3 cache distribuído poupando pressão no servidor de banco de dados
Um cache distribuído é na memória, portanto, ela é rápida e ele foi projetado para distribuir o crescimento relativamente linearmente, especialmente se você tiver o mecanismo de distribuição à direita (também chamado de topologia de armazenamento em cache).
Um cache distribuído deve fornecer alto desempenho e escalabilidade linear, e porque existe na memória, ele deverá fornecer replicação para qualquer computador que se falhar (a memória em que máquina estiver disponível), outro computador terão os dados e você não perderá qualquer. Replicação fornece mais de uma cópia dos mesmos dados em locais diferentes em diferentes caixas e usando que você obter 100 % de tempo para a duração da seu armazenamento de dados.
Um cache distribuído armazena um objeto .NET ou um objeto de Java ou, para que importa, quaisquer outros dados como um documento XML. Ele armazena dados em um formato preparado. Ele não tem o conceito de tabelas e linhas e as chaves primárias e chaves externas que tenha um banco de dados. Para programadores, um cache distribuído é essencialmente uma tabela de HASH, onde há uma chave e cada chave tem um valor e que valor é um objeto. Você precisará saber a chave, e com base na chave, você pode buscar o objeto desejado. Isso é um cache de lógica que pode abranger vários servidores. Você pode adicionar servidores ao mesmo tempo para aumentar o tamanho de cluster do cache, e você pode remover caixas ao mesmo tempo para reduzir o cluster de cache sem interromper qualquer coisa.
Topologias de cache
As topologias várias que um cache eficiente deve fornecer são replicadas, particionados, um híbrido de replicado e particionado e o cliente ou cache local. A idéia é fazer com topologias de cache diferentes para diferentes tipos de uso, tornando o cache extremamente flexível. Uma topologia replicada replica o cache de muitas vezes, dependendo de como quantas vezes você precisa (consulte a Figura 4 ). Destina-se para situações em que você ter um uso intensivo com leitura cache, mas não muita de atualizações.
Figura 4 O cache replicado é ideal para uso intensivo com leitura
Um cache particionado é a topologia altamente escalonável para update-muitos ou transacionais dados que precisam ser armazenada em cache. Isso pode ser dados de sessão do ASP.NET, que é muito transacionais. Como mencionado anteriormente, para cada solicitação da Web, a sessão é ler uma vez e atualizada uma vez, para que ele tenha um número igual de leituras e gravações.
Uma topologia particionada (veja a Figura 5 ) é excelente para ambientes onde atualizações devem ser feitas pelo menos quantas vezes que você está fazendo leituras ou bem próximo ao. Nesta topologia, o cache é dividido. À medida que você adiciona mais e mais servidores de cache, o cache é mais particionados de forma que Nth quase uma (N significa o número de nós) do cache é armazenado em cada servidor de cache.
A Figura 5 um cache particionado é ideal para uso intensivo com de gravação.
Uma topologia de terceira é um híbrido das versões particionados e replicados. Você pode particionar o cache e, ao mesmo tempo, todas as partições podem ser replicadas. Portanto, você pode obter o melhor dos dois mundos. Você poderá particionar e aumentar, mais você pode duplicar para disponibilidade verificar que nenhum dado é perdido (veja a Figura 6 ).
A Figura 6 caches de réplica de partição são ideais para gravação-intensiveusage com confiabilidade.
Com a ajuda das topologias híbrida particionados e particionados de replicação, você pode aumentar o cache linearmente em termos de escalabilidade.
Um cliente ou o cache local é a topologia de extremamente útil quarta que fica no servidor de aplicativos. Esse tipo de cache é muito próximo ao aplicativo e ainda pode ser InProc. Ele é geralmente um pequeno subconjunto do cache distribuído grande real e se baseia em que o aplicativo em que momento tem sido solicitando. Que as solicitações do aplicativo, uma cópia é mantida no cache do cliente. Na próxima vez que o aplicativo deseja os mesmos dados, ele automaticamente achará no cache do cliente. Ele não precisa ir para o cache distribuído, para salvar mesmo que como uma viagem, porque o cache distribuído geralmente está na rede em um servidor de cache separado ou cluster de servidores de cache. Um cache de cliente oferece um aumento de desempenho e escalabilidade adicional.
Os dados em um cache de cliente devem ser mantidos sincronizados com o cache distribuído. Se esses mesmos dados for alterados no cache distribuído, o cache distribuído deve sincronizar a alteração com o cache do cliente. Isso é um aspecto importante — você não deseja ter apenas um cache local que está totalmente desconectado. Isso é apenas o equivalente de um cache InProc, que é inaceitável porque você tem problemas de integridade de dados. Você tem várias cópias dos mesmos dados que obtém fora de sincronia.
Opções diferentes
Há vários recursos de cache distribuídos disponíveis... E, como na maioria das situações, soluções livres fornecem um conjunto mais limitado de recursos enquanto aquelas comerciais oferecem muito mais opções e recursos.
Além de alto desempenho, escalabilidade e alta disponibilidade, um cache distribuído eficiente deve incluir vários recursos de chaves para ajudar a manter o cache de novas e sincronizada com a fonte de dados mestre, se do banco de dados ou mainframe. O cache deve tiver uma opção de expiração para que você pode dizer que executar a expiração automática, que pode ser uma hora absoluta ou o que é chamado "tempo deslizante". Basicamente, tempo ocioso; se ninguém usa os dados, ele é automaticamente expirado.
Um cache deve também poderá gerenciar relações entre diferentes tipos de dados. A maioria dos dados são relacionais. Por exemplo, se um cliente, você ter pedidos referentes a esse cliente portanto não há uma relação entre dados de clientes e dados de pedidos. Se armazenar em cache cliente e ordem de dados e você inadvertidamente excluir os dados do cliente do cache, faz sentido que a ordem deve ser excluída automaticamente. Neste exemplo, você não saberá se os dados do cliente é removido do cache ou permanentemente excluídos. No caso de você permanentemente excluído-lo, a ordem também é inválida agora porque a ordem deve ser de um cliente válido.
Há outros tipos semelhantes de relações que devem ser gerenciadas no cache. Se o cache não fazê-lo, em seguida, o aplicativo tem que manter controle e que é muito complicado. Um objeto de cache do Microsoft no ASP.NET que é muito útil é chamado "conceito de dependência de cache". Um item em cache depende de outro. Se esse item em cache é nunca removido do cache ou mesmo atualizado, o primeiro item de cache será removido também. Este é um conceito de dependência de cache poderosa que deve estar disponível em todos os caches que armazenar em cache dados relacionais.
Sincronização com o banco de dados é outra capacidade importante para o cache. Um banco de dados normalmente é compartilhado por vários aplicativos. Se um aplicativo usando o cache é a única atualização do banco de dados, provavelmente não será necessário o recurso de sincronização do banco de dados. Mas com muita freqüência, outros aplicativos, às vezes, os aplicativos de terceiros, estiver atualizando dados no banco de dados porque o banco de dados é um armazenamento compartilhado comum e os aplicativos não estiver usando o cache. Eles ainda não podem ser aplicativos. NET. Eles podem ser aplicativos de terceiros você não controlar, mas elas são atualizadas no banco de dados. Portanto, você precisa permitir para situações em que o banco de dados pode ser atualizado fora do seu aplicativo, mas alguns dos dados que tem sido atualizados no banco de dados também é armazenada em cache. Portanto, o cache deve ser capaz de sincronizar. Ele tem para poder saber sempre que os dados que ele tem são não o mesmo no banco de dados. Ele deve remover os dados do cache e talvez até mesmo recarregar a cópia mais recente do banco de dados. Sincronização do banco de dados pode ser feita por meio de eventos acionados pelo servidor de banco de dados ou pelo cache de pesquisa o banco de dados. Os eventos são claro mais em tempo real e pesquisa tem um ligeiro atraso. Mas pesquisa pode ser mais eficiente se uma grande quantidade de dados está alterando.
Notificação de evento está entre os recursos mais importantes que deve ter um cache distribuído eficaz. Um cache geralmente é compartilhado entre vários aplicativos e até mesmo dentro de um aplicativo entre vários usuários. Portanto, o cache deve ter um mecanismo de notificação de eventos caso, por exemplo, um objeto em cache seja atualizado ou removido. Se seu aplicativo estiver usando esses mesmos dados, convém ser notificado para que você pode recarregar o do banco de dados ou uma nova cópia do cache próprio. Um mecanismo de notificação melhora a colaboração entre vários usuários ou vários aplicativos por meio de cache.
O mundo real
Gerenciamento de TI enfrenta todos os os problemas de desempenho associados a bancos de dados, e no caso de afunilamentos, se tiver sorte poder relatá-los para desenvolvedores, eles podem tentar resolvê-los. Infelizmente, desenvolvimento sempre não internamente. Geralmente você é que com e gerenciar um aplicativo de terceiros.
Em qualquer caso, o melhor insira para iniciar a implementação de cache distribuído para abrir os afunilamentos e turbo-carga é de seus aplicativos com o armazenamento de sessão ASP.NET, porque você não precisa depender os desenvolvedores. Não há nenhuma programação envolvidos. É uma simples questão de substituir o armazenamento de sessão existente com um cache de distribuídos na memória. Além disso, a implementação de um cache distribuído para armazenamento de sessão ASP.NET oferece a oportunidade para ver os benefícios que se acumulam para desempenho e escalabilidade, e, em seguida, você pode optar por fazer o mesmo para os dados de aplicativo.
Para experimentar o aprimoramento de escalabilidade, você que seja necessário executar distribuídos cache armazenamento na produção ou você tem que simular que carga no seu ambiente de teste. Você pode ter acesso a perguntas e respostas, que podem ajudar a executar um teste de carga em um ambiente de teste para simular uma grande carga antes de colocar um cache distribuído em produção. A maioria dos gerentes de TI provavelmente não será confortáveis colocar um cache distribuído em produção, a menos que eles tinham testado-lo primeiro em seu ambiente de perguntas e respostas, mesmo se eles não puderam simular a mesma quantidade de carga. Portanto, que é um bom lugar para iniciar.
Uma vez você está em execução com um cache distribuído e reaping suas vantagens, você pode compartilhar suas novas descobertas de desempenho e escalabilidade de sessão do ASP.NET com sua equipe de desenvolvimento interno ou de terceiros-fornecedor. Com a evidência de disco rígida na mão, você pode pedir a equipe de desenvolvimento para analisar as áreas onde eles podem armazenar dados de aplicativo nesse cache distribuído bem.
Cache de dados de aplicativo fornece um aumento adicional e em muitos casos os muito mais aumentar de simplesmente usar um cache distribuído para armazenamento de sessão do ASP.NET. Os desenvolvedores poderão identificar todos os elementos de dados que são lidos com mais freqüência que elas são atualizadas. Dados mesmo transacionais (, como os clientes, pedidos e assim por diante) é um bom candidato para o armazenamento em cache, mesmo se ele permanece no cache por alguns minutos antes de expirar. Isso ocorre porque nesse breve período de tempo, os dados podem ser reler o muitas vezes, e se esse reler for do cache e não do banco de dados, ele libera seu banco de dados de muita carga leitura.
No entanto, para os desenvolvedores aos dados de aplicativos de cache, eles precisará fazer um pouco de programação, fazer chamadas de API para o cache distribuído. A idéia é muito simples. Sempre que o aplicativo tenta buscar os dados do banco de dados, ele deverá primeiro verificar o cache. Se o cache tiver esses dados, os dados serão retirados do cache. Caso contrário, o aplicativo busca os dados do banco de dados, armazena em cache-lo e, em seguida, concede a ele para o usuário. Dessa forma, os dados poderão ser encontrados no cache na próxima vez que ele é lido. Da mesma forma, sempre que dados são modificados no banco de dados, ele também deve ser atualizado no cache. E, se o cache reside em vários servidores, ele deve, portanto, ser sincronizado automaticamente para garantir que, se seu aplicativo for executado em um Web farm, os mesmos dados de cache seja acessíveis de todos os servidores no farm. Para obter mais informações sobre o tópico de como desenvolver um aplicativo que usa um cache distribuído para melhor desempenho, consulte para o meu artigo futuro na edição de julho de MSDN Magazine.
Iqbal khan é o presidente e tecnologia divulgador da Alachisoft, a empresa que fornece o NCache — o setor está levando cache de .NET distribuído para acelerar o desempenho e escalabilidade em aplicativos corporativos. Iqbal recebeu um Microsoft em ciências da computação da Universidade de Indiana, Bloomington, em 1990. Você pode contatá-lo em iqbal@Alachisoft.com.