Escala ASP.NET SignalR Aplicativos para desempenho máximo

Introdução

O ASP.NET é uma plataforma muito popular para o desenvolvimento de aplicativos da Web em tempo real, pois fornece aos desenvolvedores um rico conjunto de recursos de assistência ao desenvolvimento. Um desses recursos é o SignalR, que pode ajudá-lo a desenvolver aplicativos ASP.NET de processamento de dados em tempo real com eficiência.

SignalR ("R" significa tempo real) é uma biblioteca de código aberto bem conhecida para desenvolvedores da Web ASP.NET que permite enviar conteúdo do lado do servidor para todos os clientes conectados assim que as informações estiverem disponíveis. Isso ajuda a simplificar os esforços de desenvolvimento necessários para adicionar funcionalidades da Web em tempo real aos seus aplicativos.

Por que você deve usar ASP.NET SignalR?

O SignalR oferece a você a capacidade dentro de seus aplicativos ASP.NET de ter conteúdo push de código do lado do servidor para thin clients conectados instantaneamente, à medida que se torna disponível em vez de esperar que os clientes façam outra solicitação de novos dados. Os clientes não precisam mais depender do mecanismo de pesquisa HTTP típico e, em vez disso, o SignalR usa o mecanismo push para que o novo conteúdo seja disponibilizado aos clientes. Isso ajuda a melhorar o desempenho geral do aplicativo e a experiência do usuário.

O SignalR possui uma API muito simples que é muito fácil de usar para chamar funções JavaScript do lado do cliente dentro do navegador do cliente diretamente do lado do servidor. Ele usa chamadas de procedimento remoto (RPC) para invocar a comunicação ClientServer e também fornece código .NET completo em torno do gerenciamento de conexão Client-Server.

O SignalR lida com a funcionalidade de comunicação completa entre servidores e clientes e você não precisa implementar isso sozinho. Para ter uma troca de mensagens super rápida, uma camada de transporte é incorporada ao SignalR. Tudo o que você precisa fazer é introduzir os recursos do SignalR em seu aplicativo ASP.NET e começar a usar seus métodos.

Aqui está um diagrama de alto nível para referência.

SignalR lida com todas as conexões internamente e no backend, Web Sockets são usados ​​se suportados pelo cliente (HTML5 e posteriores). Se os Web Sockets não estiverem disponíveis, ele retornará automaticamente ao mecanismo de transporte mais antigo, quando necessário. Isso simplifica seus esforços de desenvolvimento e você não precisa mais escrever e gerenciar esse código de comunicação por conta própria.

Criando o seu primeiro ASP.NET SignalR Aplicação

Usar o SignalR em seu aplicativo é muito mais fácil do que você pensa. Neste caso, vamos dar um exemplo de um Chat Hub. Você pode começar criando um projeto Web ASP.NET simples com a adição de SignalR. Agora, para o programa Chat Hub, você pode invocar classes de hub genéricas que contêm métodos internos para comunicação com conexões SignalR.

Veja como você importa o Hub Microsoft.AspNet.SignalR class em seu programa de exemplo que chama um exemplo mensagem de transmissão em todos os clientes conectados.

namespace SignalRChat
{
   public class ChatHub : Hub
   {
      public void Send(string name, string message)
      {
         // Call the broadcastMessage method to update clients.
         Clients.All.broadcastMessage(name, message);
      }
   }
}

Figura 2: implementação da classe SignalR ChatHub

O exemplo a seguir define o método em um cliente JavaScript final.

//Add script to update the page and send messages.
   <script type="text/javascript">
      $(function () {
         //Declare a proxy to reference the hub.
         var chat = $.connection.chatHub;
		 
         // Create a function that the hub can call to broadcast messages.
         } chat.client.broadcastMessage = function (name, message) {
         // Html encode display name and message.
         ...
         });
   </script>

Figura 3: implementação de JavaScript

ASP.NET SignalR Casos de uso

Qualquer aplicativo ASP.NET que esteja usando uma funcionalidade da Web em tempo real é o candidato certo para incorporar o SignalR em sua arquitetura. Em outras palavras, este é um cenário em que o aplicativo está enviando muito conteúdo novo do servidor para o cliente e o usuário precisa consumi-lo à medida que os dados mudam.

Da mesma forma, o SignalR pode ser usado para aprimorar o desempenho dos aplicativos que usam o mecanismo de pesquisa longo AJAX para recuperar novos dados. Assim, assim que houver uma atualização de dados no aplicativo ASP.NET, os métodos JavaScript do lado do cliente são chamados pelo SignalR automaticamente para solicitar o dat. Isso garante que as atualizações em tempo real sejam enviadas aos clientes da Web instantaneamente.

Alguns casos de uso populares para SignalR são mencionados abaixo.

1. Sistemas de bate-papo
2. Internet of Things (IoT)
3. Aplicativos de jogos
4. Sistemas de reservas de companhias aéreas
5. Aplicativos da Bolsa de Valores
6. Mais…

O problema: SignalR não é escalável fora da caixa

Embora a implementação da biblioteca SignalR em seu aplicativo ASP.NET possa ser uma escolha sábia, sua incapacidade de escalar linearmente pode prejudicar todo o seu propósito. Aqui está o porquê:

Como o SignalR está trabalhando em um modelo baseado em soquetes da Web, sua implantação de servidor único funciona bem com todas as mensagens sendo enviadas para todos os clientes conectados ao servidor da Web.

No entanto, um único servidor pode atingir a capacidade em breve com base no aumento da carga de solicitações de aplicativos. Neste ponto, você precisa expandir adicionando mais servidores da Web e criando um 'Web Farm'. Ao fazer isso, suas solicitações de clientes são distribuídas e, portanto, também podem ser roteadas para diferentes servidores da web. Um cliente conectado a um servidor web por meio de soquetes web não receberá mensagens enviadas de outro servidor web. Isso levará a uma situação em que os clientes não receberão mensagens do SignalR e permanecerão fora de sincronia.

Esses clientes vão realmente esperar até que essa funcionalidade seja enviada por seus próprios servidores da Web, o que aumentará a latência. Além disso, em um aplicativo baseado em vários servidores, não é necessário que todos os servidores da Web invoquem os novos dados de entrada. Portanto, há grandes chances de que esses novos dados não sejam enviados para os respectivos clientes e as mensagens sejam completamente perdidas.

Tomemos como exemplo um aplicativo do Real Time Stock Market, onde milhares de valores de ações estão mudando a cada segundo. Nesse cenário, os clientes finais precisam de informações precisas e absolutamente corretas toda vez que algum preço é alterado.

Os mercados de ações lidam com grandes quantidades de dados de transações altas e é muito importante que todas as informações sejam enviadas a todos os usuários em tempo hábil. Ter um Web farm pode aumentar a latência para alguns usuários, assim como alguns usuários podem perder completamente as atualizações importantes. Isso cria uma experiência de usuário ruim e afetará negativamente seus negócios.

Para combater esses problemas, a Microsoft oferece a opção de usar um backplane, que geralmente pode ser definido como um armazenamento central de mensagens, ao qual todos os servidores da Web estão conectados simultaneamente.

SignalR backplane permite que os servidores da Web se conectem e enviem todas as mensagens para si mesmos primeiro, em vez de enviar para seus próprios clientes conectados. O Backplane então transmite essas mensagens para todos os servidores web que internam, transmitem essas mensagens para seus clientes conectados. Isso garante que todas as mensagens sejam enviadas para todos os clientes finais, mesmo invocados pelo servidor web onde o cliente não estava conectado.

SignalR backplane pode ser um disco, um banco de dados, um barramento de mensagens ou um cache distribuído na memória. Deixe-me discutir as opções de backplane mais usadas e seus problemas associados.

Problemas com banco de dados relacional como SignalR Backplane

SignalR é usado em aplicações em tempo real que lidam com grandes volumes de dados. O Backplane precisa ser capaz de gerenciar cargas extremas de mensagens e isso também de maneira rápida e confiável. O banco de dados relacional é comumente usado como backplane, o que não é muito adequado, pois o backplane precisa ser escalável por natureza.

Vamos dar um exemplo em que você tem um aplicativo ASP.NET E-Commerce implantado em 10 servidores Web em um web farm. Todos esses 10 servidores da Web têm seus clientes baseados em navegador separados conectados a eles por meio do SignalR e os servidores da Web também estão conectados a um Backplane que é um banco de dados neste caso.

Se um dos servidores da Web gerar 1 mensagem cada um totalizando 10 mensagens, essas 10 mensagens serão transmitidas para o backplane e o banco de dados transmitirá todas essas mensagens para todos os 10 servidores da Web conectados. Isso totaliza até 100 mensagens sendo transmitidas pelo banco de dados.

Agora imagine a mesma configuração, mas o aplicativo é notoriamente chato e seus servidores produzem um total de 10000 mensagens (1000 mensagens por servidor Web) a qualquer momento. O backplane terá que transmitir 100000 mensagens (10000 x 10) ao mesmo tempo. Você pode ver como é fácil para o banco de dados engasgar quando o número de solicitações aumenta.

Aqui estão alguns problemas quando bancos de dados relacionais são usados ​​para SignalR backplane:

1. Normalmente, a carga da transação é muito alta e é necessária uma entrega mais rápida para descartar o fator de latência. Os bancos de dados relacionais são lentos e podem até mesmo ficar bloqueados sob cargas de processamento de dados em tempo real de pico.
2. Sendo baseado em um disco, um banco de dados relacional nunca pode funcionar rápido o suficiente para atingir a quantidade desejada de taxa de transferência sob alta carga.
3. Mais importante, os bancos de dados relacionais claramente carecem da capacidade de dimensionamento linear em que você não pode adicionar mais servidores para lidar com mais carga.

Problemas com Redis as SignalR Backplane

A segunda opção pode ser usar Redis como seu SignalR backplane que embora resolva problemas relacionados a desempenho e escalabilidade que você tem com bancos de dados relacionais, mas também não é uma escolha adequada a ser feita. Aqui estão algumas das razões em torno disso:

• Redis é um cache distribuído baseado em Linux e não é uma opção nativa do .NET. Usando um sistema baseado em Linux para ASP.NET SignalR não faz muito sentido onde você terá que ter uma pilha Linux junto com o Windows e precisará de conhecimentos separados para gerenciar e monitorar essa configuração.
• Um desenvolvedor .NET sempre anseia por uma pilha .Net 100% nativa ao desenvolver esses aplicativos da Web em tempo real. Será contra intuitivo gerenciar uma solução .NET não nativa como um SignalR backplane enquanto todos os outros módulos de aplicação são 100% nativos .NET.
• Outra limitação em Redis é que sua versão portada do Windows .NET na plataforma Microsoft Azure está cheia de bugs, conforme as avaliações dos usuários, que até se abstêm Redis de usar sua própria versão .NET Windows portada no Azure.

Isto torna Redis, uma escolha ambivalente entre desenvolvedores .NET do ponto de vista da compatibilidade.

A solução: usar NCache as SignalR Backplane

NCache é um sistema de cache distribuído na memória desenvolvido por Alachisoft e é a opção mais adequada para ser usada como backplane. NCache é um cluster de servidores de cache baratos que são agrupados para fornecer memória escalável e capacidade de CPU. É essencialmente, uma capacidade lógica de vários servidores que vem com todos os recursos para serem usados ​​como SignalR backplane.

A melhor parte sobre o uso NCache como seu SignalR backplane é que ele é cem por cento .NET nativo e você não precisa de grandes alterações de código em seu aplicativo ASP.NET. É como uma opção plug-nplay que não apenas oferece a capacidade de gerenciar suas mensagens de backplane, mas você também pode monitorar essas mensagens usando o NCache ferramentas de monitoramento de desempenho.

NCache fornece extensão SignalR para ser usado como backplane em seus aplicativos ASP.NET.

Todos os seus servidores web no web farm estão registrados com NCache utilização NCache Plataforma de mensagens Pub/Sub. Seus servidores da Web registram um tópico específico para mensagens do SignalR e NCache em seguida, transmite essas mensagens para todos os servidores Web. É basicamente uma estrutura de transmissão de mensagens bidirecional onde seus editores podem ser assinantes e da mesma forma vice-versa.

Conectar NCache como um backplane em seu aplicativo baseado em SignalR, você só precisa introduzir uma linha de código, que é mencionada no guia de implementação passo a passo.

Sua marca NCache Backplane é melhor que o SQL Server?

Para obter a melhor experiência do usuário em seu aplicativo ASP.NET, NCache atua como um backplane muito rápido, confiável e escalável para lidar com grandes quantidades de notificações. Abaixo mencionadas são algumas das principais vantagens de usar NCache em vez de RDBMs como backplane.

1. NCache é linearmente escalável (alta taxa de transferência e baixa latência)

   A característica mais importante de NCache backplane é que ele oferece taxa de transferência máxima e latência mínima. Ele lida perfeitamente com grandes quantidades de dados de maneira rápida, mantendo todo o processamento de mensagens na memória, eliminando qualquer chance de aumento de latência.

   Para entregar todas as mensagens a tempo, NCache oferece o máximo rendimento durante a transmissão, distribuindo a carga em todos os servidores disponíveis no cluster de cache, além de permitir adicionar mais servidores em tempo de execução.

   Aqui estão alguns números de benchmark de desempenho para referência.

   

   Isso oferece uma escalabilidade linear geral na arquitetura do aplicativo e você não precisa se preocupar com a queda no desempenho do aplicativo e especificamente sob cargas extremas.

2. NCache é extremamente confiável

   A segunda característica de NCache backplane é sua extrema confiabilidade. Para garantir a entrega garantida de mensagens, especialmente no caso de aplicativos de missão crítica, NCache pode ser usado como backplane para que você não precise se preocupar com a perda de nenhuma de suas mensagens devido à queda de servidores ou para manutenção. Ele mantém backup de cada servidor de Cache usado no cluster para SignalR backplane que é disponibilizado automaticamente no caso de um servidor cair.

   A extrema confiabilidade de NCache é atribuído à sua característica de transmitir todas as mensagens para todo e qualquer servidor web que esteja conectado ao backplane. O backup de seus dados em outros servidores garante que, enquanto seus aplicativos de missão crítica transferem cargas úteis pesadas, não há chances de perda de dados.

3. NCache está altamente disponível

   Outra característica importante de NCache backplane é sua alta disponibilidade. Com NCache instalado como seu SignalR backplane, seu sistema se torna altamente disponível, pois suas mensagens agora estão sendo transferidas por meio de um cluster de cache sempre ativo.

   NCache A arquitetura garante o recurso de alta disponibilidade por meio de seu 'Always Active Cache Cluster', que pode ser baseado em uma de nossas várias topologias de cache. Por exemplo, a topologia 'Partition-replica' fornece uma partição ativa em todos os servidores e cada servidor tem um backup dela. Portanto, se um servidor cair, os clientes detectam isso automaticamente e fazem o failover de sua conexão com os outros nós sobreviventes.

   O cluster de cache de NCache é capaz de funcionar mesmo se apenas 1 servidor estiver ativo e funcionando e é isso que você precisa no mínimo para um cenário de tempo de atividade de cem por cento. Esse recurso compensa nos casos em que seus servidores são atingidos por uma calamidade natural ou você os derruba intencionalmente para fins de manutenção. Em resumo, as topologias pragmáticas de cache de NCache ajudá-lo a obter um tempo de atividade de 100% em seus aplicativos baseados em SignalR.

   

Sua marca NCache é melhor do que Redis?

NCache também é melhor do que Redis do ponto de vista das características. Para descartar todas as deficiências enfrentadas pelos desenvolvedores em Redis sistema de cache distribuído, NCache tem essas três características superlativas.

• .NET nativo: NCache é 100% .NET nativo e, portanto, é perfeito para aplicativos ASP.NET usando SignalR. Por outro lado, Redis vem de um plano de fundo Linux e não é um cache .NET nativo.
• Mais rápido que Redis: NCache é mais rápida do que realmente Redis. NCache O recurso Client Cache oferece NCache um aumento significativo de desempenho.
• Mais Características: NCache oferece uma série de recursos de cache distribuído muito importantes que Redis não. Veja mais detalhes neste Redis vs NCache

Implementar NCache SignalR Backplane

Você pode implantar NCache como seu SignalR Backplane com apenas uma linha de mudança e você pode seguir o tutorial passo a passo abaixo para equipar seus aplicativos para isso.

1. Instalar o pacote NuGet

   Comece instalando o Alachisoft.NCache.SinalR pacote NuGet para seu aplicativo executando o seguinte comando no console do gerenciador de pacotes:

   Install-Package Alachisoft.NCache.SignalR

2. Incluir namespace

   Em sua Inicialização.cs arquivo, inclua esses dois namespaces conforme mencionado abaixo:

   • Alachisoft.NCache.SinalR
   • Microsoft.AspNet.SignalR
3. Modificar Web.config

   Em seu arquivo Web.config, você terá que definir o cacheName e chave do evento no etiqueta, rótulo, palavra-chave:

   <configuration>
      <appSettings>
         <add key="cache" value="myPartitionedCache"/>
         <add key="eventKey" value="Chat"/>
      </appSettings>
   </configuration>

   Figura 8: Alterações do Web.config

4. Inscrições NCache as SignalR Backplane para seu aplicativo

   Registrar uma instância do UsoNCache() em Startup.cs de seu aplicativo em uma das seguintes sobrecargas:

   Sobrecarga 1:

   public static IDependencyResolver
   	UseNCache(this IDependencyResolver resolver, string cacheName, string eventKey);
   public class Startup
   {
    	public void Configuration(IAppBuilder app)
   	{
   		string cache, eventKey;
   		cache = ConfigurationManager.AppSettings["cache"];
   		eventKey = ConfigurationManager.AppSettings["eventKey"];
   		//using NCache SignalR
   		GlobalHost.DependencyResolver.UseNCache(cache, eventKey);
   		app.MapSignalR();
   	}
   }
   

   Figura 9: Registro NCache SignalR Backplane (Sobrecarga 1)

   Sobrecarga 2:

   public static IDependencyResolver
   UseNCache(this IDependencyResolver resolver, NCacheScaleoutConfiguration configuration);
   
   public class Startup
   {
   	public void Configuration(IAppBuilder app)
   	{
   		string cache, eventKey;
   		cache = ConfigurationManager.AppSettings["cache"];
   		eventKey = ConfigurationManager.AppSettings["eventKey"];
   		NCacheScaleoutConfiguration configuration = new NCacheScaleoutConfiguration(cache, eventKey);
   		//using NCache SignalR
   		GlobalHost.DependencyResolver.UseNCache(configuration);
   		app.MapSignalR();
   	}
    ...

   Figura 10: Registro NCache SignalR Backplane (Sobrecarga 2)

Conclusão

Para concluir tudo, NCache é essencialmente um cache distribuído na memória baseado em .NET que pode ser usado em todos os aplicativos Web ASP.NET em tempo real como um backplane para seu SignalR para aumentar o desempenho de seu aplicativo Web.

Os recursos que o diferenciam de outras opções disponíveis incluem seu desempenho super-rápido, 100% de tempo de atividade, confiabilidade de dados, entrega garantida de mensagens e a capacidade de manter o rendimento máximo com latência mínima.

O que fazer a seguir?

• NCache Adicionar ao carrinho
• Comparação de edições
• Baixar NCache
• NCache vs AppFabric
• NCache vs Redis
• NCache vs Memcached