Haciendo que mi API de Node.js sea súper rápida

Y suficiente hablando de mí, comencemos a hablar sobre el rendimiento, que es una de mis cosas favoritas de las que me gusta hablar. Y hoy vamos a hablar sobre cómo mejorar el rendimiento en la capa de su API. Vamos a revisar, vamos a analizar esas áreas, vamos a analizar la base de datos. Vamos a analizar la serialización y deserialización de sus JSON. Vamos a hablar sobre el registro. Puede parecer trivial, pero eso puede afectar su rendimiento. El marco web que elijas y el almacenamiento en caché.

Comencemos con el trabajo de la base de datos. En primer lugar, antes de adentrarnos en cosas relacionadas con JavaScript, hay algunas cosas que debes tener en cuenta para cualquier tecnología con la que trabajes, para cualquier lenguaje de programación. En primer lugar, por supuesto, tus consultas a la base de datos deben estar optimizadas. Todos los índices deben ser muy eficientes y permitir una recuperación y operaciones eficientes muy rápidas. Y luego debes denormalizar tus datos. ¿Qué significa esto? Si tienes una tabla con 50 columnas y solo necesitas tres, no recuperes las 50 completas. Recupera solo lo que necesitas, por ejemplo. Y guarda los datos de manera eficiente. No guardes cosas ineficientes. Y luego debes pensar en soluciones en la capa de la base de datos. Pueden ser réplicas de lectura-escritura que pueden mejorar tu rendimiento. Trabajar con un conjunto de réplicas, emparejar las bases de datos que lo admitan y fragmentación.

Pero estamos en una conferencia de Node.js, y después de hablar un poco sobre consejos genéricos, vamos a adentrarnos en cosas de Node.js. ¿Cómo puedo mejorar el trabajo de la base de datos en mi aplicación Node.js? Cuando comenzamos a trabajar con Node.js, comenzamos con el primer tutorial que todos hacemos: Node.js, Express y Mongoose. Empecemos con eso y hagamos una evaluación para ver cómo funciona. Al hacer una evaluación, debemos tener en cuenta las siguientes cosas. En primer lugar, las medidas más importantes son la latencia. Debes analizar el percentil 99, no el promedio. Porque cuando tienes un contrato con un tercero y les dices que todas mis solicitudes son más rápidas que esto, debes proporcionarles el percentil 99 de la latencia, no la mediana ni el promedio. Eso es realmente importante. En segundo lugar, medir el rendimiento. Para medir el rendimiento, hay dos cosas importantes que debemos tener en cuenta. Primero, el promedio de solicitudes por segundo, y luego las solicitudes totales. Estas medidas te darán una buena idea de cómo está mejorando tu rendimiento.

Ahora vamos a comparar Mongoose y Native Mongo Driver. Escribí un servidor que funciona con Mongoose, y ese servidor expone una solicitud POST que envía un objeto persona, algo muy simple. El código no es algo realmente interesante. Estamos construyendo un servidor con Express y Mongoose, creando un esquema de Mongoose con varios parámetros, y luego esa es la función que vamos a evaluar. POST, y luego creamos un nuevo objeto persona y lo guardamos, como puedes ver aquí. El código de Native Mongo Driver va a hacer exactamente lo mismo. Una solicitud POST, que también envía un objeto persona, porque queremos comparar manzanas con manzanas. Cuando hacemos una evaluación de rendimiento, queremos comparar cosas que hacen lo mismo. Aquí está el código que se ejecuta con Native Mongo Driver. Como puedes ver, esto también hace una inserción en la base de datos.

Genial. Estos son los resultados que obtuvimos con Mongoose. Puedes ver que si observamos las solicitudes promedio por segundo, estamos alrededor de 5700 solicitudes, y las solicitudes totales son alrededor de 64,000, y el percentil 99 es de 4 milisegundos, pero al usar Mongo Driver, podemos ver que las cosas mejoraron enormemente. Podemos ver que las solicitudes promedio por segundo aumentaron a 9500, lo cual es mucho. Es más del 30%, creo. El percentil 99 es mucho más pequeño, un 50% menos, y pudimos atender, en el tiempo de la evaluación, alrededor de un 30,000% más de solicitudes. Como puedes ver, si lo vemos en un gráfico, Native Mongo Driver tiene un rendimiento mucho mejor que Mongoose.

Vamos a comparar las solicitudes totales y las solicitudes promedio por segundo, y verás que es mucho mejor. La pregunta es, ¿por qué es mucho mejor? ¿Por qué tiene un rendimiento mucho, mucho mejor? En resumen, Mongoose es una herramienta de un tipo llamado ORMs, y generalmente cuando usas esas herramientas, están mucho más allá, te brindan una capa de abstracción sobre tu base de datos que te ayuda, pero agrega una sobrecarga de serialización, desreferenciación, a veces consultas ineficientes, por lo que generalmente la mayoría de los ORMs perjudican tu rendimiento. Son buenos para aplicaciones de baja escala, mediana escala, pero cuando vas a alta escala, generalmente comienzas a trabajar nativamente con tu base de datos, ya sea Mongo, SQL u otro. Ahora hablemos un poco sobre las pool de conexiones. ¿Qué son las pool de conexiones?

Cuando trabajamos con una base de datos, queremos tener un grupo de conexiones a la base de datos que estén disponibles, cada una de ellas puede ejecutar una consulta y, cuando termina, vuelve al grupo esperando a otro cliente, otra utilidad para usarla. Si comparamos los resultados cuando trabajamos con una pool de conexiones a nuestra base de datos y trabajamos sin una pool de conexiones, hagamos esa comparación nuevamente, estamos comparando manzanas con manzanas y estamos comparando el mismo servidor, y ese servidor está realizando esa solicitud POST del que hablamos. Entonces, cuando no tenemos una pool de conexiones, veamos el rendimiento. Vemos que las solicitudes promedio por segundo son alrededor de 8100 y las solicitudes totales son aproximadamente 81,000, wow, tenemos un factor de multiplicación de 10 aquí, y luego puedes ver que si optimizamos nuestra pool de conexiones, haciéndola más grande, más eficiente para nuestras necesidades de máquina, para nuestro entorno, entonces logré obtener alrededor de un 15 a un 20 por ciento de mejora. Puedes ver que las solicitudes promedio aumentaron a 9500, la cantidad total de solicitudes está un poco cerca de las 100,000 solicitudes, y si lo vemos con gráficos, entonces podemos ver que cuando optimizamos nuestra pool de conexiones, el rendimiento aumentó un 20 por ciento. Así que estamos viendo las solicitudes totales, las solicitudes promedio y también la latencia se redujo. Otra cosa importante a tener en cuenta es trabajar con una pool de conexiones y asegurarse de optimizarla.

Muy bien, ahora hablemos sobre el análisis eficiente de JSON y el stringify. Entonces, cuando trabajamos con una solicitud HTTP, cuando estamos utilizando una solicitud POST, cuando estamos implementando una solicitud POST, estamos deserializando la solicitud HTTP, el cuerpo de la solicitud, y cuando estamos implementando una solicitud GET, estamos serializando el cuerpo de la respuesta y devolviéndolo al servidor. Pero la serialización y deserialización son operaciones síncronas que siempre bloquean el bucle de eventos. Espero que tengas en mente la arquitectura de Node.js, que estés familiarizado con el bucle de eventos que procesa actividades y trabajo, y cuando tenemos una operación síncrona que es larga, la bloquea. Y la serialización y deserialización son exactamente esas cosas.

Ahora voy a tomar el mismo servidor y reemplazar la serialización de la respuesta con otra biblioteca llamada FastJSONStringify y veamos qué obtenemos aquí. Si vamos a trabajar, estoy implementando una API GET aquí, y estoy trabajando con Express y estoy usando Express.json, como puedes ver, el serializador predeterminado, y esa es una función que estoy probando. Y Express.json se ejecuta cuando hacemos result.json. OK, estamos haciendo find one y devolviendo la respuesta. Ahora agregué un poco de mi propia adición. Creé otro servidor. Usé FastJSONStringify. Esa biblioteca necesita recibir un esquema, así que le di un esquema, como puedes ver aquí, y creé un middleware propio. Reemplacé el serializador predeterminado de Express con mi middleware personalizado, y ese middleware utiliza FastJSONStringify, ese middleware personalizado. Y si comparamos esos resultados, veremos que eso también me dio alrededor de un 15% de mejora en mi servidor Express. Por ejemplo, la cantidad promedio de solicitudes aumentó a más de 10,000 por segundo y también las solicitudes totales, esas aumentaron en aproximadamente un 50%. Pude atender un 50% más de solicitudes, por lo que el rendimiento aumentó y también la latencia es menor. FastJSONStringify me dio la ventaja en el rendimiento aquí. Pero sabes, esa no es la única biblioteca que existe. Hay más bibliotecas que existen y realmente te recomiendo buscar otros serializadores, comprender qué es más eficiente al realizar tus pruebas y tal vez considerar hacer esta capa de serialización y deserialización de tu contenido de solicitud y respuesta más eficiente.

Muy bien, hablemos un poco sobre el registro. En un mundo perfecto, nuestro sistema funciona perfectamente, pero en realidad, generalmente hay muchos problemas, las aplicaciones se bloquean, hay errores aleatorios, data falta, por lo que el registro siempre nos ayuda a debug, y el registro es algo que todos necesitamos en nuestras aplicaciones. Pero el registro puede causar una degradación del rendimiento.

Así que estaba, o lo siento, no puede, siempre causará una degradación del rendimiento. Así que estaba comparando un servidor con una solicitud POST que es, ya sabes, sin registros, y otro servidor que solo tiene una línea de registro, y eso es todo. Y mira lo que tenemos aquí. Si sin registro, la cantidad promedio de solicitudes por segundo es de alrededor de 9600, entonces cuando tenemos solo una línea de registro, el rendimiento disminuye alrededor del 15%. Mira aquí. La cantidad promedio de solicitudes por segundo es de alrededor de 8400. En los últimos resultados, pudimos atender alrededor de 100,000 solicitudes en el total de referencia. Ahora podemos atender alrededor de 93,000. Eso es como un 10% de degradación.

Entonces, cuando pienses en el registro, eso también es algo que debes tener en cuenta para elegir una biblioteca que sea eficiente en cuanto al rendimiento. Diferentes bibliotecas de registro que son populares en este momento son, digamos, Winstone, PinoJS y otras bibliotecas que tomé para comparar en mi referencia son Banyan y Log4j. Entonces, cuando miramos el panorama general, veremos que PinoJS es la biblioteca que actualmente te brinda el menor sobrecosto en tu código, lo que significa que eso es, por ahora, para mis comparaciones, la biblioteca de registro más eficiente en cuanto al rendimiento, y te daría los mejores resultados sin perjudicar el rendimiento de tu aplicación. Entonces podemos ver eso en la cantidad promedio de solicitudes por segundo, y también podemos verlo en el total de solicitudes, ya que puedes ver que Pino, el servidor con Pino pudo atender la cantidad de solicitudes que está más cerca de un servidor sin registros. Entonces, si concluimos eso, si estás pensando en el rendimiento y estás pensando en la eficiencia del rendimiento, elige PinoJS en lugar de otras bibliotecas. Eso puede cambiar, pero por ahora, es la biblioteca de registro más eficiente que existe. Otro consejo que me gustaría darte, que es importante, es, ya sabes, cuando hacemos registros, tenemos muchas concatenaciones de cadenas, pero la biblioteca de registro debe manejar esta concatenación de cadenas. No hagas la concatenación de cadenas en tu aplicación tú mismo. Como puedes ver en el ejemplo que está abajo, porque parece insignificante para ti. Lo que realmente está sucediendo detrás de escena es que si mi nivel de registro por ahora es como error, entonces esa concatenación de cadenas no se realizará por la biblioteca de registro. Si lo hago yo mismo, siempre sucederá. Entonces parece insignificante, pero realmente en aplicaciones grandes, aplicaciones complejas, esas cosas se suman. Siempre prefiere que la construcción de cadenas se realice con una interfaz adecuada para eso desde la biblioteca de registro, que recibe parámetros. Bueno, ahora en realidad estaba haciendo toneladas de ejemplos con Express. Entonces la pregunta es si podemos hacer algo más, tal vez no Express. Quiero decir, Express, para ser honesto, es un poco antiguo. No sé si lo sabes, pero la versión de lanzamiento de Express es la versión 4, y eso fue lanzado en 2014. Eso fue hace bastante tiempo.

Sé que el primer tutorial es sobre Express, pero tenemos muchos otros jugadores interesantes en el mercado. Tenemos Nest, tenemos Festify, tenemos Koa. Entonces, tal vez si vamos a elegir algo más, eso puede darnos una ventaja que necesitamos.

Así que estuve comparando Express, Festify y NestJS, y por supuesto, al hacer comparaciones, es muy importante, como dijimos, comparar manzanas con manzanas. Si estoy comparando una solicitud GET que guarda un objeto, un objeto de persona con tres parámetros, tengo que hacer lo mismo con Festify y con Nest, el code tiene que ser el mismo. Y en la base de datos, si estamos haciendo una inserción, necesitamos hacer una inserción en el otro framework. Bien, veamos qué obtenemos. Así que cuando trabajamos con Express, pudimos atender alrededor de 95, 94 cientos de solicitudes por segundo, y el rendimiento es de alrededor de 100,000 solicitudes por segundo. La latencia es de dos milisegundos. Nest nos dio algo más lento. El promedio de solicitudes por segundo es de 5,400. Pudimos atender alrededor de 60,000 solicitudes, pero Festify actualmente nos dio los mejores resultados. Pudimos atender, como puedes ver, cerca de 200,000 solicitudes por segundo. La latencia se redujo a un milisegundo. Así que Festify nos dio la ventaja de performance, y aquí está la comparación. Si lo vemos visualmente, entonces veremos que Nest estaba funcionando alrededor de un 50% más lento que Express, pero Festify actualmente es aproximadamente el doble de rápido que Express, al menos según mis comparaciones. Podemos ver eso con múltiples mediciones que se realizaron. En realidad, en la mayoría de las empresas, es un poco difícil, digamos, refactorizar tu microservicio code. Por lo general, obtienes un code en el que necesitas trabajar, y en ese caso, bueno, tienes qué hacer. Puedes hacer que tu DB funcione de manera más eficiente. Puedes usar caché. Hablaremos sobre la caché de inmediato. Puedes mejorar la serialización, pero si tienes la posibilidad de elegir un framework web más eficiente, o si tienes la posibilidad de comenzar un nuevo microservicio con un framework web diferente en tu organización, realmente deberías considerarlo, porque eso puede darte un impulso y una ventaja reales. Y, como dijimos, Festify actualmente es el framework que tiene el mejor rendimiento entre todos los frameworks que he analizado.

Ahora, espero que no te sorprendas, pero vamos a hablar de la última cosa, que es el almacenamiento en caché. Para eso, había implementado un servidor que está autenticado con JWT, y la validación del token se realiza en la autenticación JWT en ambos lados. El cliente debe validar el token y el servidor también debe validar el token. Pero te daré un adelanto. Agregar autenticación JWT al servidor ha causado una disminución del rendimiento de una manera realmente mala. Veamos eso. Entonces, este es el middleware que agregué y para cada solicitud que hago, verifico el JWT del token. Bueno, el código no es realmente complicado aquí.

Este es el middleware que se utiliza. Y mira lo que sucedió. Así que, de una situación en la que estábamos atendiendo alrededor de 100,000 solicitudes en total, pasamos a alrededor de 15,000. Eso es como un 80% de degradación. Eso es enorme. Entonces, sí, las cosas y también la latencia, ya sabes, aumentaron a alrededor de 10 milisegundos. Fue masivo. Para resolver el problema, bueno, lo mejor que se puede hacer aquí para solucionar el problema es utilizar el almacenamiento en caché.

Estos son los resultados cuando no tenemos authentication. Eso es lo que obtuvimos. Sabemos que alrededor de 9,500, 9,600. Esos son los resultados que obtuvimos cuando agregamos la authentication. Verás que el promedio de solicitudes por segundo bajó a 2,500. Y cuando usamos el almacenamiento en caché, puedes ver que estamos muy cerca de lo que teníamos al principio. Sin la authentication, teníamos alrededor de 95 solicitudes, 9,500 solicitudes por segundo. Aquí tenemos 9,100. Eso es bastante cercano. Y también podemos ver que la latencia vuelve a ser de 2 milisegundos, el percentil 99. Eso es lo que estamos observando todo el tiempo. Y aquí puedes verlo visualmente. Cuando agregamos el almacenamiento en caché, está cerca de lo que tenemos cuando no hay authentication en absoluto. Entonces, agregar almacenamiento en caché a la capa de authentication resolvió el problema.

Podemos verlo con diferentes mediciones. Y podemos ver que la latencia ha vuelto a ser la misma. Ese era el cuello de botella y se resolvió el problema de rendimiento.

Tipos de caché que podemos hacer. Podemos hacer caché en memoria, pero en realidad no se recomienda. Porque la mayoría de las veces, si estás haciendo caché en memoria, no puedes ejecutar tu servicio en múltiples réplicas. No puedes crear múltiples instancias de tu servicio. Así que no se recomienda. Es mejor utilizar tecnologías como Redis. Redis tiene otros competidores como EDCD, por ejemplo. Pero es mejor utilizar tecnologías como estas. Y en ese caso, la caché es distribuida. Todos tus servicios están accediendo a la caché. Y es mucho mejor. Bien, lo que debes cachear. O qué se recomienda cachear. Consultas a la DB, elementos de criptografía. Por ejemplo, vimos JWT. Solicitudes HTTP de terceros. Esos tipos de cosas. Eso mejorará mucho tu rendimiento. Bien. Estamos al final de esto. Lo cual es bueno. Así que hagamos un resumen rápido de todo lo que hemos visto. Optimiza las consultas a la DB. Asegúrate de tener una arquitectura eficiente de la DB como hemos hablado. Es mejor trabajar con controladores nativos de la DB en escalas grandes. Ten la capacidad de optimizar tu grupo de conexiones. Cachéalo cuando lo necesites.

Y también asegúrate de elegir un marco web eficiente para el rendimiento. Debes elegir bibliotecas de registro eficientes. Y elige un serializador eficiente. Eso fui yo. Espero que lo hayas disfrutado. Y puedes seguirme en esos enlaces. Y muchas gracias.

¿En qué áreas deberíamos mejorar el rendimiento en nuestros servicios? Y aunque Columbia es una gran respuesta. Mucha gente lo está. Definitivamente. Pero la gente ha mencionado cosas como la latencia, el tiempo de solicitud, el rendimiento, la optimización de consultas. Entonces, ¿qué piensas? ¿Estos resultados te sorprenden? ¿Qué responderías a una pregunta así? ¿Qué respondería yo? Bueno. Primero que nada, podría ser que el problema no esté en tu aplicación. Tal vez sea un problema ambiental. Tal vez si la máquina se está ejecutando en la nube, haya problemas con otro contenedor. Que esté cortando los recursos de la máquina. Así que asegúrate de no estar en esa situación. Por cierto, creo que optimizar tu código es algo que haces un poco menos. Primero debes revisar tu base de datos. Y ver si necesitas optimizar tus consultas. Y también debes ver si tu grupo de conexiones está optimizado. Y también debes ver el nivel de registro. Por cierto, nunca ejecutes aplicaciones de producción en un nivel de registro en modo malo. Siempre ejecútalas en modo de error o advertencia, porque el registro puede afectar mucho a tu aplicación. Así que antes de comenzar a optimizar tu código JavaScript, hay muchas cosas que puedes hacer.

Fantástico. Esa es una gran respuesta. Pero también quiero pasar a las preguntas de las personas que sintonizaron y tienen preguntas para ti. Así que pasemos a esas preguntas. Y de hecho, creo que es una buena transición hacia lo que preguntó la primera persona.

¿Cuál es el mayor cuello de botella de rendimiento? ¿La tecnología? ¿O los humanos en el proceso que implementan la tecnología? ¿Qué crees que es el mayor problema para el rendimiento? Bueno, la tecnología puede tener un impacto. Por ejemplo, creo que Node.js tiene un rendimiento mucho mejor que otros lenguajes como Java. Debido a su único modelo de E/S no bloqueante y bucle de eventos. Pero creo que como humanos, también debemos asegurarnos de dividir nuestro software en una buena arquitectura. Debemos tratar de dividir nuestro software y microservicios de manera que pueda escalar. Entonces, podría ser que los humanos sean capaces de... Los humanos son el mayor problema, en mi opinión. Los humanos son el mayor problema. Eso es. Como ha llegado a... Capa siete. Sí, como el trabajo de base de datos que no es correcto. El trabajo de registro que no es correcto. La arquitectura de microservicios que no está escalando. El caché que no se utiliza. Por eso necesitamos dar la bienvenida a nuestros señores de las máquinas. Ahora es el momento.

Genial, esa es una gran respuesta. Entonces, ¿qué recomiendas para aislar los cuellos de botella de rendimiento en aplicaciones de Node.js? ¿Cuál es tu mejor consejo? ¿Cuál es mi mejor consejo? Por cierto, recomiendo que si comienzas un nuevo proyecto, intentes buscar nuevos marcos. No vayas a usar, no sé, Express que todos están usando. Intenta usar nuevos marcos que te brinden esa ventaja de rendimiento. Y trata de trabajar con operaciones asíncronas, por cierto. Cuando se trata de Node.js, eso es crucial. Intenta trabajar con operaciones asíncronas. En todas partes donde tengas una API asíncrona, trabaja con ella. Trabaja con Promesas siempre que puedas. Siempre intenta ejecutar las cosas en paralelo. Porque, ya sabes, cuando trabajamos con async/await, nos gusta ejecutar las cosas una por una. Pero si puedes, ejecútalas en paralelo para aprovechar toda la potencia de los hilos de trabajo, como la potencia de los hilos de trabajo.

Así que haz eso. Ejecuta tareas en paralelo. Y si necesitas realizar operaciones síncronas intensivas de CPU, utiliza el modelo principal de hilos de trabajo para ejecutarlas en un grupo de hilos. Eso es como la optimización específica de Node.js para el rendimiento que es importante.

Entonces, eso, está bien. Mencionaste que Express es el predeterminado. Y tienes, esa también es la pregunta aquí, NestJS, Express. ¿Qué hay de Fastify, otras herramientas, qué recomendarías? ¿Cuál es otra opción no típica?

Creo que actualmente Fastify, te brinda todo el paquete. Funciona mucho más rápido que otros. Utiliza un serializador mucho más eficiente. En mi charla, la razón por la que mostré el serializador es para las personas que trabajan con Express y no pueden cambiar de tecnología. Así que eso podría ser una victoria rápida para ellos. Pero Fastify te brinda el serializador eficiente, el registro eficiente. Te brinda todo el paquete. Así que funciona eficientemente con una base de datos, no con Mongo. Así que creo que ahora es recomendado.

Increíble. Muchas gracias por esa increíble sesión de preguntas y respuestas y tu excelente charla y por unirte a nuestra comunidad. Fue maravilloso tenerte aquí. Muchas gracias, Tamar. Muchas gracias por recibirme.