Speeding Up Your Node Sever With Rust

Hola, bienvenidos a mi charla, acelerando tu servidor Node con Rust. Mi nombre es Marco Ortevita. Soy el fundador y director general de MainMetal. Somos una consultoría de ingeniería. Hacemos un montón de cosas para ayudar a equipos internacionales a resolver sus desafíos tecnológicos. Hacemos formación, refuerzo de equipos, modernización de stack tecnológico y asesoramiento estratégico. Puedes encontrar más información en MainMetal.com.

Hoy quiero hablar sobre Node. Node es bastante ubicuo, ¿verdad?, lo cual, entre otras razones, se debe a que es fácil comenzar con él. Y típicamente hay un camino corto desde la idea hasta el prototipo o MVP con Node. El problema, por otro lado, con Node es, por ejemplo, que no es particularmente eficiente para algunas clases de tareas. Y veamos un ejemplo de tal tarea. Supongamos que tenemos un archivo JSON enorme con puntuaciones que podrían haber sido enviadas por algún tipo de juego. Este archivo data.

json aquí tiene 1 millón de tales entradas como ves en la diapositiva. Entonces supongamos que tenemos un servidor express simple con un endpoint para obtener la puntuación más alta. Ese endpoint lee el archivo JSON y revisa todas las puntuaciones para encontrar la más alta. Obviamente, este no es un ejemplo realmente realista y nadie proporcionaría un sistema así en la realidad. Pero por el bien de la charla, asumiremos que esto es lo que tenemos y que de alguna manera necesita ser así. Así que no es sorprendente que esto sea lento. Ejecutando una prueba de carga simple con 10 conexiones al servidor durante 10 segundos, ves que el tiempo de respuesta para el percentil 97.5 es de más de tres segundos.

Y logramos manejar 49 solicitudes en total en 10 segundos. Y podemos echar un vistazo más de cerca a por qué esto se ralentiza bien usando Clinic.js, que muestra en el gráfico superior izquierdo que nuestro rendimiento está limitado por la CPU, lo que significa que estamos usando constantemente alrededor del 100% de la CPU, lo cual es porque estamos constantemente maximizando uno de los núcleos de la CPU. Así que como Node es de un solo hilo, no puede usar más de un núcleo. Así que si estamos maximizando un núcleo, eso es tan rápido como podemos ir, realmente. Y también, estamos usando bastante memoria, como ves en la parte superior derecha. Y este patrón de sierra que ves allí es típico de los lenguajes recolectores de basura. Muchas cosas se crean en memoria y el uso de memoria crece y crece y crece hasta que el GC limpia toda la memoria no utilizada y el uso baja dramáticamente bastante rápido, después de lo cual vuelve a subir. Y también, mientras el GC se ejecuta, la ejecución de un programa se detiene, lo cual tampoco ayuda realmente con el rendimiento, obviamente. Y vamos a ignorar los otros gráficos aquí.

Estamos maximizando un núcleo de CPU, y realmente no hay nada que podamos hacer, para que el código vaya más rápido sin refactorizaciones mayores. Entonces, ¿qué podemos hacer? La respuesta favorita de todos siempre es el Big Bang. Tiramos todo lo que tenemos, comenzamos de nuevo con una mejor arquitectura. El sueño de todo ingeniero. Obviamente, hay algunos defectos en este enfoque, ¿verdad? Como principalmente el hecho de que es caro y arriesgado, como todo gran proyecto. Así que tú o tal vez tu gerente podrían pensar que tiene que haber una mejor manera, ¿verdad? Como una que no sea tan derrochadora y arriesgada, pero que aún resuelva el problema. Y, por supuesto, hay una que es usar módulos nativos, ¿verdad? En lugar del Big Bang, donde tiras todo y comienzas de nuevo, solo reemplazas de manera muy precisa las partes del código que son lentas y delegas el trabajo que hacen a algo que es más eficiente que JavaScript y, por lo tanto, capaz de ir más rápido. Y eso te permite mantener el resto de tu aplicación y la arquitectura general, que podría estar completamente bien, ¿verdad, y también lo suficientemente rápida. Y así, limita la inversión y el riesgo de toda la empresa. Y los módulos nativos no son, sin duda, algo nuevo. Realmente, probablemente te hayas encontrado con ellos antes, por ejemplo, en paquetes como bcrypt, donde cuando los instalas, ves estas cosas mencionando un JIP y CXX y todo eso, y eso es esencialmente la extensión nativa del paquete JavaScript siendo construida. Estas extensiones nativas generalmente están escritas en C.

Ahora, el problema con C es que usarlo es un poco como hacer malabares con motosierras, ¿verdad, lo cual no es algo que yo diga, sino algo que dice Linus Torvalds, y él debe saber, ¿verdad? Debe haber escrito millones de líneas de código en C. Así que C es obviamente poderoso, pero también es realmente peligroso, ¿verdad? Hay muchas trampas, principalmente cometer errores, hacer gestión manual de memoria, lo que puede tener consecuencias horribles tanto para la seguridad como para la estabilidad. Así que realmente solo puedes usar C cuando eres un experto o tienes un equipo de expertos, que esencialmente nadie tiene en áreas donde Node se está utilizando típicamente. Así que eso significa que los módulos nativos son una forma de acelerar las cosas en teoría, pero en realidad, porque requieren C, están un poco fuera de alcance. La buena noticia es que lo que acabo de decir ya no es cierto porque Rust ha venido a salvarnos de C, y abrir un nuevo mundo de posibilidades, ¿verdad, ya que ahora podemos escribir módulos nativos en Rust y así sin exponernos a las motosierras de C, ¿verdad? Así que ahora, antes de entrar en cómo funciona escribir módulos nativos en Rust, quiero darte una breve introducción a Rust, ¿verdad, para darte una impresión de lo que es el lenguaje y lo que hace para prevenir los peligros que existen en C. Así que el lema de Rust es un lenguaje que empodera a todos para construir software confiable y eficiente. Y la palabra empoderar realmente es central aquí, ¿verdad? Como Rust empodera a grandes partes de nuestra industria para lograr rendimiento y fiabilidad a niveles que antes estaban fuera de alcance. Así que veamos cómo lo hace, ¿verdad? Comenzando con lo básico, Rust es fuertemente tipado estáticamente. O bien escribes las cosas explícitamente o dejas que Rust infiera tipos donde pueda. A diferencia de muchos otros lenguajes, las variables son inmutables por defecto, ¿verdad? Así que intentar cambiar una variable después de que se le ha asignado un valor, como en este ejemplo, resulta en un error de compilador. Y por cierto, como puedes ver, Rust tiene mensajes de error bastante buenos, ¿verdad? Por lo general, están muy bien escritos y casi siempre sugieren una forma de corregir el error que también va a funcionar, típicamente. Así que mientras las variables son inmutables por defecto, a menudo hay mutabilidad también. Este ejemplo compila bien ya que XS está explícitamente marcado como mutable. Rust también tiene enums que también pueden contener datos. Como en este caso, la variante keypress del enum event contiene el código de la tecla que fue presionada. Y estos enums se utilizan para dos tipos en la biblioteca estándar de Rust que se utilizan extensamente en programas Rust, y por lo tanto vale la pena mencionarlos aquí. Uno es el enum result, que se utiliza para operaciones que pueden salir mal. Así que Rust no tiene excepciones que puedan lanzarse en tiempo de ejecución.

Así que usas el enum result para indicar si algo salió mal en tiempo de ejecución. Result tiene dos variantes, OK y Error, y es genérico sobre los tipos de los valores asociados con estas variantes. En este ejemplo, tenemos una función try que devuelve un result. Estamos usando un número U16 para el caso OK y un error personalizado strike para el caso Error. Y estamos llamando a la función. Podemos usar la declaración match de Rust para manejar los dos casos posibles, ¿verdad? El caso Error donde las cosas funcionan bien, y recibimos el valor, así como el caso Error. Y tenemos que manejar ambos casos, ¿verdad? El compilador nos obligará a hacerlo en tiempo de compilación.

Similar al enum result es el enum option, que se utiliza para representar la presencia o la ausencia de un valor. Tiene dos variantes, sum y none, y es genérico del tipo de valor que está asociado con la variante sum. En este ejemplo, la función getValue devuelve una option de U16. Y cuando llamamos a la función, podemos usar una declaración match nuevamente para manejar los dos casos. O bien obtenemos algún U16 o no obtenemos ninguno. Y nuevamente, tenemos que manejar ambos casos. Así que esto es muy diferente de lenguajes como JavaScript y otros donde cualquier referencia también podría ser siempre implícitamente nula, ¿verdad? En JavaScript, incluso podría ser nula o indefinida por alguna razón extraña. Y solo puedes saber con certeza en tiempo de ejecución si el valor que obtienes es nulo o no. Y necesitas verificar. Y si olvidas verificar, obtienes un error. El tipo option hace eso explícito, esencialmente, lo que permite al compilador prevenir esencialmente este tipo de excepciones de puntero nulo ya en tiempo de compilación.

Finalmente, uno de los principales mecanismos de Rust para prevenir estas fuentes de errores es su sistema de ownership. Es un tema un poco complejo, y todos los que llegan a Rust por primera vez le tienen miedo. Y tengo que admitir que eso está parcialmente justificado, al menos. Así que Rust no usa recolección de basura para la gestión de memoria como JavaScript. Y tampoco requiere que los desarrolladores gestionen la memoria ellos mismos manualmente como C. En su lugar, hace gestión de memoria en tiempo de compilación, esencialmente. Y para habilitar eso, para cada valor, Rust rastrea el ownership. Y el propietario de un valor es la variable que se refiere a ese valor. Y cuando el alcance, la variable fue definida en termina, no hay nada que se refiera al valor más, así que nada puede acceder al valor más. Y Rust sabe que es seguro liberar el valor de la memoria. Así que en tiempo de compilación, Rust puede entonces agregar automáticamente toda la gestión de memoria para ti en los lugares correctos, eliminando valores de la memoria en los lugares correctos en los momentos correctos. Y no entraremos en mucho detalle, pero aquí hay un breve ejemplo.

La variable ferris contiene un string como se define en el ámbito de la función main. Así que la variable ferris es la propietaria de ese valor de string. Luego pasamos el valor a la función uppercase. Al pasar el valor que la variable ferris posee a la función uppercase, la variable name o el argumento de la función uppercase se convierte en el nuevo propietario de ese valor. Y Rust sabe que al final del ámbito de la función uppercase, cuando la variable name sale del ámbito, el valor al que apunta puede ser liberado porque ya no se puede acceder a él.

Sin embargo, en la función main, estamos accediendo al valor a través de la variable ferris en la línea de impresión después de que la función uppercase ha completado y por lo tanto el valor ha sido liberado. Y eso no puede funcionar, y obtenemos un error de compilación. En este caso, una solución simple para el error sería en lugar de pasar el valor y por lo tanto pasar el ownership, pasar una referencia de solo lectura al valor para que el ownership permanezca con la variable ferris y la función uppercase simplemente tome prestado el valor por un tiempo. Y este ejemplo aquí se compilará bien.

Como dije, sin embargo, es un tema complejo. Así que solo sepa que Rust no hace recolección de basura y tampoco requiere que los desarrolladores gestionen la memoria manualmente. En su lugar, tiene ese sistema de ownership, que le permite gestionar la memoria en tiempo de compilación por usted. Así que todas estas cosas combinadas, el sistema de ownership que asegura que no puedan existir los típicos errores de memoria como el uso después de liberar y similares como pueden ocurrir en C, inmutabilidad por defecto, el tipo result que impone un manejo adecuado de errores, el tipo option que impone el manejo de casos donde los valores están ausentes, todas estas cosas existen para salvarte de los peligros de un lenguaje como C. Si un programa Rust se compila, va a ejecutarse de manera muy eficiente y confiable.

Así que eso significa que las motosierras de C ahora son juguetes de peluche, esencialmente. O al menos esto es lo que ChatGPT piensa que el video anterior se ve como con las motosierras reemplazadas por juguetes de peluche. {{^}}Así que eso significa que escribir módulos nativos ya no es una tarea. Es muy probable que lleve al equipo a clasificarse a sí mismos, cortándose las manos con una motosierra, pero algunas cosas que realmente pueden atreverse a hacer. Así que ahora hagamos esto. Vamos a escribir un módulo nativo en Rust.

Por supuesto, no tenemos que empezar desde los primeros principios, y podemos confiar en las herramientas para facilitar las cosas, en este caso, NAPI. NAPI es un paquete que ayuda a escribir módulos nativos en Rust. Maneja la creación del proyecto, la compilación, así como la unión del código JavaScript y Rust al final. Cuando creas un paquete con la herramienta CLI de NAPI, obtienes un directorio de trabajo que se ve algo así. Hay un archivo package.json y un archivo main.js, como usualmente en un paquete, así como un montón de cosas de Rust, como cargo.toml y cargo.log, que son el equivalente de package.json y el archivo de registro de tu gestor de paquetes de elección.

Un archivo build.rs que maneja algunas cosas específicas alrededor de la construcción del código Rust, y un directorio de origen con un archivo lib.rs, que es donde va tu código Rust. Así que ahora escribamos una implementación en Rust del código que encuentra la puntuación más alta en nuestro archivo JSON de antes. En la parte superior, importamos algunas cosas que necesitamos. El trait deserialized de la dependencia Serde es necesario para deserializar el contenido de data.json en una estructura Rust. Y necesitamos el módulo fs de la biblioteca estándar de Rust para poder leer el contenido del archivo. Y tenemos algo de código específico de nappy que necesitamos para hacer que nuestra función Rust esté disponible para JavaScript.

No entraré en detalles porque es complejo. Y a continuación, está la estructura del item, que representa una entrada en el archivo JSON, ¿verdad? Su atributo score coincide con el campo del JSON, y ignoramos los atributos ID y name del JSON ya que no los necesitamos para calcular la puntuación más alta. Y luego, finalmente, tenemos la función de puntuación más alta en sí, que lee el contenido del archivo, deserializa un vector de estructuras de item del JSON, y finalmente itera sobre todos esos elementos en el vector y encuentra la puntuación máxima. No entraré en más detalles aquí. Solo quiero mencionar una cosa. Este código usa unwrap en varios lugares, lo cual es realmente malo, y solo lo estoy haciendo aquí para mantener el código simple. Así que ves que las funciones readToString y fromString y maxByKey todas devuelven resultados, ¿verdad? lo que significa que pueden fallar, y realmente deberíamos manejar tanto el caso de éxito como el de error, como mostré antes.

Llamar a unwrap en esos resultados simplemente significa fallar en tiempo de ejecución en caso de un error, lo cual es algo que nadie debería hacer en código de producción, así que me avergüenzo de mostrarte esto, pero como esto es un ejemplo y queremos mantener el código simple, lo estamos haciendo, pero solo recuerda, no hagas esto realmente, ¿verdad? De todos modos, teniendo este código Rust, podemos compilarlo, ¿verdad? No necesitamos preocuparnos por los detalles aquí. Una aplicación lo configura todo por ti, y una vez que está compilado, podemos usarlo fácilmente desde nuestro servidor express en JavaScript, ¿verdad? Así que aquí importamos en la línea dos la implementación de Rust, y luego en el endpoint de puntuación más alta, usamos la función de Rust para calcular la puntuación más alta en lugar de la implementación anterior en JavaScript, por lo que los cambios en el código JavaScript son bastante mínimos, y podemos usar la función de Rust completamente de manera transparente y mantener la arquitectura general tal como está, ¿verdad? El efecto de esto, sin embargo, es un servidor sustancialmente más rápido, ¿verdad? El tiempo de respuesta para el percentil 97.5 ahora es de aproximadamente 1.7 segundos, ¿verdad? casi el doble de rápido que antes, y en lugar de 49 solicitudes en total, ahora manejamos 122, ¿verdad?

más del doble. Mirando las cosas un poco más a fondo, todavía estamos viendo, todavía estamos maximizando la CPU, por supuesto, ¿verdad? ya que esta es una tarea dependiente de la CPU, y eso siempre será el caso, pero estamos usando la CPU de manera más eficiente, ¿verdad? Así que la estamos maximizando por un período de tiempo más corto, o por la misma cantidad de tiempo para el benchmark de 10 segundos, pero podemos manejar más solicitudes al mismo tiempo. También es importante notar que todavía estamos usando solo un núcleo aquí, ¿verdad? Dado que Rust es multihilo, podríamos cambiar el código relativamente fácil para aprovechar más núcleos, aumentando aún más la ganancia de rendimiento y, como, por un margen considerable. Y también estamos usando mucho menos memoria, ¿verdad? y el uso de memoria es estable ya que no hay recolección de basura, ¿verdad? Verás que es esencialmente una línea plana la mayor parte del tiempo. Así que aunque este es un ejemplo bastante poco realista, verás que obviamente hay una diferencia bastante sustancial en el rendimiento entre Node y Rust, y fue relativamente fácil desbloquear ese tipo de ganancia de rendimiento, ¿verdad? Y también hay riesgos mínimos. También hay un riesgo mínimo para los problemas con los que nos encontraríamos con C ya que Rust nos protege de ellos, como mostré antes. Así que echemos un breve vistazo a cómo funciona esto bajo el capó. En package.json, tenemos un nuevo script de compilación, ¿verdad? que nappy generó, que usamos antes para compilar el código. Así que eso compila el código Rust en el módulo nativo binario. En este caso, es jsnation-demo-darwin-arm64.node. También genera un archivo index.js a través del cual se puede usar el modelo nativo desde JavaScript, ¿verdad? Recuerda en el ejemplo anterior que mostré, importamos la función de Rust desde index.js, no desde ese archivo .node. Y el archivo index.js simplemente carga el binario correcto para la plataforma actual, ¿verdad? En mi Mac, la plataforma es ARM64, así que esto cargaría el archivo jsnation-demo-darwin-arm64.node que vimos antes. Así que si ahora te propones escribir módulos nativos en Rust, hay algunas cosas a considerar. Aunque los módulos nativos son excelentes para hacer cosas lentas más rápidas, obviamente no todo lo que es lento se beneficiará. Las tareas dependientes de I.O. como leer de una base de datos, por ejemplo, no se beneficiarán ya que tu código no es lo que es lento, sino los recursos externos, ¿verdad? Así que hacer tu código más rápido no tendrá mucho impacto. Así que analiza cuidadosamente antes de proponerte escribir módulos nativos. Los escenarios típicos para módulos nativos son cargas de trabajo dependientes de la CPU, obviamente como en el ejemplo que compartí. También hay un poco de sobrecarga al cambiar de contexto entre Rust y JavaScript, y en particular, mover estructuras de datos a través de las fronteras puede ser costoso, ¿verdad? Porque los datos tendrán que ser transcodificados de representaciones de Rust a representaciones de JavaScript y viceversa cada vez, y eso puede ser bastante costoso y resultar en que algunas cosas incluso sean más lentas que una implementación pura de JavaScript. Y por último, Rust también es un gran lenguaje para compilar a JavaScript. Para compilar a WebAssembly. Sus restricciones lo hacen un gran ajuste para WebAssembly y las herramientas de WebAssembly en Rust también son bastante sólidas, ¿verdad? Así que eso significa que el código Rust que escribes para usarlo en módulos nativos también, en teoría, podrá tal vez reutilizarlo en el navegador o en funciones de borde como WebAssembly. Y eso es algo que vale la pena tener en cuenta al comenzar a introducir Rust en tu base de código. Así que espero que todos se conviertan en fanáticos de Rust ahora, y tu primer módulo nativo en Rust podría ser solo el primer paso en un viaje más largo hacia más y más Rust, ¿verdad? Podrías escribir más y más módulos nativos en Rust, tal vez reutilizar el código en WebAssembly, y eventualmente desplegar tu primer microservicio en Rust, y tal vez eventualmente tu viaje con Rust te lleve a EuroRust, la conferencia líder de Rust en Europa, que casualmente organizamos.