Piel escamosa ASP.NET SignalR Aplicaciones para el máximo rendimiento

Introducción

ASP.NET es una plataforma muy popular para desarrollar aplicaciones web en tiempo real, ya que proporciona a los desarrolladores un amplio conjunto de funciones de asistencia para el desarrollo. Una de esas características es SignalR, que puede ayudarlo a desarrollar de manera eficiente aplicaciones ASP.NET de procesamiento de datos en tiempo real.

SignalR ("R" significa en tiempo real) es una conocida biblioteca de código abierto para desarrolladores web ASP.NET que le permite enviar contenido desde el lado del servidor a todos los clientes conectados tan pronto como la información esté disponible. Esto ayuda a simplificar los esfuerzos de desarrollo necesarios para agregar funcionalidad web en tiempo real a sus aplicaciones.

¿Por qué debería usar ASP.NET SignalR?

SignalR le brinda la capacidad dentro de sus aplicaciones ASP.NET para que el código del lado del servidor envíe contenido a los clientes ligeros conectados instantáneamente, a medida que esté disponible en lugar de esperar a que los clientes realicen otra solicitud de nuevos datos. Los clientes ya no necesitan confiar en el mecanismo de sondeo HTTP típico y, en su lugar, SignalR utiliza un mecanismo de inserción para que el nuevo contenido esté disponible para los clientes. Esto ayuda a mejorar el rendimiento general de la aplicación y la experiencia del usuario.

SignalR tiene una API muy simple que es muy fácil de usar para llamar a las funciones de JavaScript del lado del cliente dentro del navegador del cliente directamente desde el lado del servidor. Utiliza llamadas a procedimientos remotos (RPC) para invocar la comunicación de ClientServer y también proporciona un código .NET completo para la administración de conexiones de Client-Server.

SignalR maneja la funcionalidad de comunicación completa entre servidores y clientes y no necesita implementar esto usted mismo. Para tener un intercambio de mensajes súper rápido, SignalR incorpora una capa de transporte. Todo lo que necesita hacer es introducir los recursos de SignalR en su aplicación ASP.NET y comenzar a utilizar sus métodos.

Aquí hay un diagrama de alto nivel como referencia.

SignalR maneja todas las conexiones internamente y en el back-end, se usan Web Sockets si el cliente lo admite (HTML5 y en adelante). Si Web Sockets no está disponible, automáticamente recurre al mecanismo de transporte anterior cuando sea necesario. Esto simplifica sus esfuerzos de desarrollo y ya no tiene que escribir y administrar este código de comunicación usted mismo.

Creando tu primera ASP.NET SignalR Aplicación

Usar SignalR en su aplicación es mucho más fácil de lo que piensa. En este caso, tomemos un ejemplo de Chat Hub. Puede comenzar creando un proyecto web ASP.NET simple con la adición de SignalR. Ahora, para el programa Chat Hub, puede invocar clases de hub genéricas que contienen métodos integrados para la comunicación con conexiones SignalR.

Así es como se importa el Concentrador Microsoft.AspNet.SignalR clase en su programa de muestra que llama a un ejemplo mensaje de difusión en todos los 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: implementación de la clase SignalR ChatHub

El siguiente ejemplo define el método en un cliente de JavaScript.

//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: implementación de JavaScript

ASP.NET SignalR Casos de uso

Cualquier aplicación ASP.NET que utilice una funcionalidad web en tiempo real es la candidata adecuada para incorporar SignalR en su arquitectura. En otras palabras, este es un escenario en el que la aplicación envía una gran cantidad de contenido nuevo del servidor al cliente y el usuario necesita consumirlo a medida que cambian los datos.

De manera similar, SignalR se puede usar para mejorar el rendimiento de las aplicaciones que usan el mecanismo de sondeo largo de AJAX para recuperar datos nuevos. Por lo tanto, tan pronto como haya una actualización de datos en la aplicación ASP.NET, SignalR llamará automáticamente a los métodos de JavaScript del lado del cliente para solicitar los datos. Esto garantiza que las actualizaciones en tiempo real se envíen instantáneamente a los clientes web.

A continuación se mencionan algunos casos de uso populares para SignalR.

1. Sistemas de chat
2. Internet de los objetos (IO)
3. Aplicaciones de juegos
4. Sistemas de reserva de aerolíneas
5. Aplicaciones de Bolsa
6. Más...

El problema: SignalR no es escalable desde el primer momento

Si bien la implementación de la biblioteca SignalR en su aplicación ASP.NET puede ser una buena elección, su incapacidad para escalar linealmente en realidad puede frustrar todo su propósito. Este es el por qué:

Como SignalR está trabajando en un modelo basado en sockets web, su implementación de servidor único funciona bien con todos los mensajes que se envían a todos los clientes conectados al servidor web.

Sin embargo, un solo servidor pronto puede alcanzar su capacidad en función del aumento de la carga de solicitudes de aplicaciones. En este punto, debe escalar agregando más servidores web y creando una 'granja web'. Mientras lo hace, las solicitudes de sus clientes se distribuyen y, por lo tanto, también pueden enrutarse a diferentes servidores web. Un cliente que está conectado a un servidor web a través de sockets web no recibirá mensajes enviados desde otro servidor web. Esto conducirá a una situación en la que los clientes no recibirán mensajes de SignalR y no estarán sincronizados.

Esos clientes en realidad van a esperar hasta que sus propios servidores web respectivos impulsen esa funcionalidad, lo que aumentará la latencia. Además, en una aplicación basada en varios servidores, no es necesario que todos los servidores web invoquen los nuevos datos entrantes. Por lo tanto, hay grandes posibilidades de que estos nuevos datos no se envíen a los respectivos clientes y los mensajes se pierdan por completo.

Tomemos como ejemplo una aplicación del mercado de valores en tiempo real, donde miles de valores de acciones cambian cada segundo. En tal escenario, los clientes finales necesitan información precisa y absolutamente correcta cada vez que cambia un precio.

Los mercados de valores manejan grandes cantidades de datos de transacciones altas y es muy importante tener toda la información enviada a todos los usuarios de manera oportuna. Tener una granja web puede causar un aumento de la latencia para algunos usuarios y algunos usuarios pueden perderse actualizaciones importantes por completo. Esto crea una mala experiencia de usuario y tendrá un impacto negativo en su negocio.

Para contrarrestar estos problemas, Microsoft ofrece la opción de usar un backplane, que generalmente se puede definir como un almacén de mensajes central, al que todos los servidores web están conectados simultáneamente.

SignalR backplane permite que los servidores web se conecten y envíen todos los mensajes a sí mismos primero en lugar de enviarlos a sus propios clientes conectados. Backplane luego transmite estos mensajes a todos los servidores web que internamente transmiten estos mensajes a sus clientes conectados. Esto garantiza que todos los mensajes se envíen a todos los clientes finales, incluso los invocados por el servidor web donde el cliente no estaba conectado.

SignalR backplane podría ser un disco, una base de datos, un bus de mensajes o una caché distribuida en memoria. Permítanme discutir las opciones de backplane más utilizadas y sus problemas asociados.

Problemas con la base de datos relacional como SignalR Backplane

SignalR se utiliza en aplicaciones en tiempo real que manejan grandes volúmenes de datos. Backplane debe ser capaz de gestionar la carga extrema de mensajes y eso también de una manera rápida y confiable. La base de datos relacional se usa comúnmente como backplane, lo que no es muy adecuado ya que el backplane debe ser de naturaleza escalable.

Tomemos un ejemplo en el que tiene una aplicación de comercio electrónico ASP.NET que se implementa en 10 servidores web en una granja web. Todos estos 10 servidores web tienen sus clientes independientes basados ​​en navegador conectados a ellos a través de SignalR y los servidores web también están conectados a un Backplane que es una base de datos en este caso.

Si uno de los servidores web genera 1 mensaje, cada uno de los cuales hace un total de 10 mensajes, estos 10 mensajes se transmitirán al backplane y la base de datos transmitirá todos estos mensajes a todos los 10 servidores web conectados. Esto totaliza hasta 100 mensajes transmitidos por la base de datos.

Ahora imagine la misma configuración pero la aplicación es notoriamente habladora y sus servidores producen un total de 10000 mensajes (1000 mensajes por servidor web) en un momento dado. El backplane tendrá que transmitir 100000 mensajes (10000 x 10) al mismo tiempo. Puede ver lo fácil que es para la base de datos ahogarse cuando aumenta el número de solicitudes.

Estos son algunos problemas cuando se utilizan bases de datos relacionales para SignalR backplane:

1. Por lo general, la carga de transacciones es muy alta y se requiere una entrega más rápida para descartar el factor de latencia. Las bases de datos relacionales son lentas e incluso pueden colapsar bajo cargas máximas de procesamiento de datos en tiempo real.
2. Al estar basada en un disco, una base de datos relacional nunca puede funcionar lo suficientemente rápido como para lograr la cantidad deseada de rendimiento bajo una carga alta.
3. Lo que es más importante, las bases de datos relacionales claramente carecen de la capacidad de escalado lineal en la que no se pueden agregar más servidores para manejar más carga.

Problemas con Redis as SignalR Backplane

La segunda opción puede ser usar Redis como tu SignalR backplane que, aunque resuelve los problemas relacionados con el rendimiento y la escalabilidad que tiene con las bases de datos relacionales, tampoco es una elección adecuada. Estas son algunas de las razones en torno a esto:

• Redis es un caché distribuido basado en Linux y no es una opción nativa de .NET. Uso de un sistema basado en Linux para ASP.NET SignalR no tiene mucho sentido donde tendrá que tener una pila de Linux junto con Windows y necesitará experiencia separada para administrar y monitorear esta configuración.
• Un desarrollador de .NET siempre anhela una pila de .Net 100 % nativa mientras desarrolla dichas aplicaciones web en tiempo real. Será contrario a la intuición administrar una solución .NET no nativa como SignalR backplane mientras que todos los demás módulos de la aplicación son .NET 100 % nativos.
• Otra limitación en Redis es que su versión portada de Windows .NET en la plataforma Microsoft Azure está llena de errores según las revisiones de los usuarios, lo que incluso se abstiene Redis de usar su propia versión portada de .NET Windows en Azure.

Esto hace Redis, una elección ambivalente entre los desarrolladores de .NET desde el punto de vista de la compatibilidad.

La solución: usar NCache as SignalR Backplane

NCache es un sistema de almacenamiento en caché distribuido en memoria desarrollado por Alachisoft y es la opción más adecuada para ser utilizada como backplane. NCache es un grupo de servidores de caché económicos que se agrupan para proporcionar memoria escalable y capacidad de CPU. Es esencialmente, una capacidad lógica de múltiples servidores que viene con todas las capacidades para ser utilizado como un SignalR backplane.

La mejor parte de usar NCache como tu SignalR backplane es que es .NET cien por cien nativo y no necesita cambios importantes en el código de su aplicación ASP.NET. Es como una opción plug-nplay que no solo le brinda la capacidad de administrar sus mensajes de backplane, sino que también puede monitorear estos mensajes usando el NCache herramientas de seguimiento del rendimiento.

NCache proporciona la extensión SignalR para que se use como backplane en sus aplicaciones ASP.NET.

Todos sus servidores web en la granja web están registrados con NCache usando NCache Plataforma de mensajería Pub/Sub. Sus servidores web registran un tema específico para los mensajes de SignalR y NCache luego transmite estos mensajes a todos los servidores web. Es básicamente una estructura de transmisión de mensajes bidireccional donde sus editores pueden ser suscriptores y viceversa.

Enchufar NCache como backplane en su aplicación basada en SignalR, solo necesita introducir una línea de código, que se menciona en la guía de implementación paso a paso.

¿Por qué NCache Backplane es mejor que SQL Server?

Para lograr la mejor experiencia de usuario en su aplicación ASP.NET, NCache actúa como un backplane muy rápido, confiable y escalable para manejar grandes cantidades de notificaciones. A continuación se mencionan algunas ventajas clave de usar NCache en lugar de RDBM como backplane.

1. NCache es linealmente escalable (alto rendimiento y baja latencia)

   La característica más importante de NCache backplane es que ofrece un rendimiento máximo y una latencia mínima. Maneja sin problemas grandes cantidades de datos de manera rápida al mantener todo el procesamiento de mensajes en la memoria, descartando cualquier posibilidad de aumento de la latencia.

   Para entregar todos los mensajes a tiempo, NCache ofrece el máximo rendimiento durante la transmisión al distribuir la carga en todos los servidores disponibles en el clúster de caché y también le permite agregar más servidores en tiempo de ejecución.

   Aquí hay algunos números de referencia de rendimiento para una referencia.

   

   Esto le brinda una escalabilidad lineal general dentro de la arquitectura de su aplicación y no tiene que preocuparse por la disminución del rendimiento de su aplicación y específicamente bajo cargas extremas.

2. NCache es extremadamente confiable

   La segunda característica de NCache backplane es su extrema fiabilidad. Para asegurar una entrega garantizada de mensajes, especialmente en el caso de aplicaciones de misión crítica, NCache se puede usar como backplane para que no tenga que preocuparse por la pérdida de ninguno de sus mensajes debido a que los servidores se caen o se desconectan por mantenimiento. Mantiene una copia de seguridad de cada servidor de caché utilizado en el clúster para SignalR backplane que está disponible automáticamente en caso de que un servidor se caiga.

   La extrema fiabilidad de NCache se atribuye a su característica que transmite todos los mensajes a todos y cada uno de los servidores web que están conectados al backplane. La copia de seguridad de sus datos en otros servidores garantiza que mientras sus aplicaciones de misión crítica transfieren cargas pesadas, no hay posibilidad de pérdida de datos.

3. NCache es altamente disponible

   Otra característica importante de NCache backplane es su alta disponibilidad. Con NCache instalado como su SignalR backplane, su sistema se vuelve altamente disponible ya que sus mensajes ahora se transfieren a través de un clúster de caché siempre activo.

   NCache La arquitectura garantiza la característica de alta disponibilidad a través de su 'Clúster de caché siempre activo' que puede basarse en una de nuestras diversas topologías de almacenamiento en caché. Por ejemplo, la topología 'Partición-réplica' le proporciona una partición activa en todos los servidores y cada servidor tiene una copia de seguridad de la misma. Entonces, si un servidor falla, los clientes lo detectan automáticamente y conmutan por error su conexión a los otros nodos supervivientes.

   El clúster de caché de NCache es capaz de funcionar incluso si solo 1 servidor está activo y funcionando y eso es lo que necesita como mínimo para un escenario de tiempo de actividad del cien por ciento. Esta característica vale la pena en los casos en que sus servidores se ven afectados por una calamidad natural o si los detiene intencionalmente por motivos de mantenimiento. En resumen, las topologías pragmáticas de almacenamiento en caché de NCache ayudarlo a lograr un tiempo de actividad del 100 % en sus aplicaciones basadas en SignalR.

   

¿Por qué NCache es mejor que Redis?

NCache también es mejor que Redis desde el punto de vista de las características. Para descartar todas las deficiencias que enfrentan los desarrolladores en Redis sistema de caché distribuido, NCache tiene estas tres características superlativas.

• .NET nativo: NCache es .NET 100 % nativo y, por lo tanto, se adapta perfectamente a las aplicaciones ASP.NET que utilizan SignalR. Por otra parte, Redis proviene de un fondo de Linux y no es un caché nativo de .NET.
• Más rápido que Redis: NCache es más rápido que Redis. NCache La función Caché de cliente ofrece NCache un aumento significativo del rendimiento.
• Más características: NCache ofrece una serie de funciones de caché distribuida muy importantes que Redis no es. Ver más detalles en este Redis vs NCache

Poner en marcha NCache SignalR Backplane

Puedes desplegar NCache como tu SignalR Backplane con solo un cambio de línea y puede seguir el tutorial paso a paso a continuación para equipar sus aplicaciones para esto.

1. Instalar el paquete NuGet

   Comience instalando el Alachisoft.NCache.SeñalR Paquete NuGet a su aplicación ejecutando el siguiente comando en la Consola del administrador de paquetes:

   Install-Package Alachisoft.NCache.SignalR

2. Incluir espacio de nombres

   En su Inicio.cs archivo, incluya estos dos espacios de nombres como se menciona a continuación:

   • Alachisoft.NCache.SeñalR
   • Microsoft.AspNet.SignalR
3. Modificar Web.config

   En su archivo Web.config, deberá definir el cacheName y clave de evento existentes tag:

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

   Figura 8: Cambios en Web.config

4. Registro NCache as SignalR Backplane para su aplicación

   Registrar una instancia del UsoNCache() en Startup.cs de su aplicación en cualquiera de las siguientes 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)

Conclusión

Para concluir todo, NCache es esencialmente un caché distribuido en memoria basado en .NET que se puede usar en todas las aplicaciones web ASP.NET en tiempo real como backplane para su SignalR para aumentar el rendimiento de su aplicación web.

Las características que lo diferencian de otras opciones disponibles incluyen su rendimiento ultrarrápido, 100 % de tiempo de actividad, confiabilidad de los datos, entrega garantizada de mensajes y la capacidad de mantener el máximo rendimiento con la mínima latencia.

¿Qué hacer a continuación?

• NCache Detalles
• Comparación de ediciones
• Descargar NCache
• NCache vs AppFabric
• NCache vs Redis
• NCache vs Memcached