1. Introducción a la Caché de GraphQL
Hoy, Matteo Collina hablará sobre la caché de GraphQL y cómo mejorar el rendimiento de tu puerta de enlace de GraphQL en cuatro veces. Utilizará Fastify, uno de los frameworks web más rápidos para Node.js, y Mercurius, el adaptador de GraphQL que se ejecuta sobre Fastify e integra con la biblioteca GraphQL JIT para una ejecución de consultas más rápida.
Hola a todos. Soy Matteo Collina y hoy voy a hablarles sobre la caché de GraphQL. Antes de comenzar, síganme en Twitter en matteocollina. Pueden encontrarlo en la diapositiva, así que aquí estoy. Hablo mucho sobre Node.js, JavaScript, GraphQL, código abierto, todas las cosas, así que no sé, puede que les resulte interesante. Hoy vamos a hablar sobre GraphQL, pero antes de comenzar, oh, una cosa más. Sigan mi boletín, Aventuras en Node-Land, node-land.dev. ¿Quién soy? Soy Matteo, formo parte del Comité Técnico de Dirección de Node.js, y soy Arquitecto de Software Principal en una empresa llamada NearForm. Échennos un vistazo, estamos contratando, haciendo mucho por GraphQL, así que si quieren, es una buena empresa. De todos modos, yendo un poco más lejos, cuando era niño en los años 90, sí, les estoy diciendo cuántos años tengo, estaba realmente, realmente, realmente impresionado por este espectáculo de David Copperfield, y no sé acerca de ustedes, pero siempre quise ser, me fascinaba la magia, ¿verdad? Entonces, y, ya saben, cómo hacer que las cosas desaparezcan, cómo hacer que las cosas, ya saben, vuelen, lo que sea. Es muy, muy interesante y me parecían muy entretenidos los espectáculos. Y de hecho, hay mucho trabajo duro detrás de la magia, ¿verdad? Así que en esta charla, vamos a hablar de magia y vamos a hacer que las cosas desaparezcan. De hecho, vamos a aplicar magia a GraphQL. Así que vamos a mostrar cómo mejorar el rendimiento de tu puerta de enlace de GraphQL en cuatro veces. ¿Cómo? Haciendo que las cosas desaparezcan.
Entonces, ¿cómo? Bueno, hablemos un poco sobre la herramienta del oficio. Necesitamos herramientas, ¿verdad? Necesitamos cosas que vamos a usar para esta pequeña demostración. Así que primero, vamos a usar Fastify. Fastify es uno de los frameworks web más rápidos para Node.js. Es muy fácil de usar. Es similar a Express, pero más moderno, más rápido. Tiene más características. ¡Todas las cosas que necesitarás. Es genial! Échale un vistazo. Vamos a usar Mercurius. Mercurius es el adaptador de GraphQL que puedes ejecutar sobre Fastify. Es genial. Mercurius ofrece algunas características interesantes que lo hacen único. En primer lugar, se integra con la biblioteca GraphQL JIT, para que podamos tomar tu consulta y hacer una compilación en tiempo real para tu consulta,
2. Herramientas, Experimento y Magia
Las herramientas discutidas incluyen una biblioteca llamada AutoCANON para pruebas de carga en JavaScript. El experimento involucra dos servicios federados por una puerta de enlace, que ofrecen objetos de usuario y publicación. Se utilizará el compilador en tiempo real y el módulo de caché para habilitar la caché del resolvedor. El servicio es un objeto de usuario simple con un ID y un nombre. Se realizarán pruebas de carga en vivo en hardware dedicado.
para que pueda ejecutarse mucho más rápido. Y así sucesivamente. También hace algunas cosas más como esa para rendimiento y razones de velocidad. Es genial. Así que échale un vistazo. Oh, también admite la federación completa, tanto como puerta de enlace como microservicio. Entonces, la última herramienta del oficio es una biblioteca llamada AutoCANON. AutoCANON es una herramienta que escribí hace mucho tiempo para realizar algunas pruebas de carga. Y puedes usar esto para omitir cosas en
JavaScript. Así que es para omitir pruebas de carga en
JavaScript. Es genial. Lo uso muchas veces. Estas son nuestras herramientas, ¿verdad? De acuerdo. Entonces vamos a usar estas. Tres cosas. Así que hablemos un poco sobre nuestro experimento. Tenemos dos servicios que están federados por una puerta de enlace. Y uno ofrece el objeto de usuario, y el otro ofrece el objeto de publicación. Y vamos a utilizar el compilador en tiempo real, y habilitaremos la caché para el resolvedor dependiendo de nuestros algoritmos. Así que podemos realizar múltiples experimentos, ¿verdad? Puedes verlo aquí. Puedes realizar múltiples experimentos. Y ver el impacto de este módulo de caché, ¿cómo se ve este módulo? Así que veamos dónde desaparecen o reaparecen las cosas.
¿Cuál es el servicio? Bueno, este es un ejemplo del servicio. Literalmente, es un objeto de usuario que tiene un ID y un nombre. Muy simple, ¿de acuerdo? No hay nada especial aquí.
Así que es hora de hacer un poco de magia. ¿Están listos para la magia? Hagamos que las cosas desaparezcan. ¿Cómo? Bueno, volvamos a nuestra terminal. Así que está conectado a mi servidor. Es
3. Mercurius Cache Repo and Experiments
En el repositorio de caché de Mercurius, tenemos pruebas de referencia, servicios de puerta de enlace para datos de usuario y publicaciones, y experimentos utilizando AutoCanon. Ejecutar el script sin caché realiza 3000 solicitudes por segundo. Con un TTL de cero segundos, aumenta 4 veces. Exploremos esto más a fondo.
en hardware dedicado. Así que voy a realizar pruebas de carga en vivo. ¡Oh, wow! Así que veamos mi repositorio de caché de. Todo esto está en el repositorio de caché de Mercurius. Y podemos ver que tenemos nuestras pruebas de referencia y esta es la puerta de enlace que acabo de mostrarte. Y tenemos nuestros servicios de puerta de enlace. Este es el de usuario y este es el de publicaciones. Ten en cuenta que estos servicios sirven todos losdata desde la memoria. Por lo tanto, no hay bases de datos involucradas. Son realmente rápidos. Y este es nuestro banco de pruebas. Entonces, ¿cómo evaluamos el rendimiento de las cosas utilizando AutoCanon? Básicamente, requerimos AutoCanon. Y luego tenemos nuestra consulta, y enviamos nuestra consulta como cuerpo con 100 conexiones concurrentes. Eso es todo. Y luego hacemos varios experimentos utilizando nuestro script de banco de pruebas. Entonces, en nuestro script de banco de pruebas, puedes ver que estamos ejecutando todos los servicios más varias cosas. Varios ejemplos, uno sin caché, uno con un tiempo de vida de cero segundos y uno con un tiempo de vida de un segundo y uno con un tiempo de vida de 10 segundos. Así que vamos a ejecutar este script. Primero que nada, este es nuestro básico, este es nuestro control, ¿verdad? Es un modo de puerta de enlace. Algo donde no vamos a cachear nada. Así que hemos hecho esto, ¡y vaya! Realiza 3000 solicitudes por segundo. Bueno, parece rápido o no, depende de lo que quieras hacer. La latencia es buena, sin embargo. Así que estoy bastante contento con los resultados. Ahora, con un TTL de cero segundos, ¡vaya! ¿Cómo? Simplemente se multiplicó por 4. No estoy haciendo ninguna caché. Es un tiempo de vida de cero segundos. Simplemente lo activo y se multiplica por 4. Y, ¡vaya! Todavía 4 veces. ¿Cómo es esto posible? ¿Cómo funciona esto?
4. Caching and Deduplication
Nuestro punto de referencia tiene una latencia P99 de 80 milisegundos, lo que resulta en aproximadamente 3000 solicitudes por segundo. Al habilitar la caché con un tiempo de vida de 0 segundos, podemos reducir la latencia a 18 milisegundos y aumentar el número de registros por segundo y el rendimiento en 4 veces. El gráfico de llamas muestra que la mayor parte del tiempo se dedica ahora a la caché, gracias a la deduplicación. El diagrama del bucle de eventos de Node.js proporciona información sobre el flujo de ejecución y el tiempo de bloqueo entre C++ y JavaScript, que se utiliza para la deduplicación mediante el cálculo de una clave de caché.
OK, dejemos esto ejecutándose. Explicaremos esto en un momento. Entonces, nuestro punto de referencia tiene una latencia P99. Eso es lo que quieres medir para una latencia de 80 milisegundos. Mientras que una solicitud por segundo te da más o menos 3000 solicitudes por segundo.
Sin embargo, también puedo crear gráficos de llamas. ¿Qué es un gráfico de llamas? Bueno, es una representación de dónde se está gastando nuestro tiempo de CPU. Más específicamente, todo ese tiempo se está gastando en hacer solicitudes HTTP. Por cierto, si no has visto mis charlas sobre undici y Node.js, por favor échales un vistazo porque puedes acelerar bastante tus llamadas HTTP.
Pero el resultado es que la gran mayoría del tiempo se gasta haciendo HTTP. Entonces, bueno, ¿qué podemos hacer? Necesitamos reducir el HTTP. Sí, ¿cómo podemos mejorar esto? Bueno, simplemente haciéndolo un tiempo de vida de caché de 0 segundos, podemos reducir la latencia a 18 milisegundos y multiplicar por 4 el número de registros por segundo y el rendimiento. ¡Vaya! Esto es una gran mejora sin tener ninguna caché en absoluto. Cero caché. No es caché en absoluto. Simplemente habilitamos la caché. Bueno, y si habilitamos la caché, no mejora mucho. Bueno, ¿cómo es posible? Bueno, este es el gráfico de llamas de nuestra puerta de enlace ahora. Y como puedes ver en el medio, la solicitud HTTP que estaba allí antes ha desaparecido. Y ahora tenemos en el medio un gran bloque de tiempo que se gasta haciendo la caché, vale. Literalmente, ahora la parte inferior es el sistema de caché. Entonces, ¿pero a dónde fue la llamada HTTP? ¿Dónde desapareció? Bueno, lo que estamos haciendo, estamos haciendo deduplicación, que es la estrategia clara que hará las cosas increíblemente más rápidas, especialmente en el lado gráfico. Así que volvamos y hablemos un poco sobre el bucle de eventos de Node.js. Probablemente hayas visto este diagrama sobre Node. Esto es genial porque has visto que la solicitud llega y sabes que tienes un evento, va a la cola de eventos, se procesa, y luego esto genera más actividad asíncrona. Lo que no has visto es este diagrama. Este diagrama es una presentación diferente del mismo bucle de eventos exacto. Sin embargo, lo muestra desde el punto de vista de la función JavaScript que se está ejecutando. Entonces, cuando el bucle de eventos está en ejecución, está esperando algo, está esperando, ¿verdad? Esto es, a la izquierda y a la derecha, el bucle de eventos está esperando. Luego, cuando ocurre un evento, llama a C++, llama a JavaScript, que normalmente programa algún next-tick o algunas promesas, luego vuelve a C++, que a su vez inicia las promesas y la ejecución de next-tick, y finalmente, una vez que todo eso se ha hecho y se ha resuelto, vuelve y cede el control al evento. Todo el tiempo que lleva entre medias, desde este punto de inicio del C++ hasta el final, es el tiempo en el que el bucle de eventos está bloqueado. Entonces, para hacer la deduplicación de la solicitud, lo que estamos haciendo es, cuando estamos recibiendo nuestra función de resolución, podemos calcular una clave de caché, ¿vale? Y con esa caché
5. Módulo AsyncCacheDedupe
El módulo AsyncCacheDedupe te permite calcular la misma clave de caché para un resolvedor y evitar ejecutarlo varias veces. Automáticamente almacena en caché los resultados y proporciona una forma rápida y eficiente de evitar cálculos innecesarios.
clave, podemos crear una promesa coincidente. Entonces, y luego podemos, ya sabes, completar nuestra ejecución, ¿verdad? Sin embargo, cuando llega una ejecución de seguimiento, podemos calcular exactamente la misma clave de caché y obtener la promesa que colocamos allí antes, que aún puede estar pendiente. Sin embargo, no necesitamos ejecutar el mismo resolvedor dos veces. Solo podemos ejecutarlos una vez, ¿verdad? Es bastante genial. Podemos evitar muchos cálculos de esta manera. Esto es lo que hace este módulo. Se llama AsyncCacheDedupe. Creas una nueva caché donde defines algunos métodos en ella y que son asíncronos, y luego automáticamente almacena en caché los resultados. Y podemos tener, puedes tener un TTL, pero automáticamente deduplica y almacena en caché el resultado. Es fenomenal y es muy rápido. Entonces puedes usar esto en todos los demás lugares donde quieras usar el sistema, ¿verdad? Bueno, en primer lugar, pero la pregunta ahora es ¿cómo podemos calcular una buena clave de caché? Porque queremos, para usar este módulo, necesitamos proporcionar una clave de caché y ¿qué es una buena, cómo podemos
6. Implementación de Resolvedores y Caché
Al implementar un resolvedor en Node.js, puedes usar cuatro argumentos: root, arguments, context e info. Al combinar la anatomía del resolvedor, el objeto info y otros parámetros, puedes calcular una clave de caché para cada resolvedor de GraphQL. Sin embargo, las cachés en proceso son problemáticas y el uso de Redis como una caché compartida entre nodos puede generar problemas de rendimiento.
¿Cómo obtenemos una buena clave de caché? Bueno, veamos la anatomía de nuestro resolvedor. Cuando implementas un resolvedor en
Node.js, puedes tener cuatro argumentos. Tienes el root, tienes los argumentos, tienes el contexto, que es el objeto actual, pero luego tienes los argumentos para el resolvedor, el contexto que puede incluir tu solicitud de
Node.js, respuesta, conexiones de base de datos, todas las cosas, y luego el objeto info que incluye la definición de la consulta que estás calculando. Bueno, ten eso en mente y espera un segundo. Ahora, lo que puedes hacer es tomar un objeto arbitrario y convertirlo en JSON, ¿verdad? Puedes llamar a JSON.stringify. Si haces eso, dependiendo del orden de las propiedades, obtendrás diferentes JSON. Sin embargo, hay un módulo llamado save-stable-stringify, que independientemente del orden de las propiedades, siempre generará el mismo JSON. Entonces, lo que podemos hacer es usar este módulo y combinarlo con la anatomía del resolvedor, el info, los datos en el objeto info, el root y todas esas cosas para crear una clave de caché, un hash para un hash arbitrario para ese resolvedor específico.
¿Cómo se implementa esto? Bueno, como puedes ver aquí, es bastante simple. Navegamos por el objeto info para obtener la selección, la selección actual del campo, y luego creamos un objeto que incluye el objeto resuelto actual, los argumentos, los campos y algunos parámetros más. Es genial, ¿ves? Podemos calcular una clave de caché para cada resolvedor de GraphQL. Esto es lo que llamamos TTL de cero segundos. Estamos deduplicando todos los resolvedores que acceden a tus datos. Agregar caché no mejora mucho aquí porque los servicios objetivo son en su mayoría muy simples. No requieren mucho tráfico. Lo siento. No requieren muchas CPUs para calcular. No tienen una base de datos. No tienen nada. Sin embargo, agregar más caché cambiará en caso de que necesites más. Agregar más tiempo aquí mejorará tu rendimiento si los servicios objetivo no son lo suficientemente rápidos o son lentos o algo así. Bueno, todo esto es muy bueno, ¿verdad? Pero las cachés en proceso son problemáticas. Entonces, realmente no podemos aumentar demasiado el tiempo porque todo está en proceso, ¿verdad? Si todo está en proceso, si los datos expiran en mi nodo, no están expirando en el otro nodo. Entonces, ¿cómo podemos implementar eso? Bueno, una de las buenas soluciones es usar algo como Redis para implementar un estado compartido, una caché compartida, entre todos los nodos. Sí, pero lo intentamos y lo implementamos, y no funcionó. Y no funcionó, principalmente porque, ya sabes, en nuestra prueba de referencia, teníamos cien consultas gráficas por segundo, cada una de las cuales invocaba 20 resolvedores. Y esto implica que, ya sabes, si quieres obtener esos datos de la caché, son de doscientos a dos mil Gets de Redis por segundo. Y desafortunadamente, el tiempo de ida y vuelta de Redis es de 0.5 milisegundos.
7. Redis Pipelining y Rendimiento
Hemos resuelto el problema del bloqueo sin conexión de cabeza con el auto-pipelining, una técnica que agrupa múltiples comandos en un solo pipeline de Redis, reduciendo el tiempo de ida y vuelta de la red. Esta lógica en producción ha mejorado las solicitudes por segundo en 100 veces y ha ampliado Redis en 15 veces. Redis maneja el tráfico sin problemas. Sin embargo, nombrar cosas e invalidaciones de caché siguen siendo desafíos.
Pero el tiempo real de ida y vuelta es de 15. Así que no se puede hacer mucho. Necesitamos paralelizar estos Gets de Redis, ¿verdad? Entonces, tal vez puedas usar un grupo de conexiones o, no sé. Bueno, hay algo mejor. Bueno, en realidad ya he resuelto este problema. Sí, es con esta figura. De todos modos, echa un vistazo a esta charla que di en RedisConf 2021. Explico cómo resolver el problema del bloqueo sin conexión de cabeza con el auto-pipelining. Entonces, básicamente, es una técnica que hemos inventado para... Bueno, hemos aplicado al cliente de Redis que permite agrupar múltiples comandos que ocurren en la misma iteración del bucle de eventos en un solo pipeline de Redis. De modo que los enviamos como un lote, asegurándonos de reducir el tiempo de ida y vuelta de la red en el servidor. Es genial, y funciona maravillosamente, y puedes realmente acelerar el acceso a Redis. Pero esto es en realidad lo mismo que hacíamos antes con el sincronismo. Así que, es tortugas todo el camino hacia abajo. Días felices.
Así que, tenemos toda esta lógica en producción. Es importante decir que este código en producción nos está dando una mejora de 100 veces en términos de número de solicitudes por segundo. Y tiene un factor de expansión de 15 veces en Redis. Así que, para cada consulta compleja que recibimos en promedio, estamos haciendo 15 Gets de Redis con diferentes claves de caché para verificar si las cosas funcionan como nos gustaría. Es bastante genial, ¿verdad? Pero también es bastante aterrador. Por cierto, Redis ni siquiera parpadea un ojo, ni siquiera parpadea un ojo. Está perfectamente bien con todo este tráfico, así que no nos importa. Redis es increíble, por cierto. Usa Redis. Más Redis para todos.
Así que, eso es lo que tenemos en la vida real. Esta técnica ha sido un salvavidas fenomenal recientemente. Pudimos manejar un pico enorme de tráfico sin siquiera parpadear. Así que, sí, échale un vistazo. Es genial. Sin embargo, hay dos cosas en la ciencia de la computación, ¿verdad?
8. Invalidación de Caché y Conclusión
No hemos discutido la invalidación de caché, pero es un tema fundamental. Aunque se me ha acabado el tiempo, estamos trabajando activamente en la implementación de este módulo. Pronto podrás invalidar la caché localmente y en Redis. Mantente atento a las actualizaciones en Twitter y en mi boletín. ¡Gracias por ver!
Uno es nombrar cosas, y el otro es la invalidación de caché. Oh, vamos, está realmente mal, ¿verdad? Porque no hemos hablado de cómo invalidamos la caché, y este es uno de los temas fundamentales. Sin embargo, casi hemos llegado a los 20 minutos, así que se me ha acabado el tiempo. Así que, no los voy a cubrir en esta charla. Estoy bromeando. No hemos terminado de trabajar. No hemos terminado la implementación de este módulo. Pero en realidad estamos trabajando en esto. Así que, en realidad, los añadiremos a AsyncCache.JDube pronto. Por lo tanto, podrás invalidar la caché tanto localmente como en Redis más temprano que tarde. Así que, échale un vistazo, porque estaremos atentos a mis noticias en Twitter y en mi boletín, porque habrá algunos buenos anuncios en las próximas semanas. Con eso, solo quería decirte gracias. Como dije, soy Matteo Collina. Soy el Arquitecto Principal de Software en NearForm. Puedes encontrarme en Twitter, en Matteo Collina. Por favor, hazme cualquier pregunta que quieras en Twitter, y estaré muy feliz de responder tan pronto como pueda. Así que gracias por ver esta charla. ¡Adiós!
Comments