Cinco potenciadores de rendimiento de ASP.NET
Seminario web grabado
Por Ron Hussain y Nick Zulfiqar
Descubra cómo aumentar el rendimiento y la escalabilidad de ASP.NET con una caché de .NET distribuida. Mire este seminario web para obtener información sobre las cinco formas de aumentar el rendimiento de ASP.NET para la escalabilidad en aplicaciones ASP.NET y cómo usar una caché distribuida en memoria para resolverlas de manera efectiva.
Co-entregado por nuestro Arquitecto de Soluciones Sénior y Director Regional de Ventas, únase a nosotros para obtener más información sobre:
- Almacenamiento en caché de datos de aplicaciones ASP.NET
- Caché de estado de sesión de ASP.NET
- ASP.NET SignalR Backplane utilizando caché distribuida
- ASP.NET View State Almacenamiento en caché
- Almacenamiento en caché de resultados de ASP.NET
Hoy hablaremos sobre 5 formas de aumentar el rendimiento y la escalabilidad de su aplicación ASP.NET. Es un tema muy candente, diría que es algo que tiene mucha demanda. Por lo tanto, nos complace traer esto para usted. Ron hablará sobre eso en un minuto y también, si tiene alguna pregunta durante esta presentación, siéntase libre de escribirla en el video y podré traerla a la atención de Ron.
Entonces, Ron, ¿cómo empiezas? Gracias, Nick. Hola a todos, mi nombre es Ron y seré su presentador para el seminario web de hoy y, como Nick sugirió, el tema que elegimos hoy son cinco potenciadores de rendimiento de ASP.NET. Entonces, revisaremos cinco características diferentes. Inicialmente, hablaré sobre cinco problemas diferentes, lo que normalmente vería dentro de una aplicación web ASP.NET, estos son problemas cotidianos que realmente ralentizan sus aplicaciones, su degradación del rendimiento, luego la escalabilidad es otra vía, otro aspecto en el que hablaremos sobre estos cuellos de botella y luego hablaré sobre diferentes soluciones con la ayuda del sistema de almacenamiento en caché distribuido. ¿Cómo resolver esos problemas dentro de sus aplicaciones ASP.NET? Entonces, eso es lo que hemos alineado hoy, cubriré diferentes características, tendré aplicaciones de muestra, les mostraré todo en acción, cómo configurar y comenzar con esto. Por lo tanto, será un seminario web bastante interactivo y práctico y, como mencionó Nick, si tiene alguna pregunta, no dude en participar y estaré encantado de responder todas esas preguntas por usted. Muy bien, asumiendo que todo se ve bien, voy a empezar con esto.
ASP.NET es popular para aplicaciones web de alto tráfico
Entonces, antes que nada, hablaré sobre la plataforma ASP.NET en general. ASP.NET es una plataforma muy popular para aplicaciones web. Vemos muchas implementaciones web y su popularidad está aumentando. Lo bueno de la plataforma ASP.NET es que se basa en el patrón de uso, es algo que se escala bastante bien, puede manejar miles de usuarios simultáneos y sus solicitudes asociadas sin tener que cambiar nada dentro de la arquitectura de la aplicación. Puede crear una granja web, puede crear un jardín web, le brinda muchas opciones de escalabilidad, puede colocar un equilibrador de carga al frente y luego puede enrutar solicitudes entre diferentes servidores web y puede lograr escalabilidad lineal, escalabilidad horizontal fuera de la granja web ASP.NET.
Un balanceador de carga podría tener un balanceo de carga fijo o un balanceo de carga igual que dependa de su arquitectura, dependiendo de la naturaleza con estado de sus servidores web o servidores de aplicaciones, y luego puede escalar según lo necesite.
Entonces, esta es una implementación típica de una granja web para aplicaciones ASP.NET, tiene N cantidad de clientes que pasan por el balanceador de carga para configurar servidores web dentro de una granja web y luego tiene almacenamiento de sesión ASP.NET, ese es un tipo de datos que puede ver dentro de sus aplicaciones web ASP.NET. Entonces serán servidores de bases de datos, bases de datos relacionales o NoSQL databaseEs posible que esté manejando una gran cantidad de datos de un lado a otro y luego podría ser cualquier otro sistema de archivos de mainframe del sistema de datos back-end con el que interactúen sus aplicaciones. Por lo tanto, esto es bastante popular, bastante escalable, bastante rápido y muchas implementaciones activas están usando esta plataforma.
El problema: cuellos de botella de escalabilidad
Entonces, hablemos del cuello de botella de escalabilidad dentro de ASP.NET. ¿Dónde está exactamente el problema? Es algo que escala muy bien el problema de escalabilidad y definamos rápidamente qué es la escalabilidad. La escalabilidad es una habilidad dentro de la arquitectura de la aplicación o dentro del entorno donde se implementa su aplicación. Es esa capacidad en la que puede aumentar la cantidad de solicitudes por segundo o solicitudes dadas, solicitudes simultáneas sin comprometer el rendimiento. Si tiene cierta cantidad de latencia por debajo de cinco usuarios. ¿Qué tal si mantienes esa latencia? No degrada el rendimiento y está bien no mejorar el rendimiento, pero al menos mantiene el rendimiento por debajo de 5000 usuarios o 500,000 XNUMX usuarios, esa capacidad en sí misma se llama escalabilidad, donde obtiene el máximo rendimiento del sistema, cada vez se realizan más cargas de solicitudes. manejado y luego su latencia no crece a medida que crecen las cargas de usuarios. Entonces, es esencialmente rendimiento bajo carga extrema o rendimiento extremo bajo carga extrema. Entonces, esa capacidad se llama escalabilidad.
Ahora, normalmente las aplicaciones ASP.NET, aunque la granja web es muy escalable, ahora le darían problemas de escalabilidad dentro de la granja web, pero pueden causar lentitud en cargas máximas principalmente debido a las fuentes de datos de back-end. Entonces, si su aplicación se ralentiza, se ahoga debido a una gran cantidad de carga, entonces esa aplicación es candidata para la escalabilidad, necesita tener una arquitectura escalable dentro de sí misma. Por qué la aplicación sentiría su mundo o vería situaciones como esta en las que las aplicaciones se ralentizan bajo carga máxima, podría haber diferentes cuellos de botella clasificados de almacenamiento de datos o algunos cuellos de botella dentro de la aplicación. Entonces, a partir de este punto, hablaremos sobre cinco cuellos de botella diferentes dentro de una aplicación ASP.NET que limitan su capacidad de escalabilidad, que lo limitan para escalar horizontalmente.
Dos cuellos de botella de almacenamiento de datos
Bien. Entonces, en primer lugar, tenemos dos cuellos de botella en el almacenamiento de datos.
La base de datos no puede escalar
Tenemos una base de datos de aplicaciones que normalmente no se puede escalar, tendría una base de datos relacional en forma de SQL Server, Oracle o cualquier otra fuente de datos relacional popular. Es muy bueno para el almacenamiento, pero no es muy bueno cuando se trata de manejar una gran cantidad de carga de transacciones. Tiende a ahogarse y, en algunos casos, en realidad te da errores de tiempo de espera. Entonces, o al menos ralentiza su rendimiento, no puede agregar más servidores de bases de datos sobre la marcha, por lo que será una fuente única. También es un punto único de falla en algunos casos si no tiene replicación y luego lo más importante, el problema apremiante aquí es que no es muy rápido, es lento en un escenario normal y luego en carga máxima y en realidad empeora la situación donde no es capaz de acomodar el aumento de carga y ralentiza aún más las cosas. Entonces, ese es nuestro primer cuello de botella.
Almacenamiento de estado de sesión ASP.NET
El segundo cuello de botella está relacionado con el almacenamiento del estado de la sesión de ASP.NET, ahora el estado de la sesión es un tipo de datos muy importante. Es algo que tiene información del usuario, por ejemplo, podría haber una aplicación de comercio electrónico que tenga manteniendo la información del usuario o el carrito de compras, podría ser un sistema de reserva, podría ser un sistema de emisión de boletos, podría ser su sistema financiero. Por lo tanto, podría ser cualquier tipo de sistema frontal donde los usuarios inicien sesión y tengan sus datos muy importantes dentro de este objeto de sesión.
Ahora, estos son los tres modos que ofrece la plataforma ASP.NET, tenemos InProc donde todo se almacena dentro del proceso de trabajo. Por lo tanto, todo se encuentra dentro del proceso de la aplicación, por lo que sus procesos de trabajo no son sin estado, el protocolo HTTP en sí mismo no tiene estado, pero en este caso, sus procesos de trabajo alojarían todos los datos del usuario. Luego tenemos StateServer esa segunda opción y luego tenemos SQL Server. Entonces, hable sobre estas opciones de almacenamiento de estado de sesión convencionales y hablemos sobre sus cuellos de botella.
En primer lugar, InProc es rápido porque está en la memoria, no hay deserialización de serialización pero, en primer lugar, no puede manejar un escenario de jardín web. En un servidor web, solo tendría un proceso de trabajo único para una aplicación determinada porque ahí es donde existen los datos de su sesión ahora, si la próxima solicitud va a otro proceso de trabajo, ya no tiene esos datos de sesión, tiene que ser el mismo proceso de trabajo y es por eso que lo limita, técnicamente no es posible ejecutar el jardín web con la administración de sesiones de InProc, por lo que ese es un factor limitante aquí.
En segundo lugar, necesita habilitar el bit de sesión permanente en el balanceador de carga. Entonces, en primer lugar, limitó su rendimiento o escalabilidad o sus recursos en el servidor web y al tener un solo proceso para una aplicación. En segundo lugar, sus servidores web donde se atendió la solicitud inicial, las solicitudes posteriores siempre irían a ese mismo servidor. Eso es todo, el equilibrio de carga de la sesión pegajosa funciona, hace el trabajo, pero el principal problema con esto es que podría ser que un servidor web tenga muchos usuarios activos, pero otros servidores web están inactivos porque esos usuarios ya han cerrado sesión y dado que los usuarios van a ser pegajosos por naturaleza, nunca irían a este servidor gratuito, siempre irían al mismo servidor donde tienen que ir con los datos existentes. Entonces, ese es otro problema que debe tener el equilibrio de carga de la sesión persistente con InProc y, lo que es más importante, si su proceso de trabajo se recicla y, según hemos visto, según nuestra experiencia, los procesos de trabajo de ASP.NET se reciclan bastante, perdería todo. los datos correctos, si se trata de una tarea relacionada con el mantenimiento, si el servidor debe fallar, debe desactivar un servidor web, activar otro servidor web y, como resultado, perderá todos los datos. Entonces, eso resume todos los problemas, todos los cuellos de botella que vería con la administración de sesiones de InProc con ASP.NET. Entonces, claramente no es una opción y tampoco es muy escalable, tiene un servidor que alcanza la capacidad de ese servidor y con sticky es un equilibrio de carga que realmente no ayuda.
La segunda opción es StateServer, es un poco mejor que InProc porque extrae datos de su proceso de aplicación dentro de un servicio estatal, podría ser una caja remota o uno de sus servidores web, depende completamente de usted, pero el problema con esto es que no es escalable, es una fuente única, puede escalar verticalmente en ese servidor, pero escalar horizontalmente no es una opción. Siempre será un servidor único, un servicio que alojará todos los datos de su sesión y que también administrará todas las cargas de solicitudes, si su carga de solicitudes crece, no hay opciones para agregar más recursos. Por lo tanto, no se ampliará en comparación con el tiempo, su servicio estatal puede colapsar, por ejemplo, si tiene cientos y miles de usuarios y su solicitud asociada hace que sean millones de solicitudes por segundo o por día solicitante o dentro de millones, eso es una carga bastante pesada . Entonces, en base a eso, StateServer no escalaría horizontalmente y no sería capaz de hacer frente al aumento de la carga, y entonces también es un punto único de falla. Si el propio StateServer deja de funcionar, perderá todos los datos de su sesión y los datos de la sesión son un tipo de datos muy importante que no querría perder sus sesiones mientras su usuario está a punto de comprar algo o está a punto de tomar una decisión y va a impactar. el negocio a cambio.
La tercera opción es SQL Server. SQL Server es nuevamente una administración de sesión fuera de proceso, pero nuevamente es lento, no es escalable, no puede agregar más servidores SQL y no está diseñado para manejar datos transaccionales solo, por lo que termina teniendo el mismo problema que discutimos como parte de nuestro base de datos de la aplicación, ese problema sigue siendo el mismo para el almacenamiento en caché de datos y para el almacenamiento en caché de sesiones. Por lo tanto, el estado de la sesión no se optimizará con las opciones predeterminadas que presenta la plataforma ASP.NET y esto se debe principalmente a las fuentes de datos que ofrece InProc, StateServer y SQL Server.
Espero que esto haya construido algunos detalles básicos sobre los cuellos de botella y, por supuesto, hablaremos sobre la solución, estamos hablando sobre el almacenamiento en caché distribuido y sus características en comparación y hablaremos sobre cómo solucionar estos problemas uno por uno. , así que primero quiero enumerar todos los problemas y luego hablaremos de las soluciones una por una. Este diagrama ilustra lo mismo.
Tenemos una base de datos de cuello de botella de almacenamiento de datos y luego tenemos almacenamiento de sesión ASP.NET o InProc o bases de datos como administrador de sesión y eso también representa claramente un cuello de botella, donde tenemos fuentes únicas en la mayoría de los casos, no son escalables, no son muy confiable y luego hay lento en general.
ASP.NET View State Embotellamiento
Ahora, el tercer cuello de botella importante es ASP.NET view state. Para las granjas web ASP.NET hay un estado de vista, ahora aquellos de ustedes que quieren saber qué es el estado de vista. Estoy bastante seguro de que todo el mundo lo sabe, pero el estado de vista es una gestión de estado del lado del cliente, es un paquete, es un estado de los widgets de control que tiene en sus granjas web, se construye en el extremo del servidor y se convierte en parte de su El paquete de respuesta regresa al navegador que es donde se almacena, nunca se usa realmente en el extremo del navegador y se devuelve al servidor cuando publica de nuevo en esa página como parte del paquete de solicitud dispersa. Por lo tanto, se incluye con los paquetes de solicitud y respuesta, regresa al navegador, nunca se usa realmente allí y un problema urgente con el estado de vista es que generalmente es muy pesado. Tiene un tamaño de cientos de kilobytes y piense en el escenario, donde tiene una gran cantidad de carga de transacciones, tenemos millones de transacciones y luego cada transacción tiene un paquete de paquetes de estado de visualización o un paquete de respuesta de solicitud para la aplicación web ASP.NET. ver parte del estado y si tiene cientos de kilobytes de estado de vista por solicitud y tiene millones de transacciones, consumirá una gran cantidad de ancho de banda y, en general, ralentizará las respuestas de su página porque está tratando con una gran cantidad de datos de un lado a otro y esos datos también son pesados.
Entonces, ese es otro cuello de botella que consume su ancho de banda, su causa aumenta significativamente y luego ralentiza los tiempos de respuesta de su página porque el estado de vista es pesado en general, está lidiando con una carga útil más pesada para las solicitudes en respuesta. Entonces, ese es otro tipo de cuello de botella que es parte de las granjas web ASP.NET. Si tiene una aplicación de granjas web ASP.NET, no hay forma de evitar este problema. De forma predeterminada, tendría que lidiar con una gran cantidad de estado de vista y este diagrama lo cubre donde el estado de vista vuelve al navegador, es una administración de estado del lado del cliente que se construye en el extremo del servidor y vuelve al navegador y lo trae de vuelta en el servidor en sus respaldos de publicaciones. Ahora los paquetes de solicitud y respuesta son pesados, consumen mucho ancho de banda, la carga útil pesada también ralentiza las cosas.
Cuello de botella de ejecución de página adicional
Ahora, el cuarto cuello de botella y este es el penúltimo, tenemos un cuello de botella más después de este es el cuello de botella de ejecución de página adicional. Ahora bien, esto es cierto para las granjas web ASP.NET, así como para las aplicaciones web ASP.NET MVC. Hay escenarios en los que el resultado de la página completa es el mismo o las partes dentro de una página dinámica son las mismas, por lo tanto, está tratando con contenido estático dentro de la aplicación con mucha frecuencia. Por lo tanto, la salida de la página no cambia con mucha frecuencia, pero aún está ejecutando esas solicitudes. Podría haber una solicitud e involucra algunas bases de datos de back-end que se procesan y luego obtiene algunos datos de las fuentes de datos de back-end, lee esos datos, los hace significativos, aplica alguna capa de lógica comercial diaria, capa de acceso a datos todo el cosas buenas y después de eso, genera una respuesta y la respuesta se envía de vuelta al usuario final en el navegador. Ahora, cualquiera que sea el mismo ciclo, tiene que repetirse y luego el contenido no cambia, tendrías que pasar por el mismo ciclo una y otra y otra vez. Esta página se ejecuta independientemente de si cambia o no, de forma predeterminada, se trata de una gran cantidad de contenido estático y, aunque el contenido no cambia, sigue ejecutando la misma solicitud. Ahora bien, esto aumenta el costo de su infraestructura, CPU adicional, memoria adicional, recursos de base de datos adicionales, puede alcanzar la capacidad en el servidor web, también puede afectar la capacidad en el sitio de la base de datos en general, es algo que desperdiciaría una gran cantidad de CPU y recursos costosos en ejecutar algo que ya ha sido ejecutado. Entonces, ese es otro cuello de botella y hablaremos sobre una solución con la ayuda del almacenamiento en caché de salida de la página para solucionarlo también. Entonces, esto cubre nuestro cuarto cuello de botella y el quinto y, por cierto, este diagrama involucra la ejecución de la página en la salida estática y creó más bases de datos que manejan muchas solicitudes.
ASP.NET SignalR Backplane Embotellamiento
Y el quinto cuello de botella es SignalR backplane. Ahora, este es un caso de uso muy específico que puede o no tener SignalR, pero para aquellos de ustedes que están familiarizados con SignalR y si han configurado un plano posterior, un plano posterior es un bus de mensajes común y su servidor web envía todos sus mensajes en lugar de enviar la funcionalidad de inserción en los navegadores de los clientes. Podría haber un escenario en el que se traten pocas solicitudes de clientes con otros servidores web. Entonces, solo se transmiten al backplane y el backplane a su vez transmite mensajes, mensajes SignalR a todos los servidores web y, a su vez, transmiten a todos sus clientes conectados. Entonces, con WebSockets ASP.NET SignalR backplane es una configuración bastante común, si tiene una granja web.
Ahora SignalR Backplane NCache o se puede conectar cualquier otro producto de almacenamiento en caché distribuido. También puede ser una base de datos o también podría ser un bus de mensajes, pero la idea aquí es que el backplane no debería tener problemas de rendimiento o rendimiento. Debería funcionar muy bien, debería brindarle una latencia baja, un alto rendimiento y, al mismo tiempo, debería ser muy confiable si falla y pierde todos los mensajes de SignalR que también afectarían el negocio.
Las bases de datos son lentas, no son muy escalables, tienen un rendimiento lento, Redis es una opción, no es .NET nativo, por lo que necesita algo que sea muy escalable, que sea muy rápido y también muy confiable. Entonces, ese es otro problema dentro de una aplicación ASP.NET si está usando SignalR backplane como resultado de eso. Entonces, esto completa nuestros cinco cuellos de botella, sé que es mucha información, pero principalmente su base de datos es lenta, no es muy escalable, el estado de sesión de ASP.NET no tiene opciones muy escalables, rápidas o confiables de manera predeterminada. View State para la granja web ASP.NET también es un cuello de botella, su fuente de contención, la sobreutilización del ancho de banda, las páginas estáticas dentro de la aplicación se ejecutarán independientemente de si el contenido de su aplicación está cambiando o no. Se va a ejecutar y luego tenemos SignalR Backplane que generalmente es lento y no es muy confiable, no es muy escalable y necesitas algo que sea muy escalable y muy confiable en comparación.
Entonces, esto completa nuestros cinco cuellos de botella, en las próximas diapositivas hablaré sobre la solución y luego repasaremos todos estos cuellos de botella uno por uno y presentaré diferentes soluciones. Por favor, hágamelo saber si tiene alguna pregunta y estaré encantado de responderlas ahora mismo. Tengo algunas aplicaciones de muestra de muestra alineadas aquí, así que las usaré bien. Entonces, creo que en este punto no hay preguntas. Por lo tanto, comenzaré rápidamente con la solución porque tenemos mucho que cubrir en nuestro próximo segmento.
La solución: caché distribuida en memoria
Tenemos el almacenamiento en caché distribuido en memoria como solución y usaré NCache como producto de ejemplo. NCache es el principal producto de almacenamiento en caché distribuido, caché distribuido basado en .NET, está escrito para .NET y es principalmente para aplicaciones .NET y es uno de nuestros principales productos. estaré usando NCache como un producto de ejemplo y hablaremos de cinco características diferentes dentro NCache eso se encargará de esto y verá un refuerzo de rendimiento dentro de su aplicación ASP.NET. Simplemente mejoraría drásticamente el rendimiento y la escalabilidad y estas son solo características específicas de ASP.NET, hay otras características del lado del servidor que puede ajustar, hay un seminario web separado en cómo mejorar NCache actuación, eso llevará las cosas a un nivel completamente nuevo, mejorará aún más el rendimiento, pero en este seminario web hablaré sobre cinco cuellos de botella diferentes y luego hablaré sobre cinco soluciones diferentes para esos cuellos de botella.
¿Qué es una caché distribuida en memoria?
Entonces, ¿qué es un caché distribuido en memoria y cómo es más rápido y más escalable y, en algunos casos, es más confiable en comparación? Por lo tanto, el caché distribuido es un grupo de múltiples servidores de caché económicos que se agrupan en una capacidad lógica para su memoria, CPU y sus recursos de red. Entonces, si tiene un equipo de servidores y ese equipo de servidores está unido en un clúster, es una capacidad lógica para las aplicaciones, pero es un conjunto físico de servidores o máquinas virtuales, por lo que detrás de nosotros hay múltiples recursos y usted tiene la capacidad de agregue más servidores sobre la marcha. Entonces, los servidores de caché económicos se unen, se unen y agrupan sus recursos y eso es lo que forma la base de un caché distribuido.
Luego, hemos sincronizado las actualizaciones de caché entre servidores de caché, es muy consistente en términos de datos de lo que era porque hay múltiples servidores, múltiples aplicaciones cliente se conectan a él, por lo que cualquier actualización realizada en un servidor de caché debe ser visible en otros servidores de caché web. y también a los clientes que están conectados a él y he usado el término visible, lo que significa que tiene que ser coherente. No utilicé replicación como término aquí, la replicación es otro concepto. Por lo tanto, todas las actualizaciones se aplican de forma sincronizada o coherente en todos los servidores de almacenamiento en caché, por lo que tiene la misma vista de los datos para todas sus aplicaciones cliente.
Luego, debe escalar horizontalmente tanto para transacciones como para capacidad de memoria y también para otros recursos. Si agrega más servidores, solo debería aumentar la capacidad, si tiene dos servidores y trae el tercer servidor, anteriormente manejaba 10,000 solicitudes con un tercer servidor, debería llegar a 15,000 con dos servidores más duplicando la capacidad, debería manejar 20,000 solicitudes por segundo y esa es nuestra experiencia. De hecho, aumenta la capacidad y la capacidad general de manejo de solicitudes aumenta a medida que agrega una cantidad de servidores y le mostraré algunos números de referencia para respaldar eso. Esta es la arquitectura de implementación de la caché distribuida típica.
Tiene un equipo de servidores de caché, todos los entornos de Windows son compatibles con 2008, 2012 y todas sus aplicaciones se conectan a él en un modelo cliente-servidor y utilizan esta fuente rápida, escalable y confiable además de nuestra base de datos relacional. Algún día van a dar que esto existe en la base de datos relacional, puede traer algunos o todos sus datos a la memoria caché. El estado de sesión se convierte en su tienda principal, estado de vista, caché de salida, SignalR backplane esto se convierte en su principal proveedor para eso.
NCache Puntos de referencia de rendimiento
Permítanme mostrarles algunos números de referencia para demostrar que es muy escalable. En nuestra web están publicados estos números. Entonces, estos son los detalles de la prueba y luego, si observa el rendimiento, está creciendo para lecturas, no tan lineal para escrituras, pero esta es la topología que usaremos en el seminario web de hoy, las lecturas y escrituras están creciendo linealmente y esto tiene las lecturas y escrituras crecen linealmente, así como las copias de seguridad. Por lo tanto, esto también viene con soporte de copia de seguridad, por lo que el rendimiento o la capacidad de escritura es ligeramente menor que la partición que no tiene ninguna copia de seguridad, por lo que también tiene una sobrecarga de copia de seguridad. Por lo tanto, esta es nuestra topología más popular para lecturas y escrituras y, a medida que agrega más servidores, también aumenta la capacidad.
Demostración práctica
Permítanme llevarlos a nuestro entorno de demostración, configurar un caché distribuido y luego comenzar con estas funciones una por una y chicos, quiero decir si hay alguna pregunta.
voy a estar usando, ya he descargado instalado NCache, el alcance de este seminario web no está disponible NCache configuraciones o instalación. Omitiré algunos de los detalles aquí, pero solo para que lo sepas, he descargar NCache desde nuestro sitio web una versión de prueba completamente funcional y luego la instalé en dos de mis cajas de servidor de caché y una máquina en mi extremo se utilizará como cliente. puedes instalar NCache también en el cliente o puede usar los paquetes NuGet según sea necesario.
Crear un caché
Simplemente crearé un caché, llamémoslo aspnetcache porque eso es lo que tenemos enfocado hoy.
Elegiré la caché de réplica de partición y todas estas configuraciones se analizan con gran detalle en nuestro NCache arquitectura seminarios web
Opción de replicación asíncrona y aquí, especifico los servidores que inicialmente formarán parte de mi clúster de caché.
Mantenga todo igual para el puerto TCP/IP. NCache es una comunicación basada en TCP/IP, la comunicación servidor-servidor y cliente-servidor se administra a través de TCP/IP y luego el tamaño del caché en cada servidor, mantendré todo predeterminado, mantendré los desalojos predeterminados y elegiré finalizar y eso es todo.
Así de fácil es configurar el caché. En el panel derecho tenemos todas las configuraciones relacionadas con este caché y, por cierto, también puede configurar líneas de comando y herramientas de PowerShell y luego puede administrar todo desde la línea de comando o PowerShell también. Agregaré mybox desde donde planeo ejecutar aplicaciones. Entonces, si tenemos configuraciones del lado del cliente actualizadas y puedo conectarme a este caché, comenzaré y probaré este clúster de caché y eso es todo. La configuración del sitio de mi servidor está completa en este punto. Chicos, por favor háganme saber, ¿hay alguna pregunta? Muy bien, entonces, esto ha comenzado. Haré clic derecho y elegiré estadísticas.
Ron, tengo una pregunta aquí muy rápido. NCache flujos para admitir aplicaciones Java para sesiones JSP, ¿un almacenamiento en caché de sesión o son solo aplicaciones ASP.NET? De acuerdo, esa es una muy buena pregunta, principalmente este seminario web se centró en ASP.NET, así que me concentré más en el sitio de ASP.NET, pero sí para responder esta pregunta. NCache soporte completo para aplicaciones Java, tenemos un cliente Java y luego para aplicaciones Java, si tiene sesiones web Java o sesiones JSP, podría muy bien usar NCache. Entonces, nuestro proveedor sigue siendo exactamente el mismo, es una opción sin cambio de código y tenemos una aplicación de muestra que viene instalada con NCache así como. Entonces, solo necesitas instalar NCache en el entorno de Windows o también podría usar contenedores y luego la aplicación podría estar en Windows o también podría estar en el entorno Linux UNIX, es totalmente compatible con las aplicaciones Java.
Monitorear estadísticas de caché
Abrí estadísticas solo para ver algunos aspectos de monitoreo, también abrí una herramienta de monitoreo que viene instalada con NCache. Ejecutaré rápidamente una aplicación de herramienta de prueba de estrés para verificar que mi caché esté bien configurada y, a continuación, comenzaré con las aplicaciones de muestra, un cliente está conectado, debería ver algo de actividad aquí, listo y tenemos contadores. mostrando el valor de las solicitudes por segundo de ambos servidores y ya tenemos algunos gráficos que se están completando.
Entonces, asegúrese de que todo esté configurado correctamente y luego podamos comenzar con nuestras aplicaciones de muestra.
Entonces, la primera aplicación de muestra es, estas son cinco optimizaciones diferentes. Hablaré sobre estos uno por uno y luego le mostraré las aplicaciones de muestra. En primer lugar, puede utilizar NCache para el almacenamiento en caché de datos, tenemos nuestra API detallada para los cuellos de botella de la base de datos. Puede usar un caché distribuido en memoria rápido, es más rápido porque está en la memoria, es más escalable porque puede agregar más servidores y luego aumenta la capacidad en tiempo de ejecución agregando más servidores. Puede usarlo para el estado de la sesión. Esta es una opción sin cambio de código, las sesiones son muy confiables en NCache debido a que estos se replican, las sesiones se administran en un repositorio rápido y escalable también en comparación y no necesita equilibrio de carga de sesión persistente. Hablaré sobre más beneficios una vez que mostremos estas aplicaciones de muestra, pero solo le dejaré saber que estos son algunos de los beneficios que obtiene de NCache tan pronto como usted enchufa NCache para éstos.
Para las granjas web, puede usar el estado de vista, puede almacenar el estado de vista en el extremo del servidor, no necesita enviar el estado de vista y también reduce el tamaño de la carga útil del estado de vista, luego puede usar NCache para SignalR Backplane, esa es nuestra cuarta opción y luego también puedes usar NCache para el almacenamiento en caché de salida, así como para el contenido estático y esto también es cierto para ASP.NET core. Puede usarlo para el estado de la sesión dentro de ASP.NET core y también puede usarlo para el almacenamiento en caché de respuestas en ASP.NET core aplicaciones.
Ejemplo de almacenamiento en caché de sesión de ASP.NET
Entonces, comencemos con el almacenamiento de estado de sesión de ASP.NET. Esto es lo más fácil de todo, puede configurarlo en cinco minutos y puede probarlo rápidamente. De hecho, le mostraré cómo configurarlo y luego empezar a usarlo.
Entonces, esa es nuestra primera aplicación de muestra, lo que hice es que viene instalada con NCache también, pero lo he modificado ligeramente. Para el almacenamiento en caché de sesiones, todo lo que necesita hacer es agregar una etiqueta de ensamblaje, estos dos ensamblajes son redundantes, estos son para otro caso de uso para el almacenamiento en caché de objetos, pero solo necesita Alachisoft.NCacheEnsamblado .SessionStoreProvider. La versión 4.9 es la última versión y luego también necesita una cultura y un token público para este ensamblaje. Entonces, esta es una referencia típica a este ensamblaje de estado de sesión, después de esto, debe reemplazar su etiqueta de estado de sesión existente con NCache. Si ya tiene una etiqueta de estado de sesión, debe reemplazarla, si no tiene una, era InProc, en ese caso podría reemplazarla, puede agregarla como nueva. Aquí el modo es personalizado y el proveedor es NCacheSessionsProvider, el valor de tiempo de espera es si un objeto de sesión en NCache permanece inactivo durante más de veinte minutos, caducará automáticamente y se eliminará de la memoria caché.
Luego hay algunas configuraciones como excepciones para habilitar. Por lo tanto, esto se puede usar como una etiqueta de muestra, puede copiarlo desde aquí y pegarlo en la aplicación y luego lo más importante es el nombre del caché, solo necesita especificar el nombre del caché aspnetcache. Creo que uso el mismo nombre aspnetcache y resolvería las configuraciones para esta muestra porque solo especifica el nombre. Por lo tanto, solo leería las configuraciones para este caché desde client.ncconf aspnetcache o este archivo también puede formar parte del proyecto. Si tiene un paquete NuGet, también podría hacer que este archivo forme parte de su proyecto y eso es todo. Solo necesita guardar esto y déjeme hacer esto como una página principal porque estábamos usando dos páginas aquí y ejecutaré esto y esto iniciaría las sesiones de juego de invitados para el proveedor y se conectaría a NCache para datos de sesión.
Entonces, espero crear un objeto de sesión en el caché y luego leeré algunos datos de la sesión y también le mostraré el objeto de sesión que se está creando. Esta es una aplicación de juego de adivinanzas, le permite adivinar un número entre uno y cien y luego imprime el invitado anterior del objeto de la sesión. Entonces, adivinó que el número está entre 0 y 23. Entonces, solo adivinaré 12, el número está entre 12 y 23. Entonces, también leyó el último número. Supongamos que el número está entre 13 y 23. Entonces, supongamos una vez más. No puedo adivinar, con suerte llegaré allí, pero solo para informarle que se debe haber creado un objeto de sesión en el extremo del servidor.
Déjame mostrarte esto con la ayuda de una herramienta y ahí está, NCache test es una palabra clave que agrego con esta aplicación de muestra. Si lo cambio, esto es para distinguir entre sesiones de diferentes aplicaciones, podría haber un escenario en el que tenga dos aplicaciones y usará el mismo caché para ambas aplicaciones. Entonces, en ese caso, puede agregar una ID de aplicación a la variable de sesión, pero normalmente una aplicación debe almacenar en caché su sesión en un caché dedicado. Por lo tanto, realmente no importa, si incluso lo especifica como una cadena vacía, pero esto se ha creado y esta es su ID de sesión de ASP.NET, la sesión aquí se replica aquí. Entonces, si este servidor se cae, los datos de la sesión estarán disponibles automáticamente.
Algunos beneficios más de NCache el estado de la sesión en comparación con los hits de InProc fuera del proceso, por lo que su proceso web no tiene estado. Entonces, eso es lo que prefiere el protocolo HTTP, es más escalable, puede agregar más recursos, es más rápido porque está en la memoria, es comparable con InProc y luego es muy confiable. Si un servidor se cae, no tiene que preocuparse por nada y, lo que es más importante, ya no tiene que usar sesiones pegajosas o equilibrio. Puede tener un equilibrio de carga igual y la solicitud puede rebotar de un servidor web a otro. No tiene que preocuparse por nada porque los servidores web no almacenan nada, los objetos de sesión reales se almacenan en NCache y este es un almacén de procesos externo para sus aplicaciones y comparaciones de StateServer. No es un punto único de falla, si un servidor deja de funcionar o lo desconecta por mantenimiento, no tiene que preocuparse por nada, simplemente funcionaría sin problemas.
En segundo lugar, es muy escalable, puede agregar más servidores sobre la marcha. Es muy confiable, es muy escalable, es rápido en comparación. Para la base de datos, no es lento, es rápido y es muy escalable y, en algunos casos, es incluso mejor en términos de confiabilidad donde no tiene replicación para las bases de datos. Entonces, esto lo cubre y una característica más importante dentro NCache es nuestro soporte de sesión multisitio, esa es otra característica sesiones multirregionales, donde tendrá sesiones de dos regiones diferentes almacenadas en NCache y puedes tener sesiones totalmente sincronizadas.
Si una solicitud de sesión rebota de un servidor a otro o de una región a otra, se alimentará automáticamente de la sesión en toda la región y la traerá aquí y viceversa. Por lo tanto, si necesita bajar el lado, puede enrutar todo su tráfico al otro lado manteniendo el caché en funcionamiento durante un período de tiempo. Entonces, esa es otra característica. Una de nuestras principales aerolíneas, el cliente de las aerolíneas, en realidad está utilizando esta función para su afinidad de ubicación. Entonces, esto cubre nuestro estado de sesión ASP.NET. Este es un proveedor sin cambio de código, por favor hágamelo saber si hay alguna pregunta al respecto, entonces ya respondí una pregunta sobre las sesiones JSP, puede usar NCache también para sesiones web basadas en Java. Suponiendo que no haya preguntas.
ASP.NET View State Ejemplo de almacenamiento en caché
A continuación, hablaré sobre el estado de vista, ahora NCache también tiene un proveedor de estado de vista, la forma en que funciona es que, básicamente, mantenemos el estado de vista en el extremo del servidor. Es nuevamente un proveedor, todo lo que necesita hacer es configurar un grupo de secciones correctamente, es la configuración de contenido, es ContentOptimization.Configurations.ContentSettings. El nombre del grupo de secciones es nContentOptimization y luego tiene algunas configuraciones en las que toma un nombre de caché, por ejemplo, estoy usando mycache en este momento, la forma en que hemos diseñado nuestro ASP.NET view state proveedor es que mantenemos el estado de vista en el lado derecho del servidor. Entonces, antes que nada, ejecutaré sin almacenamiento en caché, aunque tengo el proveedor anterior conectado, pero configuré el almacenamiento en caché del estado de vista para que sea falso y ejecutaré esto y le mostraré el estado de vista real. al navegador.
Entonces, te mostraré la opción predeterminada y luego te mostraré la NCache ver el estado y compararemos la diferencia. Entonces, hay una granja web de algunas páginas y le mostraré la fuente de la página de vista.
Este es el estado de vista predeterminado, la parte de valor, déjame traerlo aquí y déjame crear un documento temporal aquí. Este es el estado de vista predeterminado que es parte de mi paquete de respuesta y cuando vuelvo a esta página, también será parte de mi paquete de solicitud. Esa es una solicitud individual y observe cuántos caracteres, se ha agregado a los encabezados de solicitud y respuesta a la derecha y esto es lo mismo para todas las solicitudes que haré. Déjame mostrarte algunas solicitudes más y déjame mostrarte la fuente de la página de visualización de esta también.
Entonces, es casi similar a lo que podrías ver en la pantalla. Ahora con NCache lo que hemos hecho es interceptar su estado de vista con la ayuda de nuestro proveedor de estado de vista. Mantenemos el estado de visualización en el extremo del servidor, por lo que, en esta parte del valor, creamos una clave y un valor para una página determinada de la granja web, lo almacenamos en el extremo del servidor, ahora se almacena en el extremo del servidor, por lo tanto, enviamos un pequeño token volver al navegador. Entonces, ese es un token de tamaño estático, que se envía de vuelta al navegador. Realmente nunca cambia, siempre se enviará allí y luego se traerá de vuelta para usarse nuevamente y cuando lo publique, en realidad hace una llamada a NCache y obtener el estado de vista adicional de NCache y luego úselo en su granja web para ver el estado real y eso es lo que estamos haciendo detrás de escena.
Los beneficios que obtiene su paquete de estado de vista se vuelven más pequeños en tamaño porque es un token. Entonces, eso tiene el impacto general de reducir el tamaño de la carga útil para la solicitud y la respuesta. Entonces, esto mejora su rendimiento y, en segundo lugar, si tiene cientos de kilobytes de estado de vista que viajan de un lado a otro para miles de solicitudes, consumirá su ancho de banda. S, esto no va a pasar con NCache, NCache view state es un token estático y le mostraré el token rápidamente.
Ron, déjame saltar a la pregunta, lo hace muy rápido. NCache ¿Tiene alguna característica de seguridad de la factura, como el cifrado de las sesiones y el almacenamiento en caché del estado de visualización? sí lo hace, estas son características que puede configurar explícitamente, estas son generales NCache características. Por lo tanto, todo el estado de la vista ya es una cadena cifrada, pero si desea cifrar aún más y déjeme ver si está disponible, sí, puede habilitar el cifrado en el caché, debe detenerlo, configurar el cifrado, tenemos proveedores de DES. , tenemos proveedores AES, tenemos clientes FIPS, compatibles con FIPS, proveedores DES AES. Entonces, sí, simplemente puede configurar esto y toda la carga útil de los servidores cliente se cifraría y descifraría aquí y se recuperaría respectivamente. Entonces, esto es algo que puede configurar a pedido y puede hacer que las cosas funcionen y, con esta pregunta, también quiero resaltar que, dado que NCache no está almacenando este es el estado de vista después NCache se ha conectado se ha conectado como proveedor y observe la diferencia, son estos muchos caracteres frente a estos muchos caracteres. Entonces, este es su valor predeterminado, esto es con NCache y vea la diferencia usted mismo, esto se ralentiza, reduce el tamaño de la carga útil sobre todos los aumentos de rendimiento, los costos de virtualización de banda disminuyen. Por lo tanto, ve muchas mejoras en la arquitectura y, lo que es más importante, su estado de vista real nunca más se envía de vuelta al navegador. Se almacenará en el extremo del servidor, es seguro en general.
Entonces, en base a esta pregunta, gracias por preguntar esto. NCache view state es por defecto más seguro que la opción por defecto porque lo almacenamos en el extremo del servidor que es donde realmente se necesita. Entonces, espero que eso ayude. Voy a cerrar esto, cualquiera de las preguntas sobre el estado de vista, de lo contrario, pasaré a nuestro próximo segmento.
Ejemplo de almacenamiento en caché de datos de la aplicación
Permítanme mostrarles primero el almacenamiento en caché de objetos debido a la limitación de tiempo. Creo que debería cubrir esto primero. Para los cuellos de botella de la base de datos, cualquier cosa que se almacene en la base de datos que ralentice las cosas, alternativamente, puede usar un caché distribuido como NCache. Es NCache API aquí.
Conexión de cachéCache cache = NCache.InitializeCache("myCache");
cache.Dispose();
Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Así es como conecta el caché, así es como dispone el identificador hacia el final de las operaciones, todo se almacena en un par de valores clave, es un objeto permitido de .NET de valor clave de cadena, puede asignar sus tablas de datos a sus objetos de dominio y luego almacena sus objetos de dominio y luego se ocupa de los objetos de dominio almacenando objetos individuales o colecciones que tienen relaciones, SQL busca en la lista, pero esta es una operación básica de creación, lectura, actualización y eliminación.
Ejecutaré rápidamente una aplicación de muestra y demostraré cómo usaría realmente NCache para el almacenamiento en caché de objetos. Necesitas estas dos referencias resumidas Alachisoft.NCache.web y Alachisoft.NCache.Tiempo de ejecución. Una vez que haya hecho esto, déjeme hacer esto como una página de inicio y mostrarle el código detrás de esto. Esta es una granja web ASP.NET, pero si tiene controladores MVC, también podría usar el mismo enfoque y luego tengo este espacio de nombres aquí y dentro de esta aplicación, estoy inicializando mycache, debe especificar el nombre del caché y también puede especificar servidores aquí, usando InitParams derecho caché InitParams aquí o simplemente puede especificar el nombre y resolver el nombre a través de client.ncconf que le mostré anteriormente. Hay un addObject, que agrega un cliente, el nombre es David Jones, hombre, número de contacto, esta es la dirección y luego llamo a cache.Add.
Del mismo modo, estoy insertando esto cambiando la página o, de hecho, también podría cambiar el nombre solo para asegurarme de que esté actualizado y luego estoy llamando a cache.Insert y luego estoy recuperando el objeto, obteniendo el recuento del objeto. Estoy eliminando ese objeto, solo estoy ejecutando una prueba de carga. 100 artículos se actualizarán una y otra vez. Por lo tanto, ejecutemos la aplicación de muestra, así de intuitivo es comenzar con ella y simplemente iniciaría la aplicación y podré realizar todas estas operaciones por usted y antes de hacer esto, también me gustaría para mostrarle los estados de vista que se almacenaron en caché NCache.
Podría ver las claves para el estado de vista durante tres páginas vs y esta es la clave real del objeto y luego el estado de vista real está en la parte del valor. Olvidé mencionar esto ahora, suponiendo que me hayamos dejado borrar el contenido. Entonces, ahora que solo estamos tratando con datos de almacenamiento en caché de objetos, en realidad déjenme hacer esto desde el administrador, es conveniente. Entonces, agregaré un objeto, el cliente agregó. Recuperaré este objeto. Entonces, tenemos a David Jones, de 23 años. Lo actualizaré y luego lo agregaré, lo recuperaré ahora es David Jones 2 y luego tenemos 50 como edad, nuevamente obténgalo, elementos en el caché 1, eliminaré este objeto nuevamente elementos en el caché 0 insértelo una vez más, inserte está en agregar y recupere el objeto y luego puedo mostrarle esto en el caché. Entonces, estaba tratando con un objeto en este punto y la clave era cliente en el nombre del cliente adjunto y luego comenzaré la carga, probaré ahora. Vería algo de actividad en el caché, hay solicitudes entrantes y tiene solicitudes de clientes que se ocupan de los datos.
Y si simplemente vuelvo a ejecutar estas claves de caché de volcado, solo me mostrará las cien claves volcadas juntas. Entonces, estas son las claves que agregué. Entonces, así de simple es comenzar con el almacenamiento en caché de objetos, cualquier dato que pertenezca a la base de datos y ralentice las cosas, limite su escalabilidad, puede llevarlo a NCache utilizando nuestro almacenamiento en caché de objetos. Podría ser cualquier objeto de dominio, colecciones, conjuntos de datos, imágenes, cualquier tipo de datos relacionados con la aplicación que se puedan almacenar en caché mediante el modelo de almacenamiento en caché de objetos. Espero que esto ayude, déjame comenzar con esto, está bien, esto cubre nuestro almacenamiento en caché de datos a continuación, hay SignalR Backplane.
ASP.NET SignalR Backplane Muestra
Vamos a hablar acerca de SeñalR. Con NCache tenemos un poderoso mensajes de publicación/suscripción plataforma. Entonces, tenemos una aplicación de muestra y también les mostraré los paquetes de NuGet. NCache Las bibliotecas vienen instaladas con la instalación o puede usar nuestros paquetes NuGet. Entonces, si va a nuestro repositorio NuGet en línea y busca NCache, verá todos los paquetes de NuGet. Alachisoft.NCache.SDK es para el almacenamiento en caché de objetos, Linq para la consulta de linq, tenemos un proveedor de estado de sesión, luego también tenemos código abierto y comunidad.
Este es el paquete NuGet que he incluido en esta aplicación. Solo constrúyalo y veamos si funciona bien porque debería tener un paquete NuGet agregado. Muy bien, para SignalR Backplane todo lo que necesita hacer es asegurarse de haber agregado el paquete SignalR NuGet, quiero decir que esto es instalar si aún no está instalado, de acuerdo. Entonces, tiene un paquete NuGet agregado y luego necesita agregar, agregó algunos ensamblajes de SignalR según sea necesario y algunos ensamblajes de ayuda también y luego, si va a web.config, acabo de agregar algunas configuraciones allí mi nombre del caché es aspnetcache right y luego la clave del evento, que es el nombre del tema que te gusta para esto. Entonces, en realidad le gustaría proporcionar un nombre de tema basado en el cual le gustaría que se transmitieran los mensajes de chat de SignalR o los mensajes de SignalR para esta aplicación de chat en particular y luego todo lo que necesita hacer es cambiar una línea de código dentro donde especifica el nombre del caché y la clave del evento y apunta a las palabras NCache y ejecute la aplicación de ejemplo. Se usaría automáticamente NCache para el plano posterior de SignalR, NCache se convierte en su backplan así de simple es enchufar NCache para la aplicación SignalR.
Beneficios que obtiene su .NET nativo a diferencia Redis es rápido, escalable, confiable en comparación con las bases de datos y los buses de mensajes, y luego tenemos un modelo pub/sub completamente funcional y totalmente compatible, que respalda esto. Por lo tanto, también puede usar la mensajería de publicación/suscripción directamente, pero una extensión de ese caso de uso de la mensajería de publicación/suscripción es nuestra SignalR Backplane y es bastante fácil de configurar también.
Entonces, esta aplicación ha comenzado. Debería haber una clave aquí, creo que es difícil encontrar la clave, pero solo para mostrarte el chat. NCache, esto funciona y voy a transmitir esto a otro navegador firmando otro usuario, digamos Nick. Si vuelvo a traer esto, podría ver que en realidad también transmitió el mensaje al otro cliente conectado. Entonces, así de fácil es. Déjame preguntarte una vez más y luego verificar si funciona como se esperaba, así que ahí lo tienes. Entonces, esto está siendo impulsado NCache y es muy fácil de configurar y así es como se configura y la última característica dentro NCache, el quinto refuerzo es el almacenamiento en caché de salida.
Ron, tengo una pregunta sobre SignalR, nuestros mensajes de SignalR almacenados como un objeto visual dentro NCache o lo hace NCache ¿Usar notificación para esto? NCache usa la notificación de publicación/suscripción para esto. Por lo tanto, tenemos una plataforma de mensajería de publicación/suscripción que está en segundo plano, en el caché en sí solo vería un objeto o ni siquiera verá el objeto porque es un tema. Entonces, hay un tema que se crea, es un túnel lógico donde se conectan múltiples procesos de trabajo y en realidad transmiten NCache, todos los mensajes de SignalR a ese tema. Entonces, es un marco de notificación si está preguntando, si vería muchos mensajes agregados en el caché, no, no lo haría, solo vería un tema y luego hay mensajes dentro del tema. Hay algunas estadísticas en los encuentros emergentes que puede visualizar para ver cuántos mensajes hay dentro del tema, pero en lo que respecta a los objetos individuales, no verá esos objetos, solo verá un objeto como tema. Espero que eso ayude.
Ejemplo de almacenamiento en caché de resultados de ASP.NET
Característica final dentro de esto, creo que también tenemos poco tiempo, repasaré esto rápidamente. Es nuestro almacenamiento en caché de salida, solo necesita configurar la sección de almacenamiento en caché de salida, necesita una referencia a NCache DLL del proveedor de caché de salida. Esto es justo aquí, necesita estas referencias Ncache.Adaptadores, web, tiempo de ejecución en caché y luego simplemente consulte el proveedor de caché de salida N y luego configure el nombre del caché en aspnetcache, la versión debe ser la más reciente. La forma en que funciona es que en realidad almacena en caché la salida de las páginas estáticas, simplemente lo ejecuta y luego simplemente almacenará en caché la salida de una página estática. Si es la página completa o partes dentro de la página las que son estáticas y usted decora sus páginas estáticas parciales con esta caché de salida de directiva, especifique una duración, ubicación y VaryByParam. Si estos parámetros no cambian, eso significa automáticamente que esta es la misma salida.
Por lo tanto, la salida en caché se presenta a sus usuarios finales, no tiene que ejecutar las páginas, no tiene que involucrar bases de datos, quitar la carga de los procesos de trabajo, fuera de la base de datos, ahorrar costosas CPU y recursos de máquina y obtenga una salida de página lista para usar disponible para sus clientes finales. Por lo tanto, en general mejora su rendimiento, ASP.NET proporciona esto como una función y NCache lo lleva a un nivel distribuido donde tenemos una salida de página muy escalable, muy rápida y muy confiable almacenada en NCache sin ningún cambio de código y esto es cierto para ASP.NET core también, podrías usar por la forma en que puedes usar NCache dentro de ASP.NET core aplicaciones web también. Hicimos un seminario web por separado sobre eso y si tenemos caché distribuido, tenemos almacenamiento de sesión y luego también tenemos ASP.NET core almacenamiento en caché de respuesta junto con el almacenamiento en caché del núcleo EF.
Entonces, estas son algunas de las características que quería resaltar, esto completa nuestros cinco potenciadores de rendimiento. Espero que les haya gustado, por favor avíseme si hay alguna otra pregunta, creo que también tenemos muy poco tiempo. Entonces, si hay otras preguntas, ahora es el momento de hacer esas preguntas, así que hágamelo saber.
En general, también me gustaría mencionar que NCache es un clúster de caché dinámico de tiempo de actividad del cien por cien totalmente elástico, sin punto único de falla. Tenemos muchas topologías y funciones como encriptación, seguridad, compresión, alertas de correo electrónico, sincronización de bases de datos, búsquedas similares a SQL, consulta continua, modelo pub/sub, datos relacionales en NCache, todos estos están cubiertos como parte de diferentes características. Entonces, si hay alguna pregunta específica sobre esto, siéntase libre de hacer esas preguntas también, de lo contrario, concluiré y se lo pasaré a Nick.
Muchas gracias, Ron, una última pregunta: ¿es posible configurar un proveedor personalizado para el almacenamiento en caché de sesiones en NCache? NCache ya es un proveedor personalizado. NCache se encuentra bajo un proveedor personalizado, los modos predeterminados son InProc, State Server o SQL Server y luego el cuarto modo de ASP.NET es personalizado. Asi que, NCache El proveedor en sí es un proveedor personalizado. Estoy un poco confundido sobre la pregunta si hay algún requisito específico en torno a esto, por favor hágamelo saber de lo contrario NCache en sí mismo es un proveedor personalizado para ASP.NET.
De acuerdo, muchas gracias Ron, si no hay más preguntas, me gustaría agradecer a todos por venir y unirse a nosotros hoy y gracias a Ron nuevamente por su valiosa información sobre esto y si tienen alguna pregunta, siempre pueden comunicarse con nosotros enviándonos correos electrónicos. en support@alachisoft.com. Se pone en contacto con nuestro equipo de ventas enviándonos un correo electrónico a sales@alachisoft.com y alguien del equipo de ventas estará encantado de trabajar con usted y asegurarse de que todas sus preguntas sean respondidas, proporcionar toda la información que necesita y con eso también le sugiero que puede descargar una versión de prueba de nuestro sitio web de NCache, viene con una prueba de 30 días. También tenemos una mediación que tiene una opción de soporte pago, así como una edición gratuita de código abierto, trece años con mucho contenido. Gracias a todos por unirse a nosotros y nos vemos la próxima vez, gracias.