Piel escamosa ASP.NET SignalR Aplicaciones con caché distribuida
Seminario web grabado
Kal Ali y Nick Zulfiqar
ASP.NET SignalR es una biblioteca de código abierto para desarrolladores web que se usa con mucha frecuencia en estos días para agregar funcionalidad web en tiempo real a las aplicaciones. Puedes usar ASP.NET SignalR para enviar contenido desde el lado del servidor a todos los clientes conectados tan pronto como la información esté disponible.
SignalR ayuda a simplificar los esfuerzos de desarrollo necesarios para agregar funcionalidad web en tiempo real a su aplicación. Algunas aplicaciones comunes que pueden usar SignalR son los sistemas de chat, Internet de los objetos (IO), aplicaciones de juegos, sistemas de reserva de aerolíneas, aplicaciones de bolsa de valores y muchas más.
El problema con SignalR es que no es escalable por defecto. Y, para crear una granja web, Microsoft ofrece la opción de usar un SignalR backplane que se puede definir generalmente como un almacén central de mensajes y al que todos los servidores web están conectados simultáneamente. Los mensajes de SignalR se transmiten a todos los clientes finales conectados a través del backplane.
Típicamente, SignalR backplane es una base de datos relacional que es lenta y no escalable para manejar una carga de mensajes extrema, que es un requisito fundamental para las aplicaciones web en tiempo real de alto tráfico. SignalR backplane también debe ser muy confiable y altamente disponible para que tenga un cien por ciento de tiempo de actividad en el extremo de la aplicación.
En este webinar verás cómo NCache SignalR backplane es una mejor opción en comparación con las opciones tradicionales para implementar y escalar su tiempo real ASP.NET SignalR aplicaciones web con backplane. Demostramos cómo NCache se puede utilizar como su SignalR backplane sin requerir ninguna codificación importante.
Nuestro Arquitecto de Soluciones Sénior cubre:
- Introducción a los ASP.NET SignalR y sus casos de uso comunes
- Problemas con el escalado de aplicaciones SignalR y con las opciones de backplane tradicionales
- ¿Por qué NCache Backplane es una mejor opción en comparación
- Usar NCache como Backplane para sus aplicaciones ASP.NET
- NCache Paquetes Nuget para SignalR backplane
- Cree, implemente y ejecute aplicaciones SignalR usando NCache plano posterior
Entonces, hoy hablaremos sobre SignalR como la tecnología, cómo y dónde es posible que se use dentro de sus aplicaciones y cuáles son los problemas que se ven especialmente, en el caso de que introduzca el Backplane en este escenario y cómo qué Cuáles son las posibles opciones que tiene y cómo puede solucionarlas básicamente? Entonces, voy a cubrir todas esas cosas diferentes y, como producto de muestra, usaré NCache. Entonces, llegaremos a esa parte más adelante, inicialmente solo cubriremos algo de teoría básica allí.
Introducción a SignalR
Entonces, vayamos a la introducción real a SignalR. Entonces, estas son algunas definiciones que he copiado de la documentación de Microsoft. Asi que, ¿Qué es SignalR? SignalR es básicamente una biblioteca de código abierto que los desarrolladores pueden usar para introducir la funcionalidad web en tiempo real dentro de sus aplicaciones ASP.NET. Entonces, déjame darte un ejemplo para explicar cómo y qué quiero decir exactamente aquí. Por ejemplo, tiene un usuario que está accediendo a una página web y él o ella tiene una cierta cantidad de datos, que está presente en la página, pero si esos datos deben estar actualizados o si el usuario desea obtener datos actualizados en escenarios normales , el usuario tiene que actualizar la página, básicamente el usuario tiene que enviar una solicitud y luego, en respuesta a eso, se reciben los datos actualizados, esto o tiene que haber una retención prolongada que debe implementarse en la parte posterior. Pero si tiene SignalR, esto no sería necesario y voy a llegar a esos detalles más adelante y este es uno de los muy buenos casos de uso donde SignalR es un muy buen candidato.
Entonces, en segundo lugar, SignalR le brinda la capacidad de tener varios códigos para enviar contenido directamente al lado del cliente. Entonces, básicamente, la parte en la que el cliente tiene que enviar una solicitud para obtener los datos actualizados es que ya no es necesario que esté presente. Entonces, básicamente, ustedes son los clientes, todos los clientes realmente conectados al servidor web se actualizarán tan pronto como haya nuevos datos dentro del servidor. Por lo tanto, el servidor no tiene que esperar a que el cliente solicite nuevos datos. Los datos se actualizarían automáticamente en el cliente. Entonces, lo mejor de SignalR es que expone la funcionalidad para usted. Entonces, solo necesita introducir los recursos de SignalR dentro de su aplicación y necesita llamar a algunas funciones específicas y SignalR maneja todo lo demás. Entonces, su aplicación usaría SignalR para enviar un mensaje, por ejemplo, de clientes a servicios y de servidores a clientes, cualquiera que sea su escenario y todo lo demás y por todo lo demás, me refiero a la capa de transporte. Cómo se transfiere el mensaje y cómo se notifica, la lógica de SignalR se encarga de todo lo demás. Por lo tanto, no necesita hacerlo dentro de su aplicación, solo necesita introducir estas API dentro de su aplicación y SignalR maneja automáticamente todo lo demás. Entonces, en este diagrama si puedes ver aquí.
Solo te voy a dar un ejemplo. Entonces, en SignalR hay un concepto de Hub. Entonces, en este diagrama aquí, podemos ver que el servidor, este es un servidor web y este es un cliente conectado. Puede ser un cliente HTML o JavaScript. Entonces, este servidor puede llamar a esta función myClientFunc() en el extremo del cliente aquí y viceversa. Si miras este diagrama.
El cliente puede llamar a esta función específica miFunciónServidor() en el extremo del servidor. Entonces, básicamente, con HTTP, todos sabemos que es un protocolo sin estado. Hay una solicitud y luego hay una respuesta y no hay nada más, eso permanece, todo lo demás se elimina, pero con SignalR lo que sucede es que, debajo, SignalR usa WebSocket para mantener las conexiones. Entonces, estos son para las tecnologías más nuevas, pero en las más antiguas, usan lo normal en las básicas, pero usan el concepto de WebSockets a los que puede invocar funciones desde el servidor hasta el extremo del cliente y luego desde el cliente hasta el extremo del servidor depende de cómo se haga.
Entonces, permítanme explicar algunos casos de uso generales para SignalR. Entonces, el primero es un sistema de chat. Este también es un proyecto de muestra compartido por Microsoft y en mi demostración también, usaré un sistema de chat proporcionado por Microsoft y tendré NCache integrado con él, pero volvamos a los ejemplos aquí. Entonces, aquí necesita mensajes en tiempo real que deben enviarse, por ejemplo, si tiene un grupo donde hay varios miembros presentes dentro del grupo y si alguno de los miembros envía un mensaje, esa notificación de mensaje debe ser recibida por todos los miembros del grupo y debe hacerse de forma instantánea. Hay un retraso de cualquier tipo que no se puede permitir y el mismo caso con la industria del juego. Entonces, por ejemplo, tiene juegos multijugador en línea en los que se debe pensar mucho porque hay muchos jugadores jugando al final de la misma sesión juntos y los detalles del juego deben sincronizarse con todos ellos. .
El tercer caso de uso es, por ejemplo, el sistema de reservas de aerolíneas. Por lo tanto, si se reservó un boleto o un asiento específico, todas las demás personas o todos los demás usuarios que actualmente están viendo esos datos específicos deben ser notificados, que este boleto específico o este asiento específico ya está reservado y no se puede reservar más.
Ejemplos similares de acciones porque si cambian constantemente, los valores suben y bajan. Por lo tanto, deben actualizarse en el extremo del cliente con bastante rapidez y es un requisito realmente bueno.
Otro es el contenido de una segunda pantalla, que pueden ser anuncios o cualquier otro tipo de notificación que deba mostrarse y, finalmente, está Internet de los dispositivos, Internet de las cosas. Entonces, básicamente, estos dispositivos recopilan constantemente algunos datos, los analizan, envían algunas notificaciones. Por lo tanto, todas estas cosas necesitan un cierto tipo de confiabilidad, así como también existe la urgencia de que se reciban en los receptores. Entonces, todos estos casos de uso son escenarios bastante buenos en los que se puede usar SignalR y, en general, si se habla de hoy, en realidad se está usando en este momento.
Entonces, si pudiera pasar a la siguiente diapositiva. Chicos, si tienen alguna pregunta, siempre pueden intervenir y Nick me avisará si hay alguna pregunta y estaré encantado de responderles.
Escalamiento horizontal de aplicaciones SignalR
Entonces, hablemos de escalar las aplicaciones SignalR. Entonces, si miras este ejemplo aquí mismo.
Este ejemplo básicamente muestra que tiene una granja web y también podría ser un jardín web, pero le estoy dando el ejemplo con la granja web. Entonces, tiene una granja web aquí, donde tiene una cantidad de servidores web aquí, tiene un equilibrio de carga en el medio que se refiere a todas las solicitudes, que llegan a todos los servidores web que están presentes dentro de su granja web y luego usted tiene todos estos diferentes clientes. Estos clientes estarían conectados a cualquiera de los servidores web dentro de la granja web.
Entonces, si toma este ejemplo aquí, el cliente A está conectado a este servidor web y el cliente B está conectado a este servidor web y el cliente C está conectado a este servidor web. Entonces, el problema aquí es que, por ejemplo, si este servidor web necesita enviar un mensaje, debe enviar cualquier tipo de mensaje o notificación. Solo podrá enviar esa notificación a sus clientes conectados específicos y, en este caso, si este cliente A está enviando un mensaje, solo lo recibirán los clientes conectados a este servidor web y en este caso es solo uno.
Entonces, ¿qué pasa si hay un grupo de chat entre al menos tres clientes y están conectados a tres servidores web diferentes? Entonces, si uno de los clientes envía un mensaje, los otros clientes ahora podrían recibir este mensaje en este escenario específico porque solo los clientes conectados a un servidor web específico podrían recibir esa notificación. Entonces, en este caso, está limitado a que solo los clientes conectados al servidor web puedan recibir esta notificación y, para deshacerse de esto, SignalR introdujo un término con el nombre SignalR Backplane.
SignalR Backplane
Déjame explicarte qué es esto exactamente. Entonces, si toma el mismo ejemplo pero un poco diferente de un escenario diferente, tiene una granja web aquí y tiene un balanceador de carga en el medio, supongamos que todas las solicitudes del cliente ingresan a través de ese balanceador de carga y llegando a su respectivo servicio web.
Entonces, en este caso aquí, hay un bus compartido, hay un repositorio compartido que está conectado a todos los servidores web presentes dentro del formulario aquí. Entonces, si tiene, supongamos que tiene diez servidores web y todos ellos estarían realmente conectados a este backplane aquí y este es el lugar común que se usará para enviar o, básicamente, transmitir los mensajes o cualquier notificación. a todos los servidores web conectados.
Entonces, en este caso, si este servidor web está generando una notificación o un mensaje, no se enviará directamente a los clientes conectados. En realidad, primero lo enviaría al Backplane y una vez que el Backplane reciba esta notificación o mensaje, lo enviará a todos los servidores web conectados y luego los servidores web los enviarán a sus clientes conectados y en este De esta manera, asegura que el mensaje o notificación no se limite solo a los clientes conectados de ese servidor web específico. Es recibido por todos los clientes conectados a esa web farm específica por ejemplo derecha. Entonces, tomemos esto paso a paso.
Entonces, por ejemplo, hubo una notificación que este servidor web tuvo que enviar. Entonces, lo primero que va a hacer es notificar al Backplane aquí y lo que hará el Backplane aquí, transmitirá esto a todos los servidores web conectados aquí. Entonces, el primer mensaje lo recibe el Backplane y luego el Backplane lo envió al servidor uno y luego al servidor dos aquí y luego estos dos en estos servidores web específicos, enviaron ese mensaje a todos los clientes conectados en su escenario.
Entonces, en este caso, a diferencia del escenario que estaba aquí, si por ejemplo, hay un chat grupal como mencioné anteriormente, todos estos clientes no obtendrían una experiencia consistente o una vista, pero en este caso aquí, si hay un grupo chat en curso, todos los clientes tendrían una vista coherente, se les notificaría instantáneamente sobre cualquier actualización o cualquier mensaje nuevo que ingrese. Entonces, ese es un beneficio principal de introducir un Backplane en el escenario, pero ahora, vamos para ver cuales son las limitaciones que se han visto con un escenario Backplane y cuales son las posibles opciones que podemos tener?
cuellos de botella con SignalR Backplane
Bueno. Entonces, estaba mencionando cuellos de botella con SignalR Backplane. Entonces, estos son los principales cuellos de botella que se ven dentro de la SignalR Backplane y estas son también, las oportunidades en las que cualquier posible candidato puede ser marcado para ser utilizado como SignalR Backplane en el escenario SignalR.
Latencia y rendimiento
Entonces, el primero es la latencia y el rendimiento. SignalR Backplane necesita tener una latencia muy baja y un alto rendimiento y déjame explicarte, ¿qué significa baja latencia? Latencia básicamente, significa el tiempo que SignalR Backplane o Backplane tarda en procesar un mensaje una vez que lo recibe, el tiempo que tarda en procesar ese mensaje y luego transmitirlo o enviarlo a todos los servicios web conectados en este escenario, eso es latencia.
Por lo tanto, debe ser mínimo básicamente, lo que esto significa es que tan pronto como recibe un mensaje, debe enviarlo rápidamente a todos los servidores web conectados en la granja web. Por ejemplo, y luego el rendimiento es el número total de mensajes, que puede hacer en un cierto período de tiempo y puede ser un segundo, diez segundos o incluso cien segundos dependiendo de la escala de medición que esté presente aquí.
Por lo general, en las aplicaciones de un entorno de implementación local, tiene estas bases de datos como en su plano posterior, pero hay pocas limitaciones con la base de datos. Las bases de datos son generalmente lentas, no pueden escalar horizontalmente y, por lo general, están obstruidas por una alta carga de transacciones. Entonces, son lentos y luego no pueden escalar horizontalmente porque es un servidor único y luego hay una copia de seguridad, por ejemplo, si ese es un escenario pero es un servidor único y hay un cierto límite en el que solo puede procesar el número de solicitudes que lleguen después, comenzará a verse abrumado por estas notificaciones por transacciones y, de hecho, comenzará a afectar su aplicación. Por lo tanto, básicamente puede escalar la cantidad de servidores web dentro de su entorno para manejar el aumento de la carga entrante en su formulario web, pero cuando esas aplicaciones tienen que ponerse en contacto con una base de datos. Por ejemplo, en el banco, ahí es donde está el cuello de botella y ahí es donde usted está, todas sus aplicaciones reciben un golpe en la parte de rendimiento.
Entrega garantizada de mensajes
Lo siguiente es la entrega garantizada de sus mensajes. SignalR Backplane debe ser fiable, debe garantizar una entrega garantizada de los mensajes. No debería haber un escenario en el que un mensaje no se entregó todo lo que se perdió o debido a cualquier escenario nunca se recibió correctamente. Por lo tanto, debe tener una garantía de entrega de mensajes.
Otro son las bases de datos, como mencioné anteriormente, la base de datos puede colapsar bajo una carga extrema y también es un punto único de falla. Entonces, si ese servidor específico falla en todo su entorno básicamente, ese no debería ser el escenario, debería haber algún tipo de respaldo eficiente que pueda, en un escenario de emergencia, cualquiera que sea el escenario, debería poder recuperarse muy rápidamente de ese escenario específico.
Alta disponibilidad de backplane
El tercero es que necesita tener alta disponibilidad. Por lo tanto, SignalR debe estar altamente disponible debido a cualquier escenario, si hay algún tipo de problema, todo el sistema ahora debería fallar. Debería haber algún tipo de respaldo que pueda ayudar a continuar las operaciones, no debería verse afectado muy rápidamente si hay una situación. Debería haber algún tipo de copia de seguridad que debería poder mantener todo o mantener el entorno en funcionamiento hasta que todo se pueda restaurar a la normalidad y esto puede ser en escenarios planificados, donde hay algún tipo de mantenimiento planificado o escenario no planificado donde cualquier cosa podría ir mal.
Entonces, si miramos este diagrama aquí mismo.
Podemos ver el cuello de botella de escalabilidad con una base de datos y eso es exactamente lo que les estaba explicando ahora mismo aquí, tienen a todos sus clientes que están conectados y sus solicitudes se redirigen a través del balanceador de carga y esta es su agricultura web. . Como mencioné anteriormente, puede escalar esta granja web, puede aumentar la cantidad de servidores web y eso, a su vez, aumentaría la cantidad total de solicitudes, que su entorno básicamente puede tomar en un solo momento, pero el problema real depende, cuando estos servidores web tienen que ponerse en contacto con el back-end con la base de datos en la parte posterior y podría ser para cualquier escenario, pero no solo para SignalR o podría ser cualquier otro escenario también.
Caché distribuida en memoria como SignalR Backplane
Entonces, voy a presentar la solución. La solución a esto es un caché distribuido en memoria como un SignalR Backplane y voy a, como se mencionó anteriormente, voy a ser útil NCache como un producto de muestra para eso y NCache es un producto de código abierto. Tenemos diferentes versiones y puedes valorarlas si lo necesitas.
Clúster de servidores de caché
Entonces, déjame explicarte qué es un caché distribuido en memoria. Entonces, básicamente, el caché distribuido en memoria es un grupo de servidores de caché económicos. Entonces, tiene diferentes servidores de caché que alojan el mismo caché, lógicamente es una sola unidad, pero debajo hay varios servidores que alojan este caché y, una vez que están juntos, necesitan una cantidad múltiple de servidores. No solo están reuniendo los recursos de potencia computacional totales, sino que también están tomando los recursos de memoria. Entonces, como tenía una cantidad de servidores, básicamente escalaba la cantidad de transacciones que se pueden realizar en un tiempo específico establecido y también la cantidad total de datos que se pueden almacenar.
En este momento, estoy explicando generalmente en términos de ¿Qué es un caché distribuido en memoria? No me refiero a SignalR, pero asignaré todas estas características a los cuellos de botella que se discutieron inicialmente. Entonces, inicialmente solo estoy explicando y esto podría ser un caché distribuido que podría usarse para un escenario de almacenamiento en caché de objetos o un escenario de almacenamiento en caché de sesión, es para todos esos en este momento, pero también mapearé estas características allí.
Caché sincronizado entre servidores
Entonces, aquí una cantidad múltiple de múltiples servidores agrupan la agrupación en sus recursos de memoria y también los recursos de potencia computacional juntos y lo siguiente es una sincronización de caché en todo el servicio. Entonces, con referencia a NCache lo que hace es incluso si, por ejemplo, tiene cuatro servidores de caché que alojan el mismo caché y hay algunos datos nuevos que se agregan al caché. Hay un mapa de distribución que se actualiza tan pronto como los datos se agregan o actualizan o incluso se eliminan, se actualizan.
Por lo tanto, en cualquier momento, incluso si uno de los servidores, uno de los servidores de caché, obtiene un nuevo elemento agregado, todos los demás servidores dentro del clúster recibirán una notificación automática e instantánea de que ahora hay un nuevo elemento agregado al caché. . Por lo tanto, garantiza que todo el entorno permanezca sincronizado entre sí y que haya diferentes topologías en las que los datos se mantengan dentro de la memoria caché y eso es una discusión aparte, pero hablando en general tan pronto como se agrega el elemento, todos los servidores en el clúster obtienen notificado sobre un nuevo elemento que se está agregando. Entonces, de esa manera asegura que sea inmediatamente visible para todos los servidores presentes dentro del mismo disfraz.
Escalabilidad lineal
El tercero es escalable linealmente, como le mencioné anteriormente, se trata de una cantidad múltiple de servidores que se juntan y no hay límite. Puede agregar tantos servidores aquí como sea necesario y el caché se ajustará automáticamente. Básicamente, aumenta la solicitud total que puede manejar, también aumenta la cantidad total de datos de miembros que se pueden agregar al mismo caché. Entonces, todo es linealmente escalable. Entonces, a medida que escala su nivel de aplicación, también puede escalar su nivel de almacenamiento en caché y ese fue uno de los cuellos de botella con las bases de datos. Nunca puede escalar su entorno de base de datos, pero con esto definitivamente puede escalar su servidor de caché, todo su caché y, de esa manera, también puede aumentar el rendimiento de sus aplicaciones.
Replicación de datos para confiabilidad
El cuarto es la replicación de datos para la confiabilidad. Entonces, como les mencioné anteriormente, estos son múltiples servidores que se juntan. Por lo tanto, dependiendo de la topología, se mantienen replicaciones en otros servidores. Entonces, incluso si uno de los servidores falla, los datos de ese servidor perdido se replican en cualquiera de los otros servidores y eso iniciaría automáticamente el proceso de recuperación, luego recuperaría esos datos y los volvería a colocar en las particiones activas de la caché. Si estamos hablando de partición de réplicas, por ejemplo, como una topología de NCache. Entonces, automáticamente traería esos datos y los agregaría al mismo caché. Por lo tanto, los datos no se pierden incluso si uno de los servidores se ha ido y si hay algún cliente conectado a ese servidor, que se perdió, lo detectarían automáticamente y conmutarían por error su conexión al servicio restante presente dentro del clúster y esto es una de las otras cosas clave, que no es un único punto de falla. Por lo tanto, si tiene una cantidad múltiple de servidores, siempre que tenga un servidor de caché restante en el clúster, su caché será funcional, responderá a las solicitudes que ingresen, incluso si uno de los servidores se cae, todo el caché no baja. Su entorno no se cae y sus aplicaciones siguen funcionando bien. Entonces, ahora voy a mapear todas estas cosas que acabo de discutir o los cuellos de botella que se discutieron anteriormente durante un SignalR Backplane.
Entonces, si vas aquí y el primero fue la latencia y el rendimiento. Entonces, la latencia, como mencioné anteriormente, es la cantidad de tiempo de procesamiento. Entonces, si tiene muchos servidores que generan muchos mensajes, esas solicitudes llegan directamente al Backplane y el Backplane en este caso es Ncache. Entonces, si siente que su entorno se está ahogando, puede agregar una cantidad de servidores y eso aumentaría la capacidad total de manejar esa cantidad de solicitudes.
¿Puedo tener una pregunta aquí? ¿Qué tan complejo es configurar NCache as SignalR Backplane? Es bastante fácil y tenemos una explicación muy detallada y explicada de un documento, que lo ayuda a trabajar en él y voy a revisar exactamente eso y la parte de demostración práctica y me referiré a esta pregunta allí.
Entonces, volviendo a los cuellos de botella que generalmente se observan con el SignalR Backplane y mapeo NCache en una función de caché de discapacidad general en él. Entonces, como mencioné anteriormente, su latencia es realmente baja ya que tiene una cantidad múltiple de servidores, que en realidad pueden manejar las solicitudes que ingresan. Entonces, eso automáticamente disminuiría la latencia y obviamente también aumentaría el rendimiento a medida que tiene una latencia baja, el rendimiento se redujo automáticamente y, en general, su rendimiento general se reduciría.
El segundo es la entrega garantizada de mensajes. Entonces, dentro del NCache algoritmo y la lógica del cliente al servidor, se mantienen muchos controles. Entonces, si, por ejemplo, el cliente intenta conectarse a la memoria caché en clúster y si, por alguna razón, no puede entregar ese mensaje, se implementan reintentos internos. Entonces, el cliente NCache el cliente intenta automáticamente volver a conectarse al servidor de caché y todo esto es configurable, ya que puede configurar la cantidad de reintentos, puede configurar, ¿cuánto tiempo debe reintentar todo eso? Entonces, básicamente, puede asegurarse de que su cliente pueda conectarse a su clúster de caché específico en este caso e incluso mientras ya se mantiene una conexión y se descubre que está rota. Nuevamente, en ese escenario específico, garantizaría que el mensaje realmente se entregue.
El tercero es la alta disponibilidad del plano posterior y esta es una de las cosas clave, mencioné inicialmente, tiene varios servidores que alojan el caché. Entonces, si uno de los servidores se cae, no significa que todo el caché se cae. Sus otros servidores van a poder manejar la carga que está entrando. Van a hacer que las conexiones de los clientes pasen por error a los servidores restantes presentes dentro del clúster. Por lo tanto, de esta manera garantiza una alta disponibilidad, garantiza que los mensajes realmente se entreguen y, por último, garantiza que el rendimiento aumente considerablemente a medida que agrega números, a medida que escala el nivel de su aplicación. También puede escalar horizontalmente en el nivel de almacenamiento en caché.
Kal otra pregunta, ¿cuánta mejora de rendimiento puede obtener cada uso? NCache as SignalR Backplane, en comparación con las bases de datos o hay puntos de referencia? De acuerdo, específicamente para SignalR, es posible que tenga que buscar estos puntos de referencia, pero en general, en términos de puntos de referencia, en términos de la cantidad de transacciones que se realizan, definitivamente puedo mostrarlas más adelante, había una captura de pantalla. Entonces, puedo mostrar eso.
Justo ahí. Por lo tanto, estos son los números de escalabilidad y también son específicos de las topologías, pero generalmente son una sola vez. Entonces, como tenía una cantidad de servidores, en realidad aumenta la cantidad total de transacciones que se pueden realizar y las transacciones se dividen en lecturas y escrituras por segundo. Por lo tanto, definitivamente se pueden comparar con bases de datos porque no es escalable. Por lo tanto, se convertiría en un momento en que el caché realmente aparecería en comparación con la base de datos.
Bueno. Entonces, viniendo aquí. Este es un despliegue típico de Ncache.
Por lo tanto, recomendamos tener un nivel de almacenamiento en caché separado, como puede ver en esto, pero también puede tener el caché en los mismos servidores que su aplicación. Entonces, eso también es compatible, pero recomendamos tener un nivel de almacenamiento en caché separado y voy a dar una referencia hablando en referencia a eso. Entonces, este es su nivel de aplicación, donde tiene todos sus servidores de aplicaciones y este es su nivel de almacenamiento en caché . Nuevamente, es linealmente escalable, puede agregar tantos servidores aquí como sea necesario y luego todos estos servidores, como mencioné anteriormente, no requieren ningún hardware específico. No requieren alta tecnología o son servidores económicos y con NCache el único pre-rec de NCache es .NET 4.0, de lo contrario NCache es compatible con todos los entornos de Windows. Los sistemas operativos recomendados son Windows Server 2008, 12 y 16, donde cualquiera que tenga .NET 4.0, definitivamente puede trabajar con eso con NCache.
Hay dos tipos diferentes de tipos de instalación. Ahí está el NCache instalación del servidor de caché, que en realidad puede alojar un caché y luego hay un remote client instalación. Remote client pueden tener un caché local o básicamente independiente y pueden, tienen las bibliotecas y los recursos para que los clientes puedan conectarse a los cachés de clúster remotos y, como mencioné anteriormente, los cachés en clúster son los que están alojados en la instalación del servidor de caché . Entonces, esta es una implementación típica, todas sus aplicaciones están conectadas a la base de datos en el nivel de almacenamiento en caché y el nivel de caché también está conectado con la base de datos en la parte posterior. Tenemos funciones, que también son compatibles y se pueden usar. Asi que, NCache no solo se puede usar, por ejemplo, como backplane para SignalR, sino que también se puede usar para el almacenamiento en caché de datos, el almacenamiento en caché de sesiones y tenemos otros seminarios web y documentación, que lo ayudan a configurarlos si tiene interés en eso.
Bueno. Entonces, ahora este diagrama básicamente muestra NCache, se despliega como un SignalR Backplane.
Entonces, es bastante similar al mismo, que estábamos mirando inicialmente. Entonces, esta es su granja de servidores web aquí y tiene, supongamos, un balanceador de carga aquí. Entonces, todas las solicitudes de los clientes se están desviando, así que en lugar de un plano posterior de avión aquí, NCache se usa como backplane aquí y tiene una cantidad de servidores aquí, que son linealmente escalables, como mencioné anteriormente en este caso. Tenemos tres servidores web, tres servidores de caché aquí. Entonces, en este caso, este servidor web de aquí, generó una notificación o un mensaje y envió esta notificación al Backplane y, en este caso, el Backplane fue NCache. ¿Qué NCache ¿haría? A su vez, publicaría esto básicamente, transmitiría esta notificación a todos los suscriptores de este mismo mensaje aquí mismo. Entonces, una vez que este mensaje fue recibido por NCache, luego se transmitió a todos los servidores web conectados. En este caso y posteriormente se envió a todos los clientes conectados. Entonces, de esta manera se aseguró de que todos los clientes conectados tuvieran ese visor constante y experimentado mientras trabajaban en su aplicación y NCache fue enchufado como Backplane en este caso. Y estos son los números, de los que ya he hablado. Entonces, como básicamente tenía una cantidad de servidores, puede ver que hay una mejora lineal en la cantidad de lecturas y la cantidad de escrituras que se están realizando en este momento. Por lo tanto, es linealmente escalable, no se detiene, por lo que puede agregar tantos servidores aquí como sea necesario dentro de su entorno.
Demostración práctica
Entonces, voy a ir a la parte de demostración práctica real y aquí es donde demostraré cómo crear un caché. Lo hojearé rápidamente porque eso no es parte de la agenda, pero tenemos otros seminarios web en los que cubrimos todos y cada uno de los detalles y hablamos sobre las mejores prácticas y otras recomendaciones generales, cuando esté crear caché o configurar y configurar diferentes ajustes relacionados con el proceso de creación de caché.
Instalar NCache y crear una caché en clúster
Entonces, lo primero que debe hacer es instalar, completarlo y descargar una copia de NCache desde nuestro sitio web y luego debe instalarlo dentro de su entorno. Tengo dos máquinas, que tienen NCache ya está instalado en ellos y lo usaré. Entonces, solo voy a iniciar sesión en esos. Tengo estos registrados en demo1 y demo2 aquí. Entonces, con NCache viene una herramienta NCache administrador a través del cual básicamente puede crear y configurar y trabajar y administrar cachés básicamente, así que aquí es cuando abre el NCache gerente. Esta es la vista que obtiene, si hace clic con el botón derecho en los cachés agrupados y hace clic en crear un nuevo caché agrupado, esta es la vista que obtiene.
Por lo tanto, todos los cachés deben tener un nombre. Voy a seguir adelante y darle un nombre SignalRCache. Todos los cachés deben nombrarse como mencioné anteriormente, pero esto no distingue entre mayúsculas y minúsculas, puede usarlo de cualquier manera. Haga clic en Siguiente. Estos son los cuatro topologías y tenemos esto cubierto en otros seminarios web.
Esta es una estrategia de aplicación, voy a mantener todo predeterminado y solo voy a configurar los dos servidores de caché que les acabo de mostrar, demo1 y demo2 aquí, solo voy a hacer clic en siguiente. Este es el puerto en el que se comunica el clúster. Asi que, NCache utiliza puertos TCP/IP para mantener sus conexiones. Entonces, solo estoy buscando a Nestor, este es el tamaño del caché. si estás usando NCache para SignalR y como BackPlane para SignalR, realmente no importa el tamaño porque es solo una cola, eso se mantendrá dentro del caché y tan pronto como ese mensaje se envíe a los clientes conectados se eliminará. Entonces, además de un solo elemento, no hay nada más que se almacenará dentro del caché y el elemento único, hablaré de eso más adelante cuando vea la muestra real que viene con él.
Entonces, voy a mantener todo predeterminado aquí, voy a desactivar los desalojos porque no quiero que se elimine nada, incluso en el caso de que el caché se llene. Voy a marcar esta casilla que iniciará el caché cuando haga clic en Finalizar, solo voy a hacer clic en Finalizar. Entonces, así de fácil es crear un caché dentro de su entorno usando NCache. Entonces, esperaré a que se inicie el caché y luego agregaré un remote client a él, que va a ser mi máquina personal aquí. Bien, el caché se inició y podemos ver aquí, esta actividad cero en este punto, pero eso se debe a que no tenemos otra aplicación, ninguna aplicación básicamente está conectada a este caché en este momento.
Entonces, voy a continuar y agregar mi máquina como un nodo de cliente para agregar un cliente o simplemente hacer clic derecho aquí y hacer clic en agregar nodo. Voy a darle la IP de mi máquina personal, puede ser un nombre de máquina o una IP, ambas son compatibles. Simplemente haga clic en terminar aquí.
Podemos ver que mi máquina se agrega como remote client aquí mismo. Entonces, voy a probar rápidamente este caché para ver si todo funciona, en realidad está bien antes de eso, déjame mostrarte el herramienta de seguimiento de NCache. Entonces, si estás usando NCache como Backplane, puede usar la herramienta de monitoreo, que es una excelente herramienta, que le brinda bastante detalle de lo que está sucediendo exactamente en el caché, lo ayuda a depurar problemas y, de hecho, obtiene muchos detalles, cómo el rendimiento está sucediendo y cómo, desde dónde y dónde se reciben los resultados reales y qué se puede mejorar en general. Entonces, si solo hago clic con el botón derecho en el nombre del caché aquí, puedo hacer clic en el grupo de monitores. Esto abre NCache monitorear, que se puede usar para monitorear el caché. Entonces, le muestra un montón de cosas diferentes aquí, si simplemente abre el tablero del servidor aquí, me da una muy buena vista de lo que está pasando exactamente en el caché, gráfico diferente, este es el gráfico de la CPU, este es la red total que se está utilizando, este es el tamaño de caché, este es el total de solicitudes que ingresan. Por lo tanto, le muestra un poco de cosas diferentes que se pueden usar y observar cuando tiene un entorno de trabajo correcto. aquí y lo que voy a hacer es, desde mi caja personal aquí mismo. Voy a ejecutar una aplicación de la herramienta StressTest para simular una carga ficticia en el caché. Esta herramienta viene instalada con NCache. Así que solo voy a buscarlo. Solo voy a escribir STR, aparecerá la herramienta StressTest.
Entonces, Kal, mientras obtienes datos, puedes responder qué tipo de mainframe NCache usos para SignalR? Bueno. Así que básicamente NCache está usando el Modelo de publicación/suscripción. Entonces, todos estos clientes que son básicamente servidores web, están conectados como editores y suscriptores. Entonces, cualquiera de los clientes puede publicar un mensaje y todos los clientes conectados también son suscriptores. Entonces, ellos también serán notificados al respecto. Por lo tanto, es básicamente un modelo de Pub/Sub, tenemos una API implementada completamente separada, así como todo el marco de Pub/Sub, pero debajo de SignalR Pub/Sub se está utilizando, también puede usarlo por separado.
Agregar datos de muestra y caché de monitor
Bueno. Entonces, solo voy a abrir la herramienta StressTest. Entonces, esta es la ubicación, donde está en realidad, es un C:\archivos de programa\NCache\bin\herramientas Entonces, solo buscamos una herramienta StressTest aquí, solo vamos a abrir la instancia desde el símbolo del sistema, la vamos a arrastrar y soltar aquí. De acuerdo, en realidad, presioné enter demasiado rápido solo para borrar la pantalla. Bien, lo que voy a hacer es escribir bien, esta es la herramienta StressTest. Voy a dar un espacio para dar el nombre del caché, el nombre del caché era signalrcache. Solo voy a presionar enter ahora. Entonces, si vuelvo a esta vista aquí y abro las estadísticas, deberíamos ver las solicitudes entrantes y hacer esto ahora mismo. De acuerdo, vea algunas solicitudes que ingresan ahora y aquí mismo, puede ver que hay un montón de solicitudes diferentes que ingresan a ambos servidores de caché conectados en este momento. Entonces, parece que todo está funcionando bien y también está tomando una solicitud. Si abre la herramienta de monitoreo aquí, puede ver que este cliente se conectó aquí, un cliente se conectó aquí y si miramos aquí, vemos que hay un gran salto en la cantidad total de solicitudes que ingresan. También puede ver que el gráfico de memoria también está recibiendo un pequeño golpe.
Entonces, si verificamos que realmente está funcionando. Entonces, voy a detener esta herramienta ahora, va a volver a la NCache gerente. Voy a hacer clic derecho aquí. Voy a limpiar el contenido de esto.
Ejecutar muestra de chat de SignalR
Entonces, ahora que tenemos un caché configurado y funciona bien, lo hemos probado, parece estar funcionando bien. Entonces, lo que voy a hacer es abrir un proyecto de muestra que viene instalado en el NCache y voy a seguir la documentación, que está publicada en nuestro sitio web, paso a paso sobre cómo puede configurarlo básicamente. Puede configurarlo, su propia aplicación ASP.NET para usar NCache como un plano posterior. Entonces, si vuelvo directamente al directorio de instalación de NCache eso esta en c:\archivos de programa\ncache aquí, puedo ir a la carpeta de muestras y luego a dotnet y aquí, si solo buscamos aquí, podemos ver que hay una muestra de SignalRChat dada aquí. Entonces, esto viene instalado con NCache y este es el mismo que voy a usar en mi demostración. Ya lo tengo abierto aquí mismo. Entonces, voy a abrir la documentación y esta es la documentación que le brinda una vista paso a paso de cómo puede configurarlo dentro de su propio entorno específico.
Entonces, si solo vamos aquí. Entonces, lo primero que debe hacer es instalar el Paquete NuGet y déjeme mostrarle exactamente de qué paquete NuGet estamos hablando. Entonces, si hacemos clic derecho aquí y hacemos clic en administrar paquetes NuGet para la solución. Bien aquí, si vamos al navegador y estamos navegando en nuget.org. solo voy a buscar NCache, está bien y justo aquí, si baja un poco, creo que me lo pasé por alto, pero es la comunidad SignalR, está bien, no hay tiempo para que pueda encontrarlo, el nombre del paquete NuGet es Alachisoft.NCache.SeñalR. Entonces, debería subir aquí, Alachisoft.NCache.SeñalR. Por lo tanto, esto debe instalarse dentro de su aplicación. No necesito instalarlo en este momento porque tengo una instalación de NCache y ya tiene referencias que requerirán bibliotecas, pero si no está utilizando el NCache instalación, definitivamente puede agregar esto como un paquete NuGet. Solo necesita instalarlo dentro de su proyecto de producto de aplicaciones.
El siguiente paso aquí es incluir estos dos espacios de nombres Alachisoft.NCache.SeñalR y luego Microsoft Microsoft.AspNet.SignalR. Por lo tanto, estos deben introducirse en Startup.cs, solo seguiré el proyecto de muestra, pero debe hacerlo en referencia a su propia configuración específica. Entonces, si ingresa a Startup.cs aquí, va a la derecha en la parte superior, podemos ver que estos dos ya son referencia aquí Alachisoft.NCache.SeñalR y Microsoft.AspNet.SignalR. Entonces, ya está agregado aquí.
Vamos a ver el siguiente paso. Entonces, ahora necesitamos modificar web.config. Entonces, necesitamos agregar estas dos claves específicas aquí y déjame explicarte cuáles son. El primero, que tiene el nombre de caché, es el nombre real de la caché. Entonces, debe darle el caché que va a usar, que estará encendido y funcionando y necesita usar esto.
La segunda es la clave par y esto es lo que diferencia entre múltiples. Entonces, si tiene el mismo caché que se usa como medio como backplane para múltiples aplicaciones diferentes. Correcto, entonces, esto es lo que lo diferencia. Entonces, básicamente abre un canal dentro del caché a través del cual todas las aplicaciones, que tienen el mismo valor, podrían recibir notificaciones. Por lo tanto, si hay dos aplicaciones que necesitan comunicarse entre sí, deben tener este valor para que sean iguales, pero si hay una aplicación diferente, puede cambiar esto de acuerdo con su entorno específico. Entonces, en este momento, se dice Chatear aquí y si volvemos al proyecto de muestra aquí y entramos en web.config, podemos ver que está configurado aquí.
El nombre del caché es diferente y lo que voy a hacer es cambiarlo al caché que hemos creado y ese es signalrcache. Como mencioné anteriormente, este es el nombre del caché que no distingue entre mayúsculas y minúsculas, por lo que puede elegir solo esto. Entonces, voy a seguir adelante y guardar esto. Volvamos aquí, estas cosas son básicamente, estas son las sobrecargas que se pueden usar, voy a mostrar lo que estoy usando en mi entorno. Inicialmente, solo se está registrando en variables de cadena, que tomarán los valores que hemos almacenado inicialmente en web.config. Ese es el nombre de caché, así como el canal, por ejemplo, nombre y luego aquí es donde especificas que NCache debe ser utilizable. Básicamente, son solo dos o tres líneas de código que deben introducirse en su aplicación. Deberías estar listo para ir a usar NCache como Backplane dentro de su aplicación.
Inicialmente había una pregunta que se refería a lo difícil que es configurar NCache como backplane para su aplicación específica y es bastante fácil. Por lo tanto, solo hay que introducir tres líneas de código y debería tener NCache para ser un Backplane para su entorno específico y si vuelvo a mi proyecto aquí, voy a startup.cs. Tenemos el mismo código específico. Solo hay algunos controles presentes aquí, solo para garantizar que los valores que realmente están en su lugar y luego aquí. Tenemos esta llamada aquí mismo, que presenta NCache para ser utilizado como backplane para esto. Entonces, lo que voy a hacer ahora es ejecutar esta aplicación y abrir un par de instancias de ella. Entonces, puedo mostrarte cómo está funcionando esta sala de chat en este momento. Entonces, solo voy a hacer clic en ejecutar aquí y debería abrirlo. Bueno. Entonces, la compilación está lista, debería abrirse ahora. Está bien, solo esperando la carga, no toma tanto tiempo, pero es ahora mismo.
Bien, mientras tanto, permítanme repasar rápidamente las diapositivas que estamos usando. Entonces, si solo hago clic en Default.html aquí mismo, debería aparecer una ventana emergente aquí, que me pregunta el nombre que voy a usar. Entonces, dado que se trata de una sala de chat, debe registrarse con el nombre. Entonces, cuando envía un mensaje, los otros destinatarios deben saber exactamente de quién proviene este mensaje. Entonces, aquí mismo, me está pidiendo mi nombre. Voy a seguir adelante y dar el nombre de Kal. Voy a escribir hola y tratar de enviarlo, mientras tanto, solo voy a abrir otra instancia aquí mismo, debería abrirse. Todavía no lo ha enviado, pero verifiquemos que el nombre del caché sea correcto, regrese a web.config. Creo que me equivoqué de nombre. Por lo tanto, es Signalrcache. Puede que tenga que ejecutarlo de nuevo. Voy a seguir adelante y detenerme, obviamente cerraré estas instancias ya que el nombre del caché no era correcto. Estos no funcionarían, así que necesito ejecutarlos de nuevo. Bueno. Por lo tanto, vamos a verificar una vez más SignalRCAche, es correcto ahora. Está deteniendo las instancias en este punto. Está bien, solo voy a ejecutarlo una vez más, esto debería ser más rápido porque ya está hecho.
Mientras tanto, si tiene alguna pregunta? Por favor, siéntase libre de preguntar. Bueno. Entonces, la compilación está lista y ahora, solo lo estamos abriendo bien. Entonces, Kal, tengo una pregunta aquí, ¿funciona también para SignalR core? Sí, funciona porque NCache apoya a .NET Core también. Entonces, funciona con eso, sí. Bien, otra pregunta es qué capacidades de mensajería NCache ofertas que no sean SignalR? Como mencioné inicialmente debajo de SignalR, toda la implementación como Backplane, NCache está usando el modelo Pub/Sub, pero aparte de eso, también puede usar Pub/Sub por separado. Siempre debe usarse como backplane para SignalR, pero de lo contrario, tenemos eventos y los eventos pueden ser eventos controlados por datos o también pueden ser eventos específicos definidos por el usuario con los que básicamente puede notificar a otras aplicaciones para ciertos eventos. Se agregan, actualizan o eliminan elementos más nuevos y tenemos estas funciones, entonces también tiene la función de consulta continua.
Entonces, con eso especifica ciertos resultados establecidos dentro del caché y si se realiza alguna actualización específicamente, el conjunto de resultados y podría haber varios elementos dentro del mismo caché y cualquiera de ellos se actualizará, será el cliente que solicitó porque se le notificará al respecto, por lo que estos son otros que también están presentes. Entonces, acabo de hacer clic en el predeterminado. Debería preguntarme mi nombre, ahora solo voy a esperar eso. Bueno. Entonces, le daré el nombre, Kal, y espero que funcione. Entonces, solo voy a escribir hola y enviarlo. En este momento, solo voy a copiar este enlace y pegarlo aquí. De acuerdo, proporcionando el nombre, solo voy a darle el nombre de Nick. Bien aquí, así que aquí desde aquí, envié un mensaje diciendo hola y también fue recibido aquí. Este es un saludo de Nick. Así que voy a escribir ese saludo de Nick y lo voy a enviar. Entonces, justo aquí, Nick envía este mensaje de saludo de Nick y si miras hacia atrás en la vista de Kal, también podemos ver que aparece aquí también.
Entonces, podemos enviar múltiples mensajes aquí, tantos como queramos y serán recibidos por todos los clientes conectados a este escenario específico. Entonces, podemos ver que Kal envió un montón de mensajes y también fueron recibidos en la vista de Nick. Por lo tanto, se actualizan automáticamente, si solo envía una última de Nick también desde Nick y simplemente la envía, puede ver que surgió de Nick y desde esta vista también, podemos ver bien aquí. Entonces, si miramos rápidamente el caché que creamos y que está siendo utilizado por él. Podemos ver que se agregó un elemento aquí y, como mencioné anteriormente, solo se agrega un objeto, el resto es solo una cola que se mantiene temporalmente mientras se transfiere.
Entonces, si usamos una herramienta dentro NCache que se conoce con el nombre de volcado de claves de caché, va a volcar las claves que están presentes en el caché. Entonces, solo quiero mostrarles rápidamente y le damos el nombre signalrcache y presionamos enter.
Va a extraer todos los elementos que están presentes en el caché. Entonces, en este punto, son solo uno y podemos ver que hay un elemento colocado aquí, con el nombre chat y este valor de cadena es exactamente el mismo que configuramos dentro de nuestra aplicación contra el valor de la clave de evento. Entonces, esta es la clave común que debe usarse dentro de todas sus aplicaciones, que necesitan usar este canal específico para enviar y recibir mensajes. Entonces, esto debe ser igual en todos los aspectos y esto es exactamente lo que garantizará que todos los clientes conectados o servidores web conectados a este caché específico sean notificados y con respecto a cualquier cosa que esté sucediendo. Entonces, así de fácil es tener NCache como Backplane dentro de su aplicación.
Si reviso rápidamente lo que ya hemos discutido aquí, permítanme terminar rápidamente la última pantalla y la última diapositiva de presentación aquí es que NCache debajo de ello. Utiliza el modelo Pub/Sub.
Por lo tanto, tiene aplicaciones cliente conectadas, que pueden ser aplicaciones .NET o aplicaciones Java, y están conectadas para editores y suscriptores, en ambos sentidos. Por lo tanto, cualquier aplicación que envíe a cualquier cliente conectado que envíe un mensaje adivinado, recibe a todos los clientes conectados y de esa manera garantiza que todos los mensajes sean realmente recibidos por todos los clientes conectados.
Entonces, si revisa rápidamente lo que hemos discutido en este seminario web de hoy, es que discutimos sobre SignalR como tecnología. ¿Qué es y cómo puede ayudar en diferentes escenarios? Donde es de extrema necesidad porque las aplicaciones no pueden esperar a que el cliente envíe una notificación o solo entonces pueden responder con los datos respectivos. Quieren que los clientes sean notificados automáticamente de su actualización con los datos actualizados con bastante rapidez. Entonces, discutimos qué es SignalR. ¿Cómo funciona básicamente? ¿Cuáles son los diferentes casos de uso que son posibilidades posibles y dónde actualmente también se usa SignalR?
Por lo tanto, no son solo casos de uso futuros. También son casos de uso actuales y cómo escalar las aplicaciones SignalR puede tener algún tipo de problemas con la coherencia y cómo SignalR introdujo el concepto Backplane a través del cual pueden garantizar que todos los clientes conectados obtengan una vista coherente y obtengan notificado inmediatamente de cualquier cosa que esté pasando dentro del caché. Creo que hay una pregunta.
Bueno. Entonces, permítanme discutir los cuellos de botella asociados con la SignalR Backplane. Discutimos estos tres puntos principales y estos, como mencioné anteriormente, también fueron las oportunidades que podría tomar cualquier solución y la solución de la que hablamos fue un caché distribuido en memoria. En este caso fue NCache y mapeamos las diferentes características, diferentes cosas que NCache posee sobre, que SignalR Backplane realmente necesita? NCache se asignó a ellos perfectamente y fue un excelente caso de uso, excelente candidato básicamente, ser es ser un Backplane para una aplicación SignalR y discutimos sobre NCache. Cómo NCache ¿puede ser usado? Discutimos los números de escalabilidad y también pasamos a la demostración práctica del proyecto de muestra, que viene instalado con NCache y cómo se puede usar y luego está esta documentación aquí, que ayuda en todos y cada uno de los procesos de esta configuración.
Entonces, creo que eso es todo por mi parte, Nick pasa a ti. Gracias, Kal, eso fue muy informativo, si alguien tiene preguntas, háganoslo saber o puede escribir esas preguntas en el cuadro de preguntas. Solo para recapitular NCache la solución está disponible para descargar de nuestra web www.alachisoft.com. Tenemos la edición comunitaria, la versión de código abierto, así como la Edición Profesional que puede descargar, eche un vistazo a la empresa viene con un período de prueba de 30 días, que puede usar para probar antes de continuar y, por supuesto, el código abierto es de uso gratuito. Entonces, no hay preguntas, me gustaría agradecer a todos por unirse a nosotros y agradecer a Kal por su tiempo y espero verlos en el próximo seminario web futuro.