Código de Orlando Campamento 2019

Optimizar ASP.NET Core Rendimiento con caché distribuida

Por Iqbal Kan
Presidente y evangelista tecnológico

ASP.NET Core se está volviendo rápidamente popular para desarrollar aplicaciones web de alto tráfico. Aprenda a optimizar ASP.NET Core rendimiento para manejar cargas de transacciones extremas sin ralentizar mediante el uso de una caché distribuida de .NET de código abierto. Esta charla cubre:

Resumen rápido de ASP.NET Core cuellos de botella de rendimiento
Descripción general del almacenamiento en caché distribuido y cómo resuelve los problemas de rendimiento
¿Dónde puede usar el almacenamiento en caché distribuido en su(s) aplicación(es)?
Algunas funciones importantes de caché distribuida
Ejemplos prácticos usando Open Source NCache como el caché distribuido

Voy a repasar este tema de cómo puede optimizar ASP.NET core rendimiento y voy a usar el almacenamiento en caché distribuido como técnica para realizar esas mejoras y voy a usar NCache como el ejemplo en esto.

ASP.NET Core Popular (aplicaciones de alto tráfico)

Todos sabemos que ASP.NET core es el nuevo .NET core, la arquitectura limpia y liviana, la multiplataforma y el código abierto, y esa se está convirtiendo en una de las principales razones por las que más y más personas se están mudando a ASP.NET core.

Además, hay una gran base de usuarios de ASP.NET heredada y, especialmente, si es una aplicación ASP.NET MVC y luego se muda a ASP..NET core es bastante sencillo. Si no es un MVC, entonces, por supuesto, tiene mucho código para escribir. Entonces, todas esas son las razones por las que estoy seguro de que también estás aquí porque ASP.NET core es la opción líder de .NET para hacer aplicaciones web.

ASP.NET Core Necesita escalabilidad

Entonces, cuando tienes ASP.NET core se está utilizando cada vez más en situaciones de alto tráfico. El alto tráfico generalmente significa que tiene una aplicación orientada al cliente. Puede ser un negocio en línea, puede ser un negocio minorista. Hay una gran cantidad de industrias, atención médica, gobierno electrónico, redes sociales, apuestas en línea, juegos de azar, todo lo que se pueda imaginar. Todo el mundo está en línea en estos días. Entonces, ¡cualquiera! Cuando hay una aplicación web ASP.NET core se está utilizando eso significa ASP.NET core necesita ser escalable.

¿Qué es la escalabilidad?

¿Qué significa eso? Permítanme definir eso, estoy seguro de que saben mucho, pero solo para completar, solo voy a definir la terminología.

Entonces, la escalabilidad significa que si tiene una aplicación que con cinco usuarios tiene un tiempo de respuesta realmente bueno, hace clic en ella y en uno o dos segundos vuelve la página. Entonces, si puede lograr el mismo tiempo de respuesta con cinco mil o cincuenta mil o quinientos mil usuarios, entonces su aplicación es escalable. Si no puede, entonces no es escalable. Si no tiene un alto rendimiento con cinco usuarios, entonces debe ir a otras discusiones sobre cómo ha escrito su código. Pero supongo que su aplicación está desarrollada con buenos algoritmos, con un buen enfoque y es una aplicación de alto rendimiento con cinco usuarios. Entonces, ¿cómo se logra un alto rendimiento bajo cargas máximas?

¿Qué es la escalabilidad lineal?

Entonces, si puede pasar de cinco a cinco mil a cincuenta mil, eso se llama escalabilidad lineal.

Y, la forma en que lo logra, como sabe, en un entorno de equilibrio de carga, implementa ASP.NET core aplicación con un balanceador de carga y agrega más y más servidores. Entonces, a medida que agrega más servidores, aquí, su capacidad de transacción, su número de solicitudes por segundo aumenta de manera lineal. Si puede lograr eso, entonces podrá lograr el mismo rendimiento. Y ese es el objetivo de la charla de hoy: queremos poder lograr este alto rendimiento bajo cargas máximas. Entonces, si no tiene un alto rendimiento bajo carga máxima, si no tiene una aplicación lineal, eso significa que tiene algunos cuellos de botella, en alguna parte. Entonces, tan pronto como supere un cierto umbral, no importa si agrega más cajas. En realidad, probablemente ralentizará las cosas porque hay un cuello de botella en algún lugar que impide su aplicación. Entonces, definitivamente no quieres ser una escalabilidad no lineal.

¿Qué aplicaciones necesitan escalabilidad?

Solo para recapitular, ¿qué tipos de aplicaciones deben ser escalables?

las aplicaciones necesitan escalabilidad

Obviamente, ASP.NET core que es de lo que estamos hablando. También puede tener servicios web, lo que significa que las aplicaciones ASP.NET son las aplicaciones web, lo que significa que sus usuarios son humanos. Los servicios web vuelven a ser aplicaciones web. Sus usuarios son otras aplicaciones. Los microservicios son un concepto relativamente nuevo que también es para aplicaciones del lado del servidor. Por supuesto, eso implica rediseñar toda la aplicación. No voy a entrar en cómo se hace eso. Solo estoy mencionando los tipos de aplicación para que puedan mapear lo que ustedes estén haciendo o lo que esté haciendo su empresa, podría mapearse en esto o no. Y finalmente, muchas aplicaciones de servidor generales. Estas aplicaciones de servidor pueden estar realizando un procesamiento por lotes. Por ejemplo, si es una gran corporación, digamos, si es un banco, es posible que deba procesar muchas cosas en segundo plano en modo por lotes, en modo de flujo de trabajo y esas son las aplicaciones del servidor.

El problema de la escalabilidad y la solución

Por lo tanto, todos estos diferentes tipos de aplicaciones deben poder manejar la escalabilidad, lo que significa que deben poder procesar todas esas cargas de transacciones en aumento sin ralentizarse. Entonces, obviamente hay un problema de escalabilidad o de lo contrario no estaríamos teniendo esta conversación. Si todo estuvo bien, la buena noticia es que su nivel de aplicación no es el problema, su ASP.NET core aplicación no es el problema, es el almacenamiento de datos. Independientemente de los datos que esté tocando, lo que sea, no importa, eso está causando un cuello de botella en el rendimiento. Y esas son sus bases de datos relacionales, sus datos heredados de mainframe y muchos otros datos. Curiosamente, NoSQL databaseLas s no siempre son la respuesta porque en muchas situaciones no eres capaz de... porque NoSQL database le pide que abandone su base de datos relacional y cambie a una nueva base de datos SQL o NoSQL database que no puede hacer por una variedad de razones técnicas y no técnicas. Y, si no puede mudarse a un NoSQL database, ¿de qué sirve? ¿Derecha?

Entonces, mi enfoque es que debe resolver este problema con la base de datos relacional en la imagen porque esa es la base de datos que tendrá que usar, como dije, por una variedad de razones. Y, si no eres capaz de alejarte de él, entonces NoSQL databases no son la respuesta en muchas situaciones.

Implementación de caché distribuida

Por lo tanto, debe continuar usando una base de datos relacional y, en su lugar, implementar una caché distribuida en su aplicación.

Esto es lo que parece. Entonces, si ve que tiene el mismo nivel de aplicación, puede agregarle más y más servidores a medida que crece la carga de transacciones. En el caso de muchos de estos, digamos aplicaciones web y servicios web, generalmente son un balanceador de carga superior que se asegura de que cada servidor web reciba la misma carga de los usuarios. En el caso de las aplicaciones de servidor, es posible que no tenga mucho balanceador, puede depender de la naturaleza de la aplicación. Pero, el hecho es que puede agregar más y más servidores y aquí solo hay una base de datos. Y, como dije, puede haber algunos NoSQL database para algunos datos especializados más pequeños, pero la mayoría de los datos siguen siendo relacionales. Entonces, el objetivo es colocar un nivel de almacenamiento en caché en el medio y un caché distribuido es esencialmente un grupo de dos o más servidores y estos servidores son servidores de bajo costo. Estos no son servidores de base de datos de gama alta y todo se almacena en la memoria.

¿Por qué en la memoria? Porque la memoria es mucho más rápida que el disco duro. Si su aplicación necesita rendir más y más, debe ser absolutamente claro al respecto. El disco duro, ya sea SSD o HDD, lo va a matar. Tienes que ir a la memoria. Todo tiene que estar almacenado en la memoria o de lo contrario no vas a lograr el rendimiento que deseas. Y eso es independientemente de si va a un caché distribuido o no, pero en la memoria, este es el almacenamiento. Entonces, un caché distribuido tiene dos o más servidores. Forma un clúster y la palabra clúster significa que cada servidor sabe sobre el otro servidor en el clúster, agruparon los recursos, la memoria, la CPU y la tarjeta de red. Entonces, esos son los tres recursos que reúne en una capacidad lógica.

Memoria, porque cada servidor tiene RAM, por lo que una configuración típica que hemos visto usar a nuestros clientes es entre 16 y 32 gigas de RAM y cada servidor de caché. su mínimo de 16 recomendamos, entre 16 a 32. Y luego, en lugar de ir por encima de 32 a, digamos 64 o 128 gigas de RAM, en cada caja, lo que requiere que aumente la capacidad de la CPU porque cuanta más memoria tenga, más más recolección de basura que tienes que hacer. Debido a que .NET usa GC, más recolección de basura significa más CPU o, de lo contrario, la recolección de basura se convierte en el cuello de botella. Por lo tanto, es mejor tener un rango de 16 a 32 y no más grande y solo tener más cajas que tener 128 gigas de dos cajas. Entonces, para eso es la memoria.

La CPU obviamente es la segunda cosa. Nuevamente, la configuración típica es una caja de aproximadamente 8 núcleos. Algunas de las implementaciones de gama alta usarían alrededor de 16 núcleos, pero 8 núcleos son lo suficientemente buenos por caja. Como decía, servidores low cost. Y la tarjeta de red, por supuesto, porque todos los datos que se envían de aquí a aquí se envían a través de las tarjetas de red. Ahora, en el nivel de aplicación, obviamente tiene más servidores de aplicaciones que servidores de caché. Y nuevamente, por lo general, lo que recomendamos es una proporción de cuatro a uno o cinco a uno. Cinco servidores de aplicaciones en un servidor de caché con un mínimo de dos servidores de caché. Entonces, si tiene cinco servidores de aplicaciones aquí, tienen cinco tarjetas de red, están enviando datos a una proporción de cinco a uno de las tarjetas de red.

Entonces, la tarjeta de red, debe tener al menos una tarjeta de red gigabit o 10 gigabit en los servidores de caché. Aparte de eso, solo necesita juntarlos y digamos que comienza con dos como mínimo y cuando maximiza dos, lo que va a pasar es que lo sustituya, ejecutará su aplicación. Todo va a funcionar muy rápido o tal vez estés haciendo pruebas de carga. Todo va a funcionar súper rápido y el aumento de la carga. De repente, el lado del servidor comenzará a ver una mayor CPU, un mayor consumo de memoria y el tiempo de respuesta comenzará a disminuir. Ahora eso es lo que va a pasar con la base de datos relacional, excepto que aquí puede agregar un tercer cuadro y de repente obtiene otro gran alivio y ahora comenzará nuevamente con un rendimiento más alto y ahora puede agregar más y más transacciones, comenzará a alcanzar su punto máximo. y luego agregas una cuarta caja, ya sabes.

Entonces, así sigue aumentando este panorama y esto nunca se convierte en un cuello de botella esto, y Nunca digas nunca, pero casi nunca, se convierte en un cuello de botella porque puedes agregar más y más servidores. Y, a medida que agrega más servidores aquí, solo agrega más en este caché aquí, lo que no puede hacer con la base de datos. Ahora, pongo 8020 de carga. En realidad, es más como que el 90 % del tráfico va a la memoria caché y el 10 % va a la base de datos porque cada vez se van a leer más datos de la memoria caché. Voy a repasar algunos otros aspectos que tiene que manejar un caché, pero esto es básicamente una imagen, esta es la razón por la que necesita un caché distribuido.

Uso de caché distribuida

¡Okey! Entonces, sigamos adelante. Ahora que espero haberlo convencido de que necesita incorporar un caché distribuida en su aplicación que la primera pregunta que me viene a la mente es, bueno, ¿qué hago con eso? ¿Como lo uso? Entonces, hay tres categorías principales en las que puede usar un caché distribuido.

Hay otros, pero durante la mayor parte de la discusión, los tres son de muy alto nivel.

Almacenamiento en caché de datos de aplicaciones

El número uno es el almacenamiento en caché de datos de la aplicación. Esto es de lo que he estado hablando hasta ahora. Cualquier dato que esté en la base de datos, eso es lo que yo llamo datos de la aplicación, los estás almacenando en caché para que no vayas a la base de datos. Ahora, tenga en cuenta, y con cada uno de estos, con una aplicación de almacenamiento en caché de datos, la naturaleza del problema es que los datos existen en dos lugares; la caché y la base de datos. Y, siempre que existan datos en dos lugares, ¿qué es lo que podría salir mal? ¡Fuera de sincronización! ¡Sí! Por lo tanto, los datos podrían perder la sincronización. Entonces, si sus datos y el caché no estaban sincronizados con la base de datos, eso podría crear muchos problemas. Podría retirar un millón de dólares dos veces suponiendo que tuviera que empezar, pero, digamos que... Ese es el primer problema que me viene a la mente.

Cualquier caché, cualquier caché distribuida que no pueda manejar ese problema, significa que está limitado a datos de solo lectura. Pero, lo que llamamos datos de referencia. Y así es como el almacenamiento en caché comenzó a entenderse como caché de datos de solo lectura en mis tablas de búsqueda. La tabla de búsqueda es aproximadamente el 10% de sus datos. En algunas aplicaciones no es más que una aplicación promedio. El 90% de sus datos no son datos de búsqueda. Son datos transaccionales. Son sus clientes, sus actividades, sus pedidos, todo. Entonces, si no puede almacenar en caché todo eso, entonces el beneficio, digamos el 10% de los datos, tal vez la búsqueda realmente se está haciendo más de lo que le corresponde. Entonces, ese 10 % podría darle el beneficio del 30 %, pero todavía tiene el 70 % de los datos que tiene que ir a la base de datos. Pero, si pudiera almacenar en caché todos los datos, lo que solo sería posible si obtiene esa comodidad, entonces obtendrá el beneficio real.

ASP.NET Core Almacenamiento en caché específico

El segundo caso de uso o la segunda forma de usar es lo que yo llamo ASP.NET core almacenamiento en caché específico y hay tres formas. Una es las sesiones, que es la más comúnmente entendida. ASP.NET los tenía ASP.NET core los tiene Están aquí para quedarse. No creo que las sesiones vayan a desaparecer, aunque algunas personas argumentan que no deberíamos usar sesiones. No hay ningún daño si los usas. El único problema con ellos es dónde los almacenas. Ese fue siempre el problema con ASP.NET. Cualesquiera que fueran las opciones de almacenamiento que Microsoft le dio, estaban llenas de problemas. Entonces, la única opción en ese momento era usar un caché distribuido que afortunadamente podías conectar como una opción personalizada en los días de ASP.NET. En ASP.NET core, Microsoft no tiene una imagen integrada o tienen una imagen como una memoria independiente, pero entran inmediatamente en una IDistributedCacheIDistributedCache o proveedor de sesión personalizado que puede conectar a un caché distribuido de terceros como NCache.

Sessions es el primero, el segundo es el almacenamiento en caché de respuestas. Iba a decir quién no sabe sobre el almacenamiento en caché de respuestas, pero esa no es una buena manera de preguntar. El almacenamiento en caché de respuestas es como una versión más nueva del caché de resultados, pero está más basado en estándares. Es el resultado de la página que puede almacenar en caché y lo revisaré, pero eso también es algo que puede almacenar en caché y conectar un caché distribuido como un middleware para ello.

Y, en tercer lugar, si tiene una señal o una aplicación, que es la aplicación web en vivo. Las aplicaciones web en vivo son aquellas donde, digamos, si tiene una aplicación de comercio de acciones que necesita propagar constantemente todos los cambios en el precio de las acciones y tiene cientos de miles de clientes. Todos están conectados, por lo que permanecerán conectados al almacenamiento en caché o los niveles de aplicación. Es diferente al HTTP regular donde para cada solicitud web se abre una nueva conexión de socket. Aquí, la conexión del socket permanece abierta y los eventos se propagan desde el servidor. Entonces, en un SignalR, cuando tiene una transacción más alta, una gran cantidad de usuarios, debe tener un formulario web con carga equilibrada, pero dado que los sockets se mantienen abiertos, cada servidor va a hablar con su propio cliente, pero ahora que todo el los clientes o todos los servidores tienen diferentes conjuntos de clientes, por lo que necesitan compartir datos. Entonces, esos datos se comparten a través de un backplane y ese backplane se convierte en... Entonces, ahí es donde se conecta una caché distribuida. No voy a repasar los detalles de ese Específico. Voy a repasar los dos primeros, pero no el tercero.

Ahora, lo específico sobre ASP.NET core almacenamiento en caché específico es que los datos existen sólo en el caché. Esto es lo que estaba diciendo, no lo pongas en la base de datos. No hay necesidad. Estos son datos temporales. Solo lo necesita durante 20 minutos, 30 minutos, una hora, 2 horas, lo que sea después de que los datos deban desaparecer. Entonces, si es temporal, solo debería existir en el caché y cuando los datos solo existen en el caché y es un caché en memoria, ¿qué podría salir mal? Podría perder datos porque está todo en la memoria. La memoria es volátil. Entonces, un buen caché distribuido tiene que manejar esa situación, por supuesto, eso significa que necesita replicar.

Mensajes y eventos Pub/Sub

El tercer caso de uso es que muchas aplicaciones necesitan realizar operaciones de tipo flujo de trabajo. El microservicio es un muy buen ejemplo de ello. Necesitan coordinar actividades, aunque los microservicios no son el tema sino incluso ASP.NET core las aplicaciones ocasionalmente necesitan hacer eso. Asi que, mensajes de publicación/suscripción es otra forma porque tiene, nuevamente tenga en cuenta, tiene una infraestructura en el lugar donde todas estas cajas están conectadas a esta infraestructura en memoria redundante. Entonces, ¿por qué no usarlo también para mensajes de publicación/suscripción?

Entonces, esos son los tres casos de uso comunes. Entonces, estas son las tres formas en que debe usar NCache o un caché distribuido si quieres beneficiarte, si quieres maximizar el beneficio.

Demostración práctica

Entonces, voy a hacerlo rápidamente, antes de explicar cómo los usa realmente, quiero mostrarles cómo se ve un caché distribuido. Voy a usar Azure como entorno y voy a usar NCache. Y, es solo una demostración rápida de...

Configuración de un entorno

Entonces, estoy conectado a Azure. Tengo cuatro máquinas virtuales, nuevamente estas son todas .NET core.

Entonces, tengo cuatro máquinas virtuales en Azure. Voy a usar dos de estos como máquinas virtuales de servidor de caché, que básicamente son esos dos... Voy a tener un cliente de Windows y un cliente de Linux. Entonces, si tienes porque .NET core es compatible con Linux. Si usted tiene .NET core como la aplicación, es posible que desee implementar esto en Linux. Ahora bien, en caso de NCache, de nuevo, no estoy de marketing NCache. Pero en caso de NCache, es el .NET core por lo que puede ejecutarse en Windows o Linux, tanto en los servidores como en los clientes.

¡Okey! Vayamos a... Entonces, estoy conectado a este cliente, el cuadro de cliente de Windows. Entonces, ahora voy a seguir adelante y crear un caché para mí.

Crear una caché en clúster

Entonces, voy a usar esta herramienta llamada NCache, la NCache gerente en realidad no viene con código abierto. Hay un equivalente de línea de comandos, pero estoy siendo vago aquí. Entonces, solo voy a usar NCache manager pero es la misma funcionalidad. La funcionalidad no cambia, así que acabo de lanzar NCache gerente. Voy a decir crear un nuevo caché. Acabas de nombrar un caché. Todos los cachés tienen nombre. Piense en eso como una cadena de conexión a la base de datos y luego elija una topología. No voy a entrar en las topologías, pero lo haré hacia el final sobre lo que debe hacer un caché para poder manejar todas esas necesidades. Entonces, solo voy a usar la topología de caché de réplica de partición. Replicación asíncrona. Agregaré mi primer servidor de caché. 10.0.0.4 y el segundo 5. Entonces, tengo dos servidores de caché. Voy a mantener todo como predeterminado. Voy a los desahucios y todo lo demás.

Y ahora voy a especificar dos clientes. 10.0.0.6 y 7. Voy a venir aquí e iniciaré el caché. Entonces, piense en esto como una base de datos, en lugar de un servidor, tiene varios servidores que constituyen el clúster y crea un clúster de servidores de caché y luego asigna clientes. No es necesario que asigne los clientes porque simplemente puede ejecutarlos, pero lo hago aquí porque le brinda más flexibilidad.

Simule estrés y monitoree estadísticas de caché

Entonces, quiero ir y probar el cliente. Entonces, yo soy el cliente. Creo que soy 10.0.0.6. déjame asegurarme de cuál soy. Creo que soy 10.0.0.6 Creo. ¡Vamos! Entonces, de nuevo, estoy haciendo todo dentro de la red virtual de Azure para que el cliente sea realmente el servidor de aplicaciones y el caché ahora está todo junto. En caso de NCache Podrías haber obtenido esto de la azure marketplace. Entonces, .6 es el cliente de Windows. Entonces, voy a iniciar PowerShell y me aseguraré de poder ver. ¡Okey! ¡Okey! Entonces, verá que este cliente va a hablar con el caché y ahora estoy haciendo alrededor de quinientas seiscientas solicitudes por segundo en cada servidor de caché. Déjame agregar algo más de carga. Voy a abrir otro PowerShell y haré hincapié en otra instancia del cliente. Ahora, verá que subirá a más de mil a mil trescientos por servidor.

y ahora hagamos... De hecho, voy a... Entonces, abrí un símbolo del sistema aquí. Déjame iniciar sesión en el cuadro de Linux. ¡Ups! ¡Y lo siento! Empezamos PowerShell allí. Necesito importar las bibliotecas parciales del clon de NCache y haré la misma caché de demostración de estrés, así que voy a... Antes de hacer esto, como puede ver, estoy haciendo alrededor de trece a mil quinientos por servidor, agregue esto como un cliente basado en Linux hablando con el caché y ahora de repente tengo casi dos mil quinientas solicitudes por servidor.

Entonces, estoy haciendo unas cinco mil solicitudes por segundo en dos servidores. Como dije, puede agregar más y más carga y, a medida que maximiza esas dos cajas, agregará una tercera, luego agregará una cuarta. Entonces, es tan simple como eso y nuevamente esto es una simulación. Es una cosa real como una herramienta de prueba de esfuerzo. Entonces, esto es lo que tienes que tener en cuenta. Voy a continuar con el caché real ahora. Es un programa de prueba de estrés. Simplemente se coloca como una matriz de bytes. Creo que pone en 1k de datos. Agrega, actualiza, obtiene. Por lo tanto, simula cualquiera que sea su aplicación real y tiene parámetros que puede cambiar para ver cuál es la proporción de lectura versus escritura de la que hablábamos. Y, esta es una herramienta que damos con NCache, para que pueda probarlo en su propio entorno. pues a ver como NCache está funcionando antes de que pase mucho tiempo migrando su aplicación a él. Déjame pasar rápidamente. Creo que estoy ejecutando eso.

ASP.NET Core Almacenamiento de sesiones

Entonces, ahora que hemos visto cómo se ve un caché, cómo puede agregar más clientes y cómo puede agregarle más carga, es muy simple. Entonces, la forma más fácil de usar un caché es colocar sesiones en él. Y, para las sesiones, hay dos cosas que puedes hacer.

O simplemente puede usar un proveedor IDistributedCache. Digamos NCache Tiene uno. Tan pronto como especifique NCache como IDistributeCache, ASP.NET core comienza a usarlo para el almacenamiento de sesiones. Y, déjame mostrarte algo de eso. Tengo este ASP.NET core solicitud. Como puedes ver aquí. En mis servicios de configuración, estoy especificando Esto, estoy diciendo hacer NCache mi proveedor de caché distribuida. Entonces, tan pronto como hago esto, comienza y luego estoy usando sesiones estándar y estas sesiones estándar usarán IDistributedCache que ahora está usando NCache. Entonces, sea cual sea el proveedor de caché distribuido que tenga, eso es todo lo que tiene que hacer. Como puede ver, un cambio de código muy pequeño y toda su aplicación es automática, todas las sesiones se colocarán inmediatamente en un caché distribuido.

public IConfigurationRoot Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
	// Add framework services.
	services.AddMvc();
	//Add NCache as your IDistributedCache so Sessions can use it for their storage
	services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
	
	//Add regular ASP.NET Core sessions
	services.AddSession();	
}

Y, una de las cosas que hemos visto es cuando muchos de nuestros clientes, cuando almacenan sesiones en la base de datos y tienen problemas, para que conecten algo como NCache es instantáneo y el beneficio que ven, la mejora notable es instantáneo. La menor cantidad de esfuerzo la ganancia máxima está ahí. Porque, por supuesto, el almacenamiento en caché directo de la aplicación también está ahí.

Voy a omitir algunas porque creo... Por lo tanto, hay varias formas de especificar sesiones. Uno fue IDistributedCache, el segundo es que en realidad puede usar un proveedor de sesión personalizado que NCache también tiene y nuevamente todos estos son de código abierto. Luego, para el almacenamiento en caché de respuestas, nuevamente, haces lo mismo. Tu específicas NCache como el caché distribuido y se convierte automáticamente en el caché para el almacenamiento en caché de respuesta. No voy a entrar en más detalles.

ASP.NET Core Almacenamiento en caché de datos de aplicaciones

Quiero que toquen la base de este tema un poco más. Entonces, cuando realiza el almacenamiento en caché de datos de la aplicación, a diferencia de las sesiones, ahora debe realizar la programación API. A menos que esté haciendo el núcleo del marco de la entidad.

Así, por ejemplo, en el caso de NCache, nuevamente de código abierto, hay un proveedor principal de EF. Entonces, hemos implementado métodos de extensión para el núcleo de EF. Entonces, en realidad puedes enchufar NCache open source y use sus consultas centrales regulares de EF y al final puede decir desde el caché o desde la base de datos, algo, es solo un método de extensión que automáticamente comienza a almacenar cosas en caché. Le da control total sobre lo que desea almacenar en caché, lo que no desea almacenar en caché. Échale un vistazo. Es una forma realmente poderosa.

Si está haciendo EF core, que es lo que le recomiendo que haga. Creo que para cualquier ASP.NET core aplicación, toda la programación de la base de datos debe realizarse a través del núcleo de EF, especialmente porque el núcleo de EF es una arquitectura mucho mejor que el antiguo EF. Entonces, esa es una forma de hacerlo.

La otra es que realmente puedes hacer esto. Puede usar la API IDistributedCache o la interfaz que le brinda flexibilidad para no estar encerrado en una solución de almacenamiento en caché, pero tiene un costo. Es muy básico. Solo hay una entrada de obtención y eso es básicamente, bueno, también hay una eliminación. Eso es todo. Y, todas las cosas de las que hablamos, si no puedes mantener el caché sincronizado con la base de datos, todas esas cosas las pierdes. Entonces, si desea beneficiarse de todas esas funciones, debe ingresar a la API que realmente admite todas esas funciones. Y nuevamente, debido a que se comprometerá con un caché de código abierto, generalmente es más fácil hacerlo, pero el almacenamiento en caché directo de la aplicación, la API es muy sencilla, hay una clave y un valor. El valor es su objeto.

Mantener el caché actualizado

Ahora, permítanme pasar al tema de lo que le permite mantener el caché actualizado. La información realmente valiosa, ¿verdad? ¿A qué te dedicas?

Bueno, lo primero que hacen casi todos los cachés distribuidos es la caducidad. Haces expresión absoluta. Lo que sea que ponga en el caché, diga que lo elimine del caché dentro de cinco minutos. Entonces, es seguro mantenerlo en cinco minutos, creo que en cinco minutos soy el único que lo actualiza después de que otras personas lo hagan. Asi que, NCache lo tiene, todos los demás también lo tienen. Transitorio... hay una expresión deslizante para datos transitorios como sesiones y otros que después de que haya terminado de usarlo, si no se toca durante un cierto período de tiempo, digamos sesiones, cuando el usuario cierra la sesión después de 20 minutos de inactividad, la sesión caduca Entonces, sucede lo mismo. Caducidades, casi todo el mundo las tiene.

El siguiente es el caché sincronizado con la base de datos. Esta es una característica que le permite hacer que el caché monitoree su base de datos. Entonces, en realidad puedes... cuando estás agregando cosas a NCache, digamos, puede tener una dependencia de SQL que le permita NCache para supervisar. La dependencia de SQL es una característica de ADO.NET del servidor SQL que usamos. La dependencia de SQL le permite especificar una declaración de SQL o un procedimiento de almacenamiento que permita NCache para monitorear su base de datos del servidor SQL, ese conjunto de datos específico. Y, si ocurre algún cambio en ese conjunto de datos, el servidor SQL notifica NCache y cualquier caché elimina esos datos del caché o si combina esa sincronización con una función de lectura, entonces la vuelve a cargar. Entonces, supongamos que tenía un objeto de cliente que se almacenó en caché y era una dependencia de SQL y ese cliente cambió en la base de datos que son datos transaccionales de clientes, por lo que cambiará con frecuencia. Puede usar la lectura completa y recargar automáticamente en cualquier expresión o sincronización de base de datos.

Entonces ahora, de repente, su caché es responsable de monitorear los datos. Hay tres formas de hacerlo: la dependencia de SQL, la dependencia de DB y el sello son procedimientos almacenados de CLR. No voy a entrar en detalles. Puedes ir a nuestro sitio web y leerlo. Pero, de nuevo, lo más importante es que, si no tiene la sincronización de la memoria caché con la base de datos como característica, entonces está limitado a esos datos estáticos y de solo lectura. Y, luego, eso limita todo y nuevamente puede sincronizar este caché con la fuente de datos no relacional también.

Y, la tercera cosa es que puede tener un relacional... la mayor parte del tiempo va a estar almacenando en caché datos relacionales, que tienen relaciones de uno a muchos uno a uno. Entonces, digamos que un cliente tiene varios pedidos. Si elimina al cliente, los pedidos tampoco deberían permanecer en el caché porque tal vez lo haya eliminado de la base de datos. Entonces, si no hace eso, su aplicación tiene que hacer todo esto, pero hay un objeto de caché ASP.NET que tiene esta función llamada función de dependencia clave. NCache lo ha implementado que le permite tener una relación uno a muchos o uno a uno entre varios elementos de caché y que si una cosa se actualiza o elimina, la otra cosa se elimina automáticamente. Entonces, esas cuatro cosas combinadas le permiten asegurarse de que su caché se mantenga actualizada y consistente con la base de datos. Y esto es lo que le permite comenzar a almacenar datos en caché. Entonces, ese es el primer beneficio.

Lectura y escritura

La segunda es que si puede usar la lectura directa y la escritura directa, simplifica su aplicación.

Lectura completa, como dije, puede combinar la lectura completa para la recarga automática, que es algo que su aplicación no podría hacer si no tuviera la lectura completa. Y, escriba de nuevo, puede actualizar el caché y el caché puede actualizar la base de datos, especialmente si tiene un derecho detrás, nuevamente estamos hablando de rendimiento, ¿verdad? Por lo tanto, todas las actualizaciones deben realizarse en la base de datos. Bueno, y las actualizaciones serán lentas en comparación con las lecturas del caché. Entonces, ¿qué pasaría si pudieras delegar las actualizaciones al caché y decir que voy a actualizar el caché? ¿Por qué no vas y actualizas la base de datos por mí? Sé que es seguro porque vamos a trabajar en el modelo de consistencia final, que es de lo que se tratan los sistemas distribuidos, que sacrificas o te vuelves más indulgente con la consistencia y optas por el modelo de consistencia final. Lo que significa que, aunque en este momento no es consistente, debido a que el caché está actualizado, la base de datos no lo está, bueno, en unos pocos milisegundos se actualizará. Y, algunos datos que no puede permitirse hacer eso, pero muchos datos sí puede.

Entonces, al hacerlo justo detrás, de repente sus actualizaciones también son súper rápidas, su aplicación no tiene que incurrir en el costo de actualizar la base de datos. El caché lo hace porque es un caché distribuido y puede absorberlo como un lote y hay otros. Entonces, una vez que comience a hacer esto, eso significa que ahora puede almacenar en caché una gran cantidad de datos.

Agrupación de datos

Una vez que almacena datos en caché, más y más datos, su caché se vuelve tan rico como una base de datos, lo que significa que está almacenando en caché casi todos los datos.

Cuando almacena en caché casi todos los datos, el valor de la clave no es suficiente para encontrar cosas. Tienes que ser capaz de buscar cosas. AppFabric solía tener grupos y subgrupos, etiquetas llamadas etiquetas, por cierto, NCache open source tiene AppFabric envoltura. Entonces, aquellos de ustedes que obtuvieron AppFabric puede moverse a NCache como cosa gratuita. Por lo tanto, la agrupación le permite obtener datos fácilmente.

Cómo encontrar datos

La búsqueda de SQL le permite encontrar cosas como, dame todos mis clientes donde la ciudad es Nueva York. Entonces, ahora está haciendo consultas de tipo de base de datos en el caché. ¿Por qué? Porque su caché no contiene muchos datos.

Todo el paradigma está cambiando porque vas con más y más memoria. Una vez más, la base de datos es el maestro. Por lo tanto, el caché todavía solo lo tiene por un período de tiempo temporal.