Cinco impulsionadores de desempenho do ASP.NET
Webinar gravado
Por Ron Hussain e Nick Zulfiqar
Saiba como aumentar o desempenho e a escalabilidade do ASP.NET com um Cache .NET distribuído. Assista a este webinar para aprender sobre as cinco maneiras de aumentar o desempenho do ASP.NET para escalabilidade em aplicativos ASP.NET e como usar um Cache Distribuído na Memória para resolvê-los com eficiência.
Co-entregue por nosso Arquiteto de Soluções Sênior e Diretor Regional de Vendas, junte-se a nós para saber mais sobre:
- Cache de dados de aplicativos ASP.NET
- Cache de estado de sessão ASP.NET
- ASP.NET SignalR Backplane usando cache distribuído
- ASP.NET View State Cache
- Cache de saída ASP.NET
Hoje vamos falar sobre 5 maneiras de aumentar o desempenho e a escalabilidade do seu aplicativo ASP.NET. É um tema muito quente, eu diria que é algo que está em alta demanda. Então, estamos felizes em trazer isso para você. Ron vai falar sobre isso em um minuto e também, se você tiver alguma dúvida durante esta apresentação, sinta-se à vontade para digitá-la no vídeo e eu poderei chamar a atenção de Ron.
Então, Ron, o que você quer começar? Obrigado, Nick. Olá a todos, meu nome é Ron e serei seu apresentador para o webinar de hoje e, como Nick sugeriu, o tópico que escolhemos hoje são cinco impulsionadores de desempenho ASP.NET. Então, vamos passar por cinco recursos diferentes. Inicialmente, falarei sobre cinco problemas diferentes, o que você normalmente veria em um aplicativo Web ASP.NET, são problemas do dia a dia que realmente tornam seus aplicativos mais lentos, sua degradação de desempenho, então a escalabilidade é outro caminho, outro aspecto em que falaremos sobre esses gargalos e depois falarei sobre diferentes soluções com a ajuda do sistema de cache distribuído. Como resolver esses problemas em seus aplicativos ASP.NET? Então, isso é o que preparamos hoje, vou cobrir diferentes recursos, terei aplicativos de amostra, mostrarei tudo em ação como configurar e começar com isso. Então, será um webinar bastante interativo e prático e, como Nick mencionou, se houver alguma dúvida, sinta-se à vontade para participar e ficarei muito feliz em responder a todas essas perguntas para você. Tudo bem, assumindo que tudo parece bem, vou começar com isso.
ASP.NET é popular para aplicativos Web de alto tráfego
Então, antes de tudo, falarei sobre a plataforma ASP.NET em geral. ASP.NET é uma plataforma muito popular para aplicações web. Vemos muitas implantações na web e sua popularidade está aumentando. O legal da plataforma ASP.NET é que, baseada no padrão de uso, é algo que se expande muito bem, você pode lidar com milhares de usuários simultâneos e suas solicitações associadas sem precisar alterar nada dentro da arquitetura do aplicativo. Você pode criar um web farm, você pode criar um web garden, ele oferece muitas opções de escalabilidade, você pode colocar um balanceador de carga na frente e então rotear solicitações entre diferentes servidores web e alcançar escalabilidade linear, escalabilidade horizontal fora do web farm ASP.NET.
Um balanceador de carga pode ter balanceamento de carga fixo ou balanceamento de carga igual dependendo de sua arquitetura, dependendo da natureza stateful de seus servidores Web ou servidores de aplicativos e, em seguida, você pode dimensionar conforme necessário.
Portanto, esta é uma implantação típica de web farm para aplicativos ASP.NET, você tem N número de clientes passando pelo balanceador de carga para configurar servidores web em um web farm e, em seguida, tem armazenamento de sessão ASP.NET, esse é um tipo de dados que você pode ver em seus aplicativos da Web ASP.NET. Então serão servidores de banco de dados, bancos de dados relacionais ou NoSQL databases você pode estar lidando com muitos dados de um lado para o outro e, em seguida, pode ser qualquer outro sistema de arquivos de mainframe de sistema de dados de back-end com o qual seus aplicativos estão interagindo. Então, isso é muito popular, bastante escalável, muito rápido e muitas implantações ativas estão usando essa plataforma.
O problema: gargalos de escalabilidade
Então, vamos falar sobre o gargalo de escalabilidade dentro do ASP.NET. Onde exatamente está o problema? É algo que dimensiona muito bem o problema de escalabilidade e vamos definir rapidamente o que é escalabilidade? A escalabilidade é uma habilidade na arquitetura do aplicativo ou no ambiente em que seu aplicativo é implantado. É essa capacidade em que você pode aumentar o número de solicitações por segundo ou solicitações dadas, solicitações simultâneas sem comprometer o desempenho. Se você tiver certa quantidade de latência, digamos, cinco usuários. Que tal você manter essa latência? Você não degrada o desempenho e não há problema em não melhorar o desempenho, mas pelo menos você mantém o desempenho abaixo de 5000 usuários ou 500,000 usuários, essa capacidade em si é chamada de escalabilidade, onde você obtém o máximo rendimento do sistema, mais e mais cargas de solicitação estão sendo manipulado e, em seguida, sua latência não aumenta à medida que as cargas do usuário aumentam. Portanto, é essencialmente desempenho sob carga extrema ou desempenho extremo sob carga extrema. Então, essa capacidade é chamada de escalabilidade.
Agora, normalmente os aplicativos ASP.NET, embora o web farm seja muito escalável, eles agora forneceriam a você os problemas de escalabilidade no web farm, mas podem causar lentidão sob cargas de pico principalmente devido às fontes de dados de back-end. Portanto, se o seu aplicativo ficar lento, travar devido a uma enorme quantidade de carga, então esse aplicativo é um candidato à escalabilidade, ele precisa ter uma arquitetura escalável dentro de si. Por que o aplicativo sentiria seu mundo ou você veria situações como essa em que os aplicativos ficam lentos sob carga de pico, pode haver diferentes gargalos de armazenamento de dados ou alguns gargalos dentro do aplicativo. Então, deste ponto em diante, falaremos sobre cinco gargalos diferentes dentro de um aplicativo ASP.NET que limita sua capacidade de escalabilidade, que limita você a escalar horizontalmente.
Dois gargalos de armazenamento de dados
Tudo bem. Então, em primeiro lugar, temos dois gargalos de armazenamento de dados.
O banco de dados não pode escalar
Temos banco de dados de aplicativos que normalmente não pode ser dimensionado, você teria um banco de dados relacional na forma de SQL Server, oracle ou qualquer outra fonte de dados relacional popular. É muito bom para armazenamento, mas não é muito bom quando se trata de lidar com uma grande quantidade de carga de transações. Ele tende a engasgar e, em alguns casos, realmente causa erros de tempo limite. Então, ou pelo menos ele realmente diminui seu desempenho, você não pode adicionar mais servidores de banco de dados em tempo real, portanto, será de fonte única. Também é um ponto único de falha em alguns casos, se você não tiver replicação e, em seguida, o mais importante, o problema urgente aqui é que não é muito rápido, é lento no cenário normal e depois no pico de carga e, na verdade, piora a situação em que ele não é capaz de acomodar o aumento da carga e torna as coisas ainda mais lentas. Então, esse é o nosso primeiro gargalo.
Armazenamento de estado de sessão ASP.NET
O segundo gargalo é em torno do armazenamento do estado da sessão ASP.NET, agora o estado da sessão é um tipo muito importante de dados. É algo que tem informações do usuário, por exemplo, pode ser um aplicativo de comércio eletrônico que você mantém as informações do usuário ou o carrinho de compras, pode ser um sistema de reservas, pode ser um sistema de emissão de bilhetes, pode ser seu sistema financeiro. Então, pode ser qualquer tipo de sistema de frente onde os usuários fazem login e eles têm seus dados muito importantes dentro desse objeto de sessão.
Agora, esses são os três modos que a plataforma ASP.NET oferece, temos o InProc onde tudo fica armazenado dentro do processo de trabalho. Portanto, tudo fica dentro do processo do aplicativo para que seus processos de trabalho não sejam sem estado, o próprio protocolo HTTP é sem estado, mas, neste caso, seus processos de trabalho hospedariam todos os dados do usuário. Então temos StateServer essa segunda opção e então temos o SQL Server. Então, fale sobre essas opções convencionais de armazenamento de estado de sessão e vamos falar sobre seus gargalos.
Em primeiro lugar, o InProc é rápido porque está na memória, não há desserialização de serialização, mas, em primeiro lugar, você não pode lidar com um cenário de jardim da web. Em um servidor web, você teria apenas um único processo de trabalho para um determinado aplicativo, porque é onde os dados da sessão existem agora, se a próxima solicitação for para outro processo de trabalho, você não tem mais esses dados de sessão, tem que ser o mesmo processo de trabalho e é por isso que limita você, tecnicamente não é possível executar o web garden com o gerenciamento de sessão InProc, então esse é um fator limitante aqui.
Em segundo lugar, você precisa que o sticky session bit esteja habilitado no balanceador de carga. Então, em primeiro lugar, você limitou seu desempenho ou escalabilidade ou seus recursos no servidor web e por ter apenas um único processo para um aplicativo. Em segundo lugar, seus servidores web onde a solicitação inicial foi atendida, as solicitações subsequentes sempre iriam para o mesmo servidor. Isso é tudo que o balanceamento de carga de sessão fixo funciona, ele faz o trabalho, mas o principal problema com isso é que pode ser que um servidor da Web tenha muitos usuários ativos, mas outros servidores da Web estejam ociosos porque esses usuários já foram desconectados e uma vez que os usuários serão de natureza pegajosa, eles nunca iriam para este servidor gratuito, eles sempre iriam para o mesmo servidor onde eles têm que ir com os dados existentes. Então, esse é outro problema que você tem que ter um balanceamento de carga de sessão fixo com o InProc e, o mais importante, se o seu processo de trabalho for reciclado e vimos com base em nossa experiência, os processos de trabalho do ASP.NET reciclam bastante, você perderia tudo os dados corretos, se for uma tarefa relacionada à manutenção, se o servidor precisar cair, você terá que derrubar um servidor da web, trazer outro servidor da web, você perderá todos os dados como resultado disso. Então, isso resume todos os problemas, todos os gargalos que você veria com o gerenciamento de sessão InProc com um ASP.NET. Portanto, claramente não é uma opção e também não é muito escalável, você tem um servidor que atinge a capacidade desse servidor e, com o balanceamento de carga, não ajuda muito.
A segunda opção é o StateServer, é um pouco melhor que o InProc porque tira os dados do seu processo de aplicação dentro de um serviço de estado, pode ser uma caixa remota ou um de seus servidores web, depende inteiramente de você, mas o problema é que não é escalável, é de fonte única, você pode escalar nesse servidor, mas escalar horizontalmente não é uma opção. Sempre será um servidor único, um serviço hospedando todos os dados da sua sessão e que também gerenciará toda a carga de solicitações, se a carga de solicitações aumentar, não há opções para adicionar mais recursos. Portanto, não será dimensionado em comparação, eventualmente, seu serviço de estado pode sufocar, por exemplo, se você tiver centenas e milhares de usuários e sua solicitação associada fizer com que milhões de solicitações por segundo ou por dia, ou em milhões, seja uma carga muito pesada . Portanto, com base nesse StateServer não seria dimensionado e não seria capaz de lidar com o aumento da carga, e também é um ponto único para a falha. Se o próprio StateServer ficar inativo, você perderá todos os seus dados de sessão e os dados de sessão são um tipo muito importante de dados que você não gostaria que perdesse suas sessões enquanto seu usuário está prestes a comprar algo ou está prestes a tomar uma decisão e isso afetará o negócio em troca.
A terceira opção é o SQL Server. O SQL Server é novamente um gerenciamento de sessão fora do processo, mas novamente é lento, não é escalável, você não pode adicionar mais SQL Servers e não se destina a lidar apenas com dados transacionais, então você acaba tendo o mesmo problema que discutimos como parte de nosso banco de dados do aplicativo, esse problema permanece o mesmo para o cache de dados, bem como para o cache de sessão. Portanto, o estado da sessão não é algo que será otimizado com as opções padrão que a plataforma ASP.NET apresenta e isso se deve principalmente às fontes de dados que ela oferece InProc, StateServer e SQL Server.
Espero que isso tenha construído alguns detalhes básicos em torno dos gargalos e, claro, falaremos sobre a solução, estamos falando sobre cache distribuído e seus recursos em comparação e falaremos sobre como cuidar desses problemas um por um , então quero listar todos os problemas primeiro e depois falaremos sobre as soluções uma a uma. Este diagrama ilustra o mesmo.
Temos banco de dados gargalo de armazenamento de dados e depois temos armazenamento de sessão ASP.NET ou InProc ou bancos de dados como gerenciador de sessão e isso também é claramente um gargalo, onde temos fontes únicas na maioria dos casos, elas não são escaláveis, não são muito confiável e depois é lento em geral.
ASP.NET View State Gargalo
Agora o terceiro gargalo importante é ASP.NET view state. Para web farms ASP.NET existe um estado de exibição, agora aqueles de vocês que querem saber o que é o estado de exibição? Tenho certeza que todo mundo sabe, mas o estado de visualização é um gerenciamento de estado do lado do cliente, é um pacote, é um estado de seus widgets de controle que você tem em seus web farms, é construído no servidor e se torna parte de seu O pacote de resposta volta para o navegador onde está armazenado, nunca é realmente usado no final do navegador e é trazido de volta ao servidor quando você publica de volta nessa página como parte do pacote de solicitação disperso. Então, ele é empacotado com os pacotes de solicitação e resposta, ele volta para o navegador, nunca é realmente usado lá e um problema urgente com o estado de visualização é que geralmente é muito pesado. Tem centenas de kilobytes de tamanho e pense no cenário, onde você tem uma grande quantidade de carga de transação, temos milhões de transações e, em seguida, cada transação tem um pacote de pacote de estado de exibição ou um pacote de resposta de solicitação para o aplicativo Web ASP.NET. view state parte dele e se você tiver centenas de kilobytes de view state por solicitação e tiver milhões de transações, isso consumirá muita largura de banda e, em geral, diminuiria as respostas da sua página porque você está lidando com muitos dados para frente e para trás e esses dados são pesados em tamanho também.
Então, esse é outro gargalo que consome sua largura de banda, sua causa aumenta significativamente e diminui os tempos de resposta da página porque o estado de visualização é geralmente pesado, você está lidando com uma carga útil mais pesada para solicitações em resposta. Então, esse é outro tipo de gargalo que faz parte dos web farms ASP.NET. Se você tiver um aplicativo de web farms ASP.NET, não há como fugir desse problema. Por padrão, você teria que lidar com muitos estados de exibição e este diagrama o cobre onde o estado de exibição volta para o navegador, é um gerenciamento de estado do lado do cliente que é construído no servidor e volta para o navegador e o traz volta no servidor em seus post backs. Agora, os pacotes de solicitação e resposta são pesados, consomem muita largura de banda, carga útil pesada também torna as coisas mais lentas.
Gargalo de execução de página extra
Agora quarto gargalo e este é o penúltimo, temos mais um gargalo depois deste é o gargalo de execução de página extra. Agora, isso é verdade para web farms ASP.NET, bem como para aplicativos web ASP.NET MVC. Existem cenários em que a saída da página inteira é a mesma ou partes de uma página dinâmica são iguais, então você está lidando com conteúdo estático no aplicativo com muita frequência. Portanto, a saída da página não muda com muita frequência, mas você ainda está executando essas solicitações. Pode haver uma solicitação e envolve alguns bancos de dados de back-end que são renderizados e, em seguida, você busca alguns dados das fontes de dados de back-end, lê esses dados, torna-os significativos, aplica alguma camada de lógica de negócios diária, camada de acesso a dados, todos os coisas boas e depois disso você renderiza uma resposta e a resposta é enviada de volta ao usuário final no navegador. Agora, o que quer que o mesmo ciclo tenha que acontecer novamente e então o conteúdo não está mudando, você teria que passar pelo mesmo ciclo de novo e de novo e de novo. Esta página é executada independentemente de mudar ou não, por padrão você está lidando com muito conteúdo estático e embora o conteúdo não esteja mudando, você ainda está executando a mesma solicitação. Agora, isso aumenta seu custo de infraestrutura, CPU extra, memória extra, recursos extras de banco de dados, pode atingir a capacidade no servidor web, também pode atingir a capacidade no site do banco de dados em geral, é algo que desperdiçaria muito CPU e recursos caros na execução de algo que já foi executado. Então, esse é outro gargalo e falaremos sobre uma solução com a ajuda do cache de saída da página como cuidar disso também. Então, isso cobre nosso quarto gargalo e o quinto e, a propósito, esse diagrama envolve a execução da página na saída estática e fez com que mais bancos de dados lidassem com muitas solicitações.
ASP.NET SignalR Backplane Gargalo
E o quinto gargalo é SignalR backplane. Agora, este é um caso de uso muito específico, você pode ou não ter o SignalR, mas para aqueles que estão familiarizados com o SignalR e se você configurou um backplane, um backplane é um barramento de mensagens comum e seu servidor web envia todos os seus mensagens em vez de enviar a funcionalidade push nos navegadores do cliente. Pode haver um cenário em que poucas solicitações de clientes sejam tratadas com outros servidores da web. Então, somos apenas transmitidos para o backplane e o backplane, por sua vez, transmite mensagens, mensagens SignalR para todos os servidores da Web e eles, por sua vez, transmitem para todos os clientes conectados. Então, com WebSockets ASP.NET SignalR backplane é uma configuração bastante comum, se você tiver um web farm.
Atual SignalR Backplane NCache ou qualquer outro produto de cache distribuído pode ser conectado. Também pode ser um banco de dados ou também um barramento de mensagens, mas a ideia aqui é que o backplane não deve ter problemas de desempenho ou taxa de transferência. Ele deve ter um desempenho muito bom, deve fornecer baixa latência, alta taxa de transferência e, ao mesmo tempo, deve ser muito confiável se cair e você perder todas as mensagens do SignalR que também afetariam os negócios.
Os bancos de dados são lentos, não são muito escaláveis, têm desempenho lento, Redis é uma opção que não é nativa .NET, então você precisa de algo que seja muito escalável, que seja muito rápido e também muito confiável. Então, esse é outro problema em um aplicativo ASP.NET se você estiver usando SignalR backplane como resultado disso. Então, isso completa nossos cinco gargalos, eu sei que é muita informação, mas principalmente seu banco de dados sendo lento, não sendo muito escalável, o estado da sessão ASP.NET não tem opções muito escaláveis ou rápidas ou confiáveis por padrão. O estado de exibição para o Web farm ASP.NET também é um gargalo, sua fonte de contenção, a utilização excessiva da largura de banda, as páginas estáticas no aplicativo serão executadas independentemente de o conteúdo do aplicativo estar mudando ou não. Vai ser executado e então temos SignalR Backplane que geralmente é lento e não é muito confiável, não é muito escalável e você precisa de algo que seja muito escalável e muito confiável em comparação.
Então, isso completa nossos cinco gargalos, nos próximos slides eu vou falar sobre solução e então nós vamos realmente passar por todos esses gargalos um por um e eu vou apresentar soluções diferentes. Por favor, deixe-me saber se houver alguma dúvida e ficarei muito feliz em responder a essas perguntas para você agora. Eu tenho alguns exemplos de aplicativos alinhados aqui, então vou usá-los bem. Então, eu acho que neste momento não há perguntas. Então, vou começar rapidamente com a solução porque temos muito o que cobrir em nosso próximo segmento.
A solução: cache distribuído na memória
Temos o cache distribuído na memória como solução e usarei NCache como um produto de exemplo. NCache é o principal produto de cache distribuído, cache distribuído baseado em .NET, foi escrito para dentro de .NET e é principalmente para aplicativos .NET e é um dos nossos principais produtos. estarei usando NCache como um produto de exemplo e falaremos sobre cinco recursos diferentes dentro NCache que cuidará disso e você verá um impulsionador de desempenho em seu aplicativo ASP.NET. Isso melhoraria drasticamente o desempenho e a escalabilidade e isso é apenas recursos específicos do ASP.NET, existem outros recursos do lado do servidor que você pode ajustar, há um webinar separado em como melhorar NCache atuação, isso levará as coisas a um nível totalmente novo, que melhorará ainda mais o desempenho, mas neste webinar falarei sobre cinco gargalos diferentes e depois falarei sobre cinco soluções diferentes para esses gargalos.
O que é um cache distribuído na memória?
Então, o que é um cache distribuído na memória e como ele é mais rápido e escalável e, em alguns casos, mais confiável em comparação? Portanto, o cache distribuído é um cluster de vários servidores de cache baratos que são agrupados em uma capacidade lógica para sua memória, CPU e recursos de rede. Então, se você tem uma equipe de servidores e essa equipe de servidores está unida em um cluster, é uma capacidade lógica para aplicativos, mas é um conjunto físico de servidores ou VMs, então atrás de nós existem vários recursos e você tem a capacidade de adicionar mais servidores em tempo real. Então, servidores de cache baratos, se juntam, se juntam e reúnem seus recursos e é isso que forma a base de um cache distribuído.
Em seguida, sincronizamos as atualizações de cache entre servidores de cache, é muito consistente em termos de dados do que era porque existem vários servidores, vários aplicativos clientes se conectam a ele, portanto, qualquer atualização feita em um servidor de cache deve ser visível em outros servidores de cache da web e também para os clientes que estão ligados a ele e eu usei o termo visível, o que significa que tem que ser consistente. Eu não usei replicação como um termo aqui, replicação é outro conceito. Assim, todas as atualizações são aplicadas de forma sincronizada ou consistente em todos os servidores de cache, para que você tenha a mesma visão dos dados para todos os seus aplicativos clientes.
Em seguida, ele deve ser dimensionado para capacidade transacional e de memória e também para outros recursos. Se você adicionar mais servidores, deve apenas aumentar a capacidade, se você tiver dois servidores e trazer o terceiro servidor, anteriormente você estava lidando com 10,000 solicitações com um terceiro servidor, deve aumentar para 15,000 com mais dois servidores dobrando a capacidade, ele deve lidar com 20,000 solicitações por segundo e essa é a nossa experiência. Na verdade, aumenta a capacidade e a capacidade geral de tratamento de solicitações aumenta à medida que você adiciona o número de servidores e mostrarei alguns números de referência para dar suporte a isso. Esta é a arquitetura de implantação do cache distribuído típico.
Você tem uma equipe de servidores de cache, todos os ambientes Windows são suportados 2008, 2012 e todos os seus aplicativos se conectam a ele em um modelo cliente-servidor e usam essa fonte rápida, escalável e confiável além do nosso banco de dados relacional. Algum dia eles vão dar isso existe no banco de dados relacional, você pode trazer alguns ou todos os seus dados no cache. Estado da sessão torna-se seu armazenamento principal, estado de visualização, cache de saída, SignalR backplane este se torna seu principal provedor para isso.
NCache Benchmarks de desempenho
Deixe-me mostrar alguns números de referência para comprovar que é muito escalável. Em nosso site esses números são publicados. Então, esses são os detalhes do teste e, se você observar o desempenho, isso está crescendo para leituras não tão lineares para gravações, mas esta é a topologia que usaremos no webinar de hoje, leituras e gravações estão crescendo linearmente e isso tem leituras e gravações crescendo linearmente, assim como backups. Portanto, isso também vem com suporte a backup, e é por isso que o desempenho ou a capacidade de gravação é um pouco menor do que a partição não tem nenhum backup, portanto, isso também tem uma sobrecarga de backup. Portanto, esta é a nossa topologia mais popular para leituras e gravações e, à medida que você adiciona mais servidores, ela também aumenta a capacidade.
Demonstração prática
Deixe-me levá-lo ao nosso ambiente de demonstração, configurar um cache distribuído e, em seguida, começar com esses recursos um por um e pessoal, por favor, quero dizer, se houver alguma dúvida?
vou usar, já baixei instalado NCache, o escopo deste webinar não é próximo NCache configurações ou configuração. Então, vou pular alguns detalhes aqui, mas só para que você saiba, eu baixados NCache do nosso site um teste totalmente funcional e, em seguida, instalei-o em duas das minhas caixas de servidor de cache e uma máquina do meu lado será usada como cliente. Você pode instalar NCache no cliente também ou você pode usar os pacotes NuGet conforme necessário.
Criar um cache
Vou apenas criar um cache, vamos chamá-lo de aspnetcache porque é isso que temos em foco hoje.
Vou escolher o cache de réplica de partição e todas essas configurações são discutidas em grandes detalhes em nosso NCache arquitetura webinários.
Opção de replicação assíncrona e aqui, especifico os servidores que inicialmente farão parte do meu cluster de cache.
Mantenha tudo igual para a porta TCP/IP. NCache é uma comunicação baseada em TCP/IP, a comunicação servidor-servidor e cliente-servidor é gerenciada através de TCP/IP e então o tamanho do cache em cada servidor, vou manter tudo padrão manter o padrão de despejos e escolher concluir e pronto.
É assim que é fácil configurar o cache. No painel direito, temos todas as configurações relacionadas a esse cache e, a propósito, você também pode configurar linhas de comando e ferramentas do powerShell e também gerenciar tudo da linha de comando ou do powershell. Adicionarei mybox de onde pretendo executar aplicativos. Então, se tivermos as configurações do lado do cliente atualizadas e eu conseguir me conectar a esse cache vou iniciar e testar esse cluster de cache e pronto. A configuração do site do meu servidor está concluída neste momento. Pessoal, por favor me avisem, tem alguma dúvida? Tudo bem, então, isso começou. Clicarei com o botão direito do mouse e escolherei estatísticas.
Ron, eu tenho uma pergunta aqui rapidinho NCache fluxos para suportar aplicativos Java para sessões JSP um cache de sessão ou é apenas aplicativos ASP.NET? ok, essa é uma pergunta muito boa, principalmente este webinar foi focado no ASP.NET, então me concentrei mais no site ASP.NET, mas sim para responder a essa pergunta NCache suporte totalmente a aplicativos Java, temos um cliente Java e, em seguida, para aplicativos Java, se você tiver sessões da Web Java ou sessões JSP, poderá muito bem usar NCache. Portanto, nosso provedor permanece exatamente o mesmo, é uma opção sem alteração de código e temos um aplicativo de exemplo que vem instalado com NCache também. Então, você só precisa instalar NCache no ambiente Windows ou você também pode usar contêineres e, em seguida, o aplicativo pode estar no Windows ou no ambiente Linux UNIX também, ele suporta totalmente aplicativos Java.
Monitorar estatísticas de cache
Abri as estatísticas apenas para ver alguns aspectos de monitoramento, abri também uma ferramenta de monitoramento que vem instalada com NCache. Executarei rapidamente um aplicativo de ferramenta de teste de estresse para verificar se meu cache está configurado bem e, em seguida, começarei com os aplicativos de amostra, um cliente está conectado, você deve ver alguma atividade aqui, lá está e temos contadores mostrando o valor das requisições por segundo dos dois servidores e já temos alguns gráficos sendo preenchidos.
Então, isso garante que tudo esteja configurado corretamente e então podemos começar com nossos aplicativos de amostra.
Então, o primeiro aplicativo de exemplo é, essas são cinco otimizações diferentes. Falarei sobre eles um por um e depois mostrarei os aplicativos de exemplo. Em primeiro lugar, você pode usar NCache para cache de dados, temos nossa API detalhada para gargalos de banco de dados. Você pode usar um cache distribuído na memória rápido, é mais rápido porque está na memória, é mais escalável porque você pode adicionar mais servidores e aumentar a capacidade em tempo de execução adicionando mais servidores. Você pode usá-lo para o estado da sessão, esta é uma opção sem alteração de código, as sessões são muito confiáveis em NCache como eles são replicados, as sessões também são gerenciadas em um repositório rápido e escalável e você não precisa de balanceamento de carga de sessão fixo. Falarei sobre mais benefícios assim que mostrarmos esses aplicativos de amostra, mas apenas informaremos que esses são alguns dos benefícios que você obtém NCache imediatamente assim que você conectar NCache Para estes.
Para web farms, você pode usar o estado de exibição, pode armazenar o estado de exibição no servidor, não precisa enviar o estado de exibição e também reduzir o tamanho da carga do estado de exibição, então você pode usar NCache para SignalR Backplane, essa é a nossa quarta opção e você também pode usar NCache para cache de saída, bem como para conteúdo estático e isso também é verdade para ASP.NET core. Você pode usá-lo para o estado da sessão no ASP.NET core e você também pode usá-lo para cache de resposta em ASP.NET core aplicações.
Exemplo de cache de sessão ASP.NET
Então, vamos começar com o armazenamento de estado de sessão ASP.NET. Isso é o mais fácil de tudo, você pode configurá-lo em cinco minutos e testá-lo rapidamente. Na verdade, vou mostrar como configurá-lo e, em seguida, começar a usá-lo.
Então, esse é o nosso primeiro aplicativo de exemplo, o que eu fiz é que ele vem instalado com NCache também, mas eu modifiquei um pouco. Para o cache de sessão, tudo o que você precisa fazer é adicionar uma tag de montagem, essas duas montagens são redundantes, são para outro caso de uso para cache de objetos, mas você só precisa Alachisoft.NCacheMontagem .SessionStoreProvider. A versão 4.9 é a versão mais recente e você também precisa de cultura e token público para esse assembly. Então, esta é uma referência típica para este assembly de estado de sessão, depois disso você precisa substituir sua tag de estado de sessão existente por NCache. Se você já tem uma tag de estado de sessão, você precisa substituí-la, se você não tiver uma, foi InProc, nesse caso você pode realmente substituí-la, você pode adicionar isso como um novo. Aqui o modo é personalizado e o provedor é NCacheSessionsProvider, o valor de tempo limite é se um objeto de sessão em NCache fica ocioso por mais de vinte minutos, ele expira automaticamente e é removido do cache.
Em seguida, existem algumas configurações, como exceções a serem habilitadas. Então, isso pode ser usado como uma tag de exemplo, você pode copiá-lo daqui e colá-lo no aplicativo e o mais importante é o nome do cache, você só precisa especificar o nome do cache aspnetcache. Acho que uso o mesmo nome aspnetcache e resolveria as configurações para este exemplo porque você especifica apenas o nome. Então, ele apenas leria as configurações para este cache do client.ncconf aspnetcache ou este arquivo também pode fazer parte do projeto. Se você tiver um pacote NuGet, também poderá tornar esse arquivo parte do seu projeto e pronto. Você só precisa salvar isso e deixe-me fazer isso como uma página principal porque estávamos usando duas páginas aqui e eu executarei isso e isso iniciaria as sessões de jogo convidado para o provedor e se conectaria a NCache para dados de sessão.
Então, espero criar um objeto de sessão no cache e, em seguida, lerei alguns dados da sessão e mostrarei o objeto de sessão que está sendo criado também. Este é um aplicativo de jogo de adivinhação, ele permite que você adivinhe um número entre um e cem e, em seguida, imprime o convidado anterior do objeto da sessão. Então, ele adivinhou que o número está entre 0 e 23. Então, vou apenas adivinhar 12, o número está entre 12 e 23. Então, ele leu o último número também. Vamos adivinhar que o número está entre 13 e 23. Então, vamos adivinhar mais uma vez. Eu não sou capaz de adivinhar, espero chegar lá, mas apenas para que você saiba que um objeto de sessão deve ter sido criado no final do servidor.
Deixe-me mostrar isso com a ajuda de uma ferramenta e pronto, NCache test é uma palavra-chave que eu acrescento a este aplicativo de exemplo. Se eu mudar isso, isso é para distinguir entre sessões de aplicativos diferentes, pode haver um cenário em que você tenha dois aplicativos e usará o mesmo cache para ambos os aplicativos. Portanto, nesse caso, você pode ter um ID de aplicativo anexado à variável de sessão, mas normalmente um aplicativo deve armazenar em cache sua sessão em um cache dedicado. Então, isso realmente não importa, se você especificar como uma string vazia, mas isso foi criado e este é o seu ID de sessão ASP.NET, a sessão aqui é replicada aqui. Portanto, se este servidor cair, você terá os dados da sessão disponibilizados automaticamente.
Mais alguns benefícios do NCache estado da sessão em comparação com as ocorrências do InProc fora do processo, portanto, seu processo da Web é completamente sem estado. Então, é o preferido pelo protocolo HTTP, é mais escalável, você pode adicionar mais recursos, é mais rápido porque está na memória, é comparável ao InProc e é muito confiável. Se um servidor cair, você não precisa se preocupar com nada e, o mais importante, não precisa mais usar sessões fixas ou balanceamento. Você pode ter balanceamento de carga igual e a solicitação pode saltar de um servidor web para outro. Você não precisa se preocupar com nada porque os servidores da Web não estão armazenando nada, os objetos de sessão reais são armazenados em NCache e este é um armazenamento de processo externo para seus aplicativos e comparações de StateServer. Não é um único ponto de falha, se um servidor cair ou você o derrubar para manutenção, você não precisa se preocupar com nada, ele funcionaria sem problemas.
Em segundo lugar, é muito escalável, você pode adicionar mais servidores rapidamente. É muito confiável, é muito escalável, é rápido em comparação. Para banco de dados não é lento, é rápido e é muito escalável e em alguns casos é ainda melhor em termos de confiabilidade onde você não tem replicação para bancos de dados. Então, isso cobre e mais uma característica importante dentro NCache é o nosso suporte a sessões multi-site, esse é outro recurso sessões multirregionais, onde você terá sessões de duas regiões diferentes armazenadas em NCache e você pode ter sessões totalmente sincronizadas.
Se uma solicitação de sessão salta de um servidor para outro ou de uma região para outra, ela é alimentada automaticamente pela região e trazida para cá e vice-versa. Portanto, se você precisar trazer o lado para baixo, poderá rotear todo o seu tráfego para o outro lado, mantendo o cache em execução por algum período de tempo. Então, essa é outra característica. Uma de nossas principais companhias aéreas, o cliente de companhias aéreas está realmente usando esse recurso para sua afinidade de localização. Portanto, isso abrange nosso estado de sessão ASP.NET. Este é um provedor sem alteração de código, por favor, deixe-me saber se houver alguma dúvida sobre isso, então eu já respondi uma pergunta sobre sessões JSP, você pode usar NCache para sessões da Web baseadas em Java também. Supondo que não haja perguntas.
ASP.NET View State Amostra de armazenamento em cache
Em seguida, falarei sobre o estado de visualização, agora NCache também tem um provedor de estado de exibição, a maneira como ele funciona é basicamente, mantemos o estado de exibição no servidor. É novamente um provedor, tudo que você precisa fazer é configurar um grupo de seções certo, são configurações de conteúdo, é ContentOptimization.Configurations.ContentSettings. O nome do grupo de seção é nContentOptimization e, em seguida, isso tem algumas configurações onde você pega um nome de cache, por exemplo, estou usando mycache agora, da maneira que projetamos nosso ASP.NET view state provedor é que mantemos o estado de exibição no lado direito do servidor. Então, antes de tudo, vou executar sem cache, embora tenha o provedor anterior conectado, mas configurei o cache do estado de exibição para ser falso e executarei isso e mostrarei o estado de exibição real voltando ao navegador.
Então, mostrarei a opção padrão e depois mostrarei a NCache view state e vamos comparar a diferença. Então, há algumas páginas da web farm e eu vou mostrar a fonte da página de visualização.
Este é o estado de visualização padrão, a parte do valor, deixe-me trazê-lo aqui e deixe-me criar um documento temporário aqui. Agora, este é o estado de visualização padrão que faz parte do meu pacote de resposta e, quando eu retornar a esta página, também fará parte do meu pacote de solicitação. Essa é uma solicitação individual e observe quantos caracteres, ela foi anexada aos cabeçalhos de solicitação e resposta à direita e isso é o mesmo para todas as solicitações que farei. Deixe-me apenas mostrar-lhe mais alguns pedidos e deixe-me mostrar-lhe a fonte da página de visualização deste também.
Então, é quase semelhante que você pode ver na tela. Agora com NCache o que fizemos foi interceptar seu estado de visualização com a ajuda de nosso provedor de estado de visualização. Mantemos o estado de exibição no servidor, então, nessa parte do valor, criamos uma chave e um valor para uma determinada página do web farm, armazenamos no servidor, agora ele é armazenado no servidor, então, enviamos um pequeno token de volta ao navegador. Portanto, esse é um token de tamanho estático, que é enviado de volta ao navegador. Ele nunca muda, sempre será enviado para lá e depois trazido de volta para ser usado novamente e quando você postar de volta, você realmente faz uma chamada para NCache e buscar o estado de visualização extra de NCache e, em seguida, usá-lo em seu web farm para realmente visualizar o estado e é isso que estamos fazendo nos bastidores.
Os benefícios que você obtém com o seu pacote de estado de visualização tornam-se menores em tamanho porque é um token. Portanto, isso tem um impacto geral na redução do tamanho da carga útil para solicitação e resposta. Portanto, isso melhora seu desempenho e, em segundo lugar, se você tiver centenas de kilobytes de estado de exibição viajando para frente e para trás para milhares de solicitações, isso consumirá sua largura de banda. S, isso não vai acontecer com NCache, NCache view state é um token estático e eu vou mostrar o token bem rápido.
Ron, deixe-me pular para a pergunta, bem rápido NCache tem algum recurso de segurança de contas, como a criptografia para sessões e cache de estado de exibição? sim, são recursos que você pode configurar explicitamente, são gerais NCache recursos. Então, todo o estado de visualização já é uma string criptografada, mas se você quiser criptografar ainda mais e deixe-me ver se está por aí sim, você pode ativar a criptografia no próprio cache, você precisa pará-lo, configurar a criptografia, temos provedores DES , temos provedores AES, temos clientes FIPS, compatíveis com FIPS, provedores DES AES. Então, sim, você pode simplesmente configurar isso e toda a carga útil dos clientes-servidores seria criptografada e descriptografada aqui e buscada, respectivamente. Então, isso é algo que você pode configurar sob demanda e você pode fazer as coisas acontecerem e, por essa pergunta, também quero destacar que, como NCache não está armazenando este é o estado de visualização após NCache conectou foi conectado como provedor e observe a diferença, são esses muitos caracteres versus esses muitos caracteres. Então, este é o seu padrão, isso é com NCache e veja você mesmo a diferença: isso diminui a velocidade, reduz o tamanho da carga útil sobre todos os aumentos de desempenho, os custos de virtualização de banda diminuem. Então, você vê muitas melhorias na arquitetura e, o mais importante, seu estado de exibição real nunca mais é enviado de volta ao navegador. Ele será armazenado no lado do servidor, é seguro em geral.
Então, com base nesta pergunta, obrigado por perguntar isso NCache view state é, por padrão, mais seguro do que a opção padrão, porque o armazenamos na extremidade do servidor, onde é realmente necessário. Então, espero que ajude. Vou encerrar isso, qualquer uma das perguntas sobre o estado de visualização, caso contrário, passarei para o próximo segmento.
Amostra de Cache de Dados do Aplicativo
Vamos me fazer mostrar o cache do objeto primeiro por causa da restrição de tempo. Acho que devo cobrir isso primeiro. Para gargalos de banco de dados, qualquer coisa que armazene no banco de dados que torne as coisas mais lentas, alternativamente, você pode usar um cache distribuído como NCache. Isto é NCache API aqui.
Conexão de cacheCache cache = NCache.InitializeCache("myCache");
cache.Dispose();
Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");É assim que você conecta o cache, é assim que você descarta o identificador no final das operações, tudo é armazenado em um par de valores de chave, é um objeto permitido de valor de chave de string .NET que você pode mapear suas tabelas de dados para seus objetos de domínio e então você armazena seus objetos de domínio e então você lida com objetos de domínio armazenando objetos individuais ou coleções com relacionamentos, pesquisas SQL a lista continua, mas esta é a operação básica de criar, ler, atualizar, excluir.
Executarei rapidamente um aplicativo de exemplo e demonstrarei como você realmente usaria NCache para cache de objetos. Você precisa dessas duas referências resumidas Alachisoft.NCache.Web e Alachisoft.NCache.Tempo de execução. Depois de fazer isso, deixe-me fazer isso como uma página inicial e mostrar o código por trás disso. Este é um web farm ASP.NET, mas se você tiver controladores MVC você também pode usar a mesma abordagem e então eu tenho esse namespace aqui e dentro deste aplicativo, estou inicializando mycache, você precisa especificar o nome do cache e você também pode especificar servidores aqui, usando InitParams right cache InitParams aqui ou você pode apenas especificar o nome e resolver o nome através do client.ncconf que eu mostrei anteriormente. Existe um addObject, que adiciona um cliente, o nome é David Jones, masculino, número de contato, este é o endereço e então estou chamando cache.Add.
Da mesma forma, estou inserindo isso alterando a página ou poderia, na verdade, também alterar o nome apenas para garantir que isso seja atualizado e então estou chamando cache.Insert e então estou recebendo o objeto de volta, obtendo o contagem do objeto. Estou removendo esse objeto, estou apenas executando um teste de carga. 100 itens serão atualizados novamente. Então, vamos executar o aplicativo de exemplo, é tão intuitivo começar com ele e ele apenas iniciaria o aplicativo e eu seria capaz de realizar todas essas operações para você e antes de fazer isso, eu também gostaria para mostrar os estados de visualização que foram armazenados em cache NCache.
Você pode ver as chaves para o estado de exibição de três páginas vs e esta é a chave real do objeto e, em seguida, o status de exibição real está na parte do valor. Esqueci de mencionar isso agora, supondo que deixamos apenas limpar o conteúdo. Então, que estamos lidando apenas com dados de cache de objetos agora, na verdade, deixe-me fazer isso no gerenciador, é conveniente. Então, vou adicionar um objeto, cliente adicionado, vou buscar esse objeto de volta. Então, temos David Jones, 23 anos. Vou atualizá-lo e adicioná-lo, recuperá-lo agora é David Jones 2 e então temos 50 como idade, novamente pegue, itens no cache 1, vou remover este objeto novamente itens no cache 0 insira-o mais uma vez, insira está em add assim como pegue o objeto de volta e então eu posso mostrar isso no cache. Então, eu estava lidando com um objeto neste momento e a chave era cliente no nome do cliente anexado a ele e então vou iniciar o carregamento, teste agora. Você veria alguma atividade no cache, há solicitações chegando e você tem solicitações de clientes lidando com os dados.
E se eu simplesmente executar essas chaves de cache de despejo novamente, ele apenas me mostrará as cem chaves despejadas juntas. Então, essas são as chaves que eu adicionei. Então, é assim que é simples começar com o cache de objetos, qualquer dado que pertença ao banco de dados e atrasa as coisas, limita sua escalabilidade, você pode trazê-lo para NCache usando nosso cache de objetos. Pode ser qualquer objeto de domínio, coleções, conjuntos de dados, imagens, qualquer tipo de dados relacionados a aplicativos que podem ser armazenados em cache usando o modelo de cache de objetos. Espero que isso ajude, deixe-me começar com isso, tudo bem, isso abrange nosso cache de dados, em seguida, há SignalR Backplane.
ASP.NET SignalR Backplane Amostra
Vamos falar sobre Sinal R. Com NCache temos um poderoso mensagens pub/sub plataforma. Então, temos um aplicativo de exemplo e neste também mostrarei os pacotes NuGet. NCache bibliotecas vêm instaladas com a instalação ou você pode usar nossos pacotes NuGet. Então, se você for ao nosso repositório NuGet online e procurar NCache, você verá todos os pacotes NuGet. Alachisoft.NCache.SDK é para cache de objetos, Linq para consulta linq, temos provedor de estado de sessão, então temos código aberto e comunidade também.
Este é o pacote NuGet que incluí neste aplicativo. Basta construí-lo e vamos ver se funciona bem porque deve ter um pacote NuGet adicionado a ele. Tudo bem, para SignalR Backplane tudo o que você precisa fazer é certificar-se de ter o pacote SignalR NuGet adicionado, quero dizer, isso é instalar se ainda não estiver instalado, tudo bem. Então, você tem um pacote NuGet adicionado e depois disso você precisa adicionar, ele adicionou alguns assemblies SignalR conforme necessário e alguns assemblies de ajuda também e depois disso, se você for para o web.config, acabei de adicionar algumas configurações lá myname do cache é aspnetcache certo e depois a chave do evento, que é o nome do tópico que você gosta para isso. Então, você realmente gostaria de fornecer um nome de tópico com base no qual você gostaria de ter mensagens de bate-papo do SignalR ou mensagens do SignalR para esse aplicativo de bate-papo específico transmitido e, em seguida, tudo o que você precisa fazer é alterar uma linha de código dentro de onde você especifica o nome do cache e a chave do evento e apontar para palavras NCache e execute o aplicativo de amostra. Ele usaria automaticamente NCache para Backplan SignalR, NCache torna-se seu plano de fundo, é tão simples conectar NCache para o aplicativo SignalR.
Benefícios que você obtém seu .NET nativo ao contrário Redis é rápido, escalável, confiável em comparação com bancos de dados, bem como barramentos de mensagens e, em seguida, temos um modelo pub/sub totalmente funcional e totalmente suportado, que está apoiando isso. Portanto, você também pode usar mensagens pub/sub diretamente, mas uma extensão desse caso de uso de mensagens pub/sub é nossa SignalR Backplane e é muito fácil de configurar também.
Então, este aplicativo foi iniciado. Deve haver uma chave aqui, acho difícil encontrar a chave, mas apenas para mostrar o bate-papo NCache, isso funciona e vou transmitir isso para outro navegador assinando outro usuário, digamos Nick. Se eu trouxer isso de volta, você poderá ver que ele também transmitiu a mensagem para o outro cliente conectado. Então, é assim que é fácil. Deixe-me perguntar mais uma vez e depois verificar se está funcionando conforme o esperado, então é isso. Então, isso está sendo conduzido NCache e é muito fácil de configurar e é assim que você configura e o último recurso dentro NCache, o quinto booster é o cache de saída.
Ron, tenho uma pergunta sobre o SignalR, nossas mensagens do SignalR armazenadas como um objeto visual dentro NCache ou faz NCache usar notificação para isso? NCache usa a notificação pub/sub para isso. Então, nós temos uma plataforma de mensagens pub/sub que está em segundo plano, no próprio cache você veria apenas um objeto ou nem mesmo veria o objeto porque é um tópico. Então, há um tópico que é criado, é um túnel lógico onde vários processos de trabalho estão conectados e eles realmente transmitem NCache, todas as mensagens do SignalR para esse tópico. Portanto, é uma estrutura de notificação se você estiver perguntando, se você ver muitas mensagens adicionadas no cache, não, não, você verá apenas um tópico e, em seguida, haverá mensagens dentro do tópico. Existem algumas estatísticas nos encontros popper que você pode visualizar para ver quantas mensagens existem dentro do tópico, mas no que diz respeito a objetos individuais, você não verá esses objetos, apenas verá um objeto como um tópico. Espero que isso ajude.
Exemplo de cache de saída ASP.NET
Recurso final dentro disso, acho que também estamos com pouco tempo, vou passar rapidamente por isso. É o nosso cache de saída, você só precisa configurar a seção de cache de saída, você precisa de referência NCache dll do provedor de cache de saída. Isso é aqui, você precisa dessas referências Ncache.Adaptadores, web, runtime em cache e depois disso você simplesmente refere o provedor de cache de saída N e então configura o nome do cache para aspnetcache, a versão deve ser a mais recente. A maneira como funciona é que ele realmente armazena em cache a saída de páginas estáticas, você simplesmente o executa e, em seguida, ele apenas armazena em cache a saída de uma página estática. Se é a página inteira ou partes da página que são estáticas e você decora suas páginas estáticas com esse cache de saída da diretiva, especifique uma duração, localização e VaryByParam. Se esses parâmetros não estiverem mudando, isso significa automaticamente que esta é a mesma saída.
Assim, a saída em cache é apresentada aos usuários finais, você não precisa executar as páginas, não precisa envolver bancos de dados, aliviar a carga dos processos de trabalho, desligar o banco de dados, economizar recursos caros de CPU e máquina e obtenha uma saída de página pronta disponível para seus clientes finais. Então, no geral melhora seu desempenho, o ASP.NET fornece isso como um recurso e NCache leva a um nível distribuído onde temos saída de página muito escalável, muito rápida e muito confiável armazenada em NCache sem nenhuma alteração de código e isso é verdade para ASP.NET core também, você poderia usar pela maneira que você pode usar NCache dentro do ASP.NET core aplicações web também. Fizemos um webinar separado sobre isso e se temos cache distribuído, temos armazenamento de sessão e também temos ASP.NET core cache de resposta, bem como o cache principal do EF.
Então, esses são alguns dos recursos que eu queria destacar, isso completa nossos cinco impulsionadores de desempenho. Espero que tenham gostado, por favor me avisem se houver mais alguma dúvida, acho que estamos com muito pouco tempo também. Então, se houver outras perguntas agora é hora de fazer essas perguntas, então, por favor, me avise.
Em geral, também gostaria de mencionar que NCache é um cluster de cache dinâmico de tempo de atividade cem por cento totalmente elástico, sem ponto único de falha. Temos muitas topologias e recursos como criptografia, segurança, compactação, alertas de e-mail, sincronização de banco de dados, pesquisas do tipo SQL, consulta contínua, modelo pub/sub, dados relacionais em NCache, todos eles são cobertos como parte de diferentes recursos. Então, se houver alguma pergunta específica sobre isso, sinta-se à vontade para fazer essas perguntas também, caso contrário, vou apenas concluir e entregá-la ao Nick.
Muito obrigado Ron uma última pergunta aqui é possível configurar um provedor personalizado para cache de sessão em NCache? NCache já é um provedor personalizado. NCache está sob um provedor personalizado, os modos padrão são InProc, State Server ou SQL Server e, em seguida, o quarto modo do ASP.NET é um personalizado. Então, NCache provedor em si é um provedor personalizado. Estou um pouco confuso com a pergunta, se houver algum requisito específico em torno disso, informe-me caso contrário NCache em si é um provedor personalizado para ASP.NET.
Ok, muito obrigado Ron, se não houver mais perguntas, eu gostaria de agradecer a todos por terem vindo e se juntar a nós hoje e obrigado Ron novamente por sua valiosa visão sobre isso e, pessoal, se você tiver alguma dúvida, sempre pode nos contatar enviando e-mails no support@alachisoft.com. Você entra em contato com nossa equipe de vendas enviando um e-mail para sales@alachisoft.com e alguém da equipe de vendas ficará feliz em trabalhar com você e garantir que todas as suas dúvidas sejam respondidas, fornecer todas as informações que você precisa e com isso eu também sugiro que você baixe uma versão de teste do nosso site de NCache, vem com um teste de 30 dias. Também temos uma mediação que tem uma opção de suporte pago, bem como edição gratuita de código aberto, treze anos com muito conteúdo. Obrigado a todos por se juntarem a nós e nos vemos na próxima vez, obrigado.