Instantáneas de inicio de Node.js

Como mencioné, soy Joy. Trabajo en Egaleo y trabajo en Node y V8. He estado trabajando en la iniciativa estratégica de rendimiento de startups en Node durante un tiempo. La iniciativa ha sido renombrada recientemente como Startup Snapshot, ya que hemos realizado la integración dentro del núcleo de Node y estamos habilitando esta función para aplicaciones de usuario, de lo cual hablaré hoy.

Así que empecemos. Un poco de historia. La integración de Startup Snapshot comenzó cuando Node comenzó a abandonar gradualmente la antigua filosofía de un núcleo pequeño y agregar muchas más características incorporadas. Esto incluye nuevos globales, en particular, nuevas API web, nuevos módulos incorporados y nuevas API en módulos existentes. Estas nuevas características requieren configuración adicional durante el inicio del núcleo de Node o requieren la carga de módulos internos adicionales durante el inicio.

Para darles una visión general, desde la última versión LTS 18 hasta la próxima versión 20, hemos agregado soporte para VEJ, web crypto, file API, blob, un montón de web strings y un montón de nuevas API bajo Yotel, como el analizador de argumentos y el analizador de tipos MIE. La lista es más larga que eso, pero te haces una idea. Node está creciendo mucho. Otra parte de este desafío es que el núcleo de Node está escrito aproximadamente en un 50% en JavaScript y en un 50% en C++. Por lo tanto, muchas de esas partes internas están implementadas en JavaScript.

La ventaja de esto es que reduce la barrera de contribución. En algunos casos, reduce los costos de devolución de llamada de C++ a JavaScript. Pero al mismo tiempo, esto dificulta mantener el rendimiento de inicio. Por un lado, el código JavaScript debe ser analizado y compilado antes de poder ejecutarse, y eso lleva tiempo. Además, la mayor parte del código JavaScript de inicialización solo se ejecuta una vez durante el inicio porque es solo inicialización, por lo que el motor de JavaScript no lo optimiza.

Cuando implementamos una biblioteca en JavaScript, debemos tener en cuenta la posible contaminación de prototipos. No queremos que el usuario haga explotar el tiempo de ejecución solo porque elimina algo del edificio de un prototipo, como el prototipo de cadena con el que comenzó. Para mitigar esto, no es necesario crear copias de estos edificios de JavaScript como inicio para que los internos los usen. En realidad, no utilizan los métodos de prototipo que exponemos a los usuarios. Todo esto puede ralentizar el inicio a medida que Node crece.

Para controlar el costo de la inicialización de inicio, el núcleo de Node utiliza múltiples estrategias. Primero, no inicializamos todos los globales y edificios al inicio. Para las características que aún son experimentales o demasiado nuevas para ser utilizadas ampliamente o solo sirven para un tipo específico de aplicación, solo instalamos accesorios que los cargarán de forma perezosa cuando el usuario los acceda por primera vez. Y segundo, al compilar versiones, precompilamos todos los módulos internos para generar la caché de código que contiene bytecode y metadatos, y los agregamos al ejecutable para que cuando tengamos que cargar módulos adicionales que solicite un usuario, pasamos la caché de código a V8, y V8 puede omitir el análisis y la compilación, y simplemente usar el código serializado cuando se actualiza, cuando valida esa caché. Y finalmente, para las características esenciales que casi siempre tenemos que cargar, por ejemplo, la API de URL web, el módulo FS, que también son utilizados por otros internos, o características ampliamente utilizadas como temporizadores, como el tiempo, características ampliamente utilizadas como temporizadores, los capturamos en una instantánea de inicio de V8, lo que ayuda a omitir simplemente la ejecución del código de inicialización y ahorrar tiempo durante el inicio.

Entonces, así es como solía construirse y ejecutarse el ejecutable de Node. Inicialmente, simplemente incrustábamos el código JavaScript en el ejecutable, en el momento de la compilación. Y en el momento de la ejecución, necesitamos analizarlo, compilarlo, ejecutarlo para inicializar el núcleo de Node y antes de poder ejecutar el código del usuario y procesar los estados del sistema para inicializar la aplicación del usuario. Y luego introdujimos la caché de código incrustado. Entonces, en el momento de la compilación, precompilamos todo el código JavaScript interno y generamos una caché de código compilado, y luego los incrustamos en el ejecutable. Y en el momento de la ejecución, le pediremos a VA que use la caché de código y omita el proceso de análisis y compilación. Aún conservaremos el código JavaScript interno como la fuente de verdad, en caso de que la caché de código no se valide en el entorno de ejecución actual, pero la mayor parte del tiempo, se utiliza el código y simplemente omitimos el proceso de compilación. Y ahora, con la integración de la instantánea de inicio, simplemente ejecutamos el código JavaScript interno en el momento de la compilación para inicializar un montón de Node y luego capturamos una instantánea y la incrustamos en el ejecutable. Los otros dos se mantienen como alternativa, pero en el tiempo de ejecución simplemente deserializamos la instantánea para obtener el montón inicializado. Por lo tanto, no es necesario ni siquiera analizar, compilar, ejecutar. El código interno es como, deserializas el resultado. Entonces, ¿qué son exactamente estas instantáneas de inicio de VA? Básicamente, son el montón VA serializado en un bloque binario. Hay dos capas de instantáneas, una que captura todos los primitivos y las uniones nativas, y otra que captura los contactos de ejecución, como los objetos y las funciones. Actualmente, NOE utiliza la instantánea de aislamiento para todos los aislamientos que se pueden crear desde el useland, incluido el aislamiento principal y los aislamientos de trabajadores. También tenemos instantáneas de contactos incorporadas para los contactos principales, los contactos de VM y los contactos de trabajadores, aunque la instantánea de contactos de trabajadores actualmente solo contiene cosas muy mínimas.

Y todavía estamos trabajando en incluir más cosas allí. Aquí. Con la instantánea predeterminada, el inicio es generalmente el doble de rápido en comparación con el inicio sin una instantánea. Por ejemplo, en esta MacBook, el inicio de Nucor pasa de aproximadamente 40 milisegundos a 20 milisegundos. A la izquierda se muestra el inicio de Nucor sin la instantánea, y a la derecha se muestra el inicio de Nucor con la instantánea. Incluso en el gráfico de llamas, se puede ver que hay menos tareas por hacer y es más simple y rápido. Esto también nos brinda más sostenibilidad a medida que crecemos Nucor y mantenemos el inicio bajo control. Todavía estamos ajustando la instantánea interna para asegurarnos de que la incorporada contenga la cantidad justa de características esenciales. Pero al mismo tiempo, esta función también está disponible para los usuarios, para que puedan crear instantáneas de sus propias aplicaciones. Esto puede ser útil para aplicaciones donde el rendimiento de inicio es importante, como herramientas de línea de comandos. En particular, si la aplicación necesita ejecutar mucho código durante el inicio o cargar muchos datos independientes del sistema, estas operaciones se pueden realizar al construir la instantánea en lugar de hacerlo en tiempo de ejecución. El flujo de trabajo general es similar al de construir la instantánea principal. Null puede tomar un script de usuario, realizar una inicialización esencial para las aplicaciones del usuario y ejecutar ese script hasta su finalización. Después de que se completen todas las operaciones asíncronas, Null puede tomar una instantánea del montón y escribirla en algún lugar, ya sea en un archivo binario junto con el ejecutable Null o como un bloque separado en el disco. Al volver a iniciar, Null puede obtener la instantánea precompilada de algún lugar y luego deserializar un montón de usuario a partir de ella para omitir las configuraciones. Actualmente, la instantánea de useline solo toma un archivo como entrada, por lo que deberá agrupar el código de configuración en un solo archivo. Pero también estamos investigando el soporte de módulos de useline en el script de construcción de instantáneas. Así que eso también está por venir. Actualmente, hay dos formas de generar la instantánea de useline. La primera es la más complicada, que consiste en construir null desde el origen con la opción de configuración --null-snapshot-main, lo que indica a 2 chain que genere una instantánea utilizando el script de usuario proporcionado y reemplace la instantánea predeterminada con una instantánea personalizada. El ejecutable final de Node contendrá la instantánea del usuario. Por ejemplo, tenemos un archivo aquí que contiene algo como global.js. Y colocamos una cadena allí. Puedes colocar muchas otras cosas complicadas, pero esto es solo un ejemplo. Luego, vas al directorio de código fuente de Node y lo construyes con esa opción de configuración. El ejecutable final que se produce en el proceso de compilación contendrá un binario que ya tiene la instantánea que contiene esta cosa que colocaste en el global this. Otra opción que no requiere construir Node desde el origen es usar la opción --build-snapshot-runtime del ejecutable oficial de Node. Esto puede ser útil si no quieres construir Node desde el origen, lo cual puede llevar mucho tiempo.

Por defecto, esto genera un archivo llamado instantánea.blob en el directorio de trabajo actual utilizando el script proporcionado. Pero también puede especificar la ruta de entrada/salida con la opción --snapshot-blob. Y al iniciar Node con una instantánea personalizada, puede utilizar nuevamente esa opción --snapshot-blob como una forma de indicarle a Node que deserialice un montón a partir de la instantánea personalizada especificada en lugar de configurar un montón predeterminado de Node Core. Esto le ayudará a omitir el análisis, la compilación y la ejecución de su propio código y le ayudará a ejecutarse más rápido. Ahora, hay otra opción que está en desarrollo, que es la nueva función de aplicación de ejecutable único. Y la instantánea se puede agregar a eso. Esto significa que será posible generar una instantánea y agregarla a un ejecutable único con Node mismo sin tener que compilar Node desde el origen. Una vista previa rápida del diseño actual es que el usuario puede crear una configuración JSON como la siguiente, instantánea. Se especifica el script principal con instantánea principal, la ruta y luego se especifica dónde desea que se escriba la salida. Luego, utiliza el ejecutable oficial de Node para tomar esta configuración JSON y generar el archivo blob. Luego, copia el ejecutable a la ruta de destino porque va a inyectar ese archivo blob. Y utiliza, por ejemplo, la línea de comandos post-ject, que es mantenida oficialmente por Node, para inyectar ese archivo blob en el binario, que es C allí, la aplicación de ejecutable único. Y luego, después de inyectar el archivo blob en ese binario, que contendrá una instantánea, Node simplemente sabrá que, oh, tengo una instantánea incrustada en este binario. Cuando se inicie, simplemente inicializaré eso. Y con esto, no es necesario compilar Node desde el origen para usar una instantánea incrustada. Aún está en desarrollo, pero está llegando. Probablemente se implementará en la versión 20. También estamos pensando en, en lugar de hacer todo esto, proporcionar algún tipo de utilidad de una sola línea para obtener una configuración JSON. Y luego genera un ejecutable único que puedes ejecutar sin hacer todo esto. Y para ayudar a los usuarios a crear instantáneas personalizadas, Node también ofrece varias APIs de JavaScript para ayudar a sincronizar los estados en tiempo de ejecución en el script de instantánea. Por defecto, después de deserializar un archivo de instantánea.blob, Node actualizará los estados en tiempo de ejecución, como process.env y process.argv. Y si el código del usuario precalcula algo de estos estados o almacena en caché estos estados antes de que se serialice la instantánea, esto se actualizará durante la deserialización. Por ejemplo, si el código del usuario calcula un nivel de depuración basado en la variable de entorno nivel de depuración como se muestra en el script de instantánea. Es posible que ya estén haciendo esto. Cuando están construyendo la instantánea, luego, en tiempo de ejecución, pueden sincronizar esto con la API de sincronización de instantáneas que proporcionamos a través del espacio de nombres V8 Startup Snapshot. Por ejemplo, en el script de instantánea de inicio, puede agregar algunas devoluciones de llamada que se llamarán. Primero, una devolución de llamada que se puede llamar durante el proceso de serialización para restablecer ese nivel de depuración. Y luego agrega otra devolución de llamada serializada que puede restablecer el nivel de depuración según la variable de entorno configurada en tiempo de ejecución. Y eso le ayudará a sincronizar estos estados nuevamente. O simplemente puede posponer el cálculo hasta la serialización si está construyendo una instantánea.

También hay un getter llamado building a snapshot que se puede utilizar desde la API para determinar si el código se está ejecutando para construir una instantánea. Otra API útil es setDigitalizedMainFunction, que nos permite especificar una función principal en la instantánea sin tener que pasar otro script principal.

Por ejemplo, si la instantánea que tenemos es una base de datos de saludos en diferentes idiomas. Una forma de registrar el saludo, según alguna variable de entorno durante el tiempo de ejecución, es, por ejemplo, pasar un script principal separado que haga el registro. Pero eso significa que necesitaremos una entrada adicional, que también debe ser analizada y compilada en tiempo de ejecución. En cambio, puedes usar la API de JavaScript, que puede incluir una función principal en la instantánea. Así, el código de esta función principal también se compilará y se serializará en la instantánea. Entonces, un nodo en tiempo de ejecución simplemente deserializará esta función principal y la ejecutará. Entonces ya no necesitamos una entrada adicional. Y también es más rápido, porque ya no es necesario compilar más código.

En resumen, hemos estado integrando instantáneas de inicio en NodeCore para acelerar el inicio del núcleo. Y ahora existe soporte experimental para instantáneas de usuario con algunas APIs de JavaScript en el espacio de nombres de instantáneas de inicio de DBA para ayudar a construirlas. También estamos trabajando en el soporte para una aplicación ejecutable única, así como más características en la instantánea. Ok, así que finalmente me gustaría agradecer a todas las personas que han contribuido a esta función, incluyendo a Anna, Colin, James, Chen Zhong, Dasham y muchos otros a los que olvido mencionar en las diapositivas, lo siento. También personalmente me gustaría agradecer a Bloomberg e Ingaria por apoyar mi parte de trabajo en esto. Y eso es todo, gracias. Gracias. Gracias. Gracias. Gracias. Gracias. Gracias. ¿Debo, ok. Gracias, Eversome, ya sabes cómo va. Sí, vamos, vamos a charlar. Hola, muchas gracias por esa charla. Audiencia, tanto en línea como en la sala, por favor, siéntanse libres de hacer preguntas. Slido.com, 1404, o el código QR, ¿cuál es? Lo mismo. Déjame ver las preguntas. Solo voy a comenzar mientras estoy haciendo tonterías y esperando las preguntas. Hasta ahora, ¿cuáles han sido los conceptos erróneos comunes en el diseño de las Instantáneas de Inicio que la gente tiene?`

Utilizaron la misma infraestructura subyacente, como NVA, para serializar un montón. Pero son herramientas diferentes para diferentes propósitos. Las instantáneas de montón están diseñadas para hacer diagnósticos en el montón, y las instantáneas de inicio están destinadas a ser rehidratadas, mientras que las instantáneas de montón no lo están, las instantáneas de inicio sí. Creo que eso es, hay tantas instantáneas en VA, que la gente puede confundirse un poco. Sí, eso es algo que se ve comúnmente. Sí, lo cual también tiene sentido. Tienen nombres similares, personas que están comenzando a aprender también.

Tenemos muchas preguntas. Pasamos de no tener preguntas en mi teléfono a tener un montón de preguntas, así que gracias a todos en la sala en línea que las han estado enviando, wow.

Muy bien, primera pregunta con más votos. ¿Las instantáneas también se pueden utilizar para iniciar las AWS Lambdas más rápido? Esto no es algo que, porque en AWS, no es algo que tú, como usuario, puedas controlar, como cómo se inicia Node. Así que la responsabilidad de usar esto recae en quien ejecute Node. Creo que en este caso, recae en Amazon. Sí, como usuario de esto, yo era un integrador de Node, eso está fuera de tu control, pero si eres alguien que puede ejecutar Node tú mismo, o si puedes pasar banderas adicionales a Node, entonces sí, puedes hacerlo. Genial, gracias.

La siguiente pregunta es, ¿existe alguna posibilidad de filtrar accidentalmente variables de entorno sensibles a la instantánea durante el tiempo de compilación? ¿Cuál? Oh, lo siento, podemos revisarlas juntos. Es la primera que está resaltada allí. ¿Existe alguna posibilidad de filtrar accidentalmente variables de entorno sensibles a la instantánea durante el tiempo de compilación? En el núcleo de Node, tenemos algunas afirmaciones internas para asegurarnos de que no las filtres. También estamos considerando exponer esto al usuario. Pero si estás deserializando una instantánea de inicio, por lo general no las verás. Es muy difícil que las veas porque Node las actualizará todas. Así que si pones algo intencionalmente ahí, eso es posible. Pero también puedes actualizarlas más tarde. Muy bien. Sí, aunque imagino que si las personas lo hicieran, probablemente no sería un acto intencional. Definitivamente algo de lo que soy culpable. ¿Cuánto impulso de inicio se ha probado que se logra con las instantáneas de inicio de usuario? Así que literalmente hay un compilador de TypeScript en el núcleo de Node como una prueba para probar que podemos hacer una instantánea del compilador de TypeScript. Así que eso es como obtener todavía alrededor, todavía está en el rango que mencioné antes. Es como dos veces más rápido. Antes eran como 200 milisegundos, por ejemplo, en mi máquina de prueba.

Y luego, cuando activas la instantánea, son como 100 milisegundos. Depende también de cuánta inicialización hagas en tu aplicación. Si haces mucha, entonces ahorrarás más porque ni siquiera ejecutarás código para inicializar tu aplicación, simplemente destruirás las cosas. En general, diría que puedes obtener hasta dos veces más rápido.

Genial, gracias. Tenemos tiempo para una más y tenemos varias que tienen dos marcas. Vamos a ir con la que está aquí arriba. ¿Cuáles son las limitaciones de las instantáneas? Por ejemplo, una conexión TCP a una base de datos no se serializará o tal vez hay otras cosas que considerar también.

Sí, eso es lo que mencioné antes. Por ejemplo, eso sería una operación asíncrona que debe finalizarse antes de tomar una instantánea porque estoy bastante seguro de que podría ser posible de alguna manera poder deserializar una solicitud en curso, pero eso tampoco es actualmente un objetivo de esta función. Así que debes asegurarte de que no haya solicitudes asíncronas antes de tomar la instantánea y debes resolver las promesas. Y sí, esas son las limitaciones actuales de estas instantáneas de inicio. Sí, y esperemos comenzar a construir los modelos mentales de las personas sobre cuándo es apropiado hacer esto y cuándo tal vez no tenga sentido para un proyecto.

Vamos a hacer solo una más aquí. ¿Qué tan buena idea es poner todo el código en una instantánea para optimizar el inicio de toda la aplicación? Una cosa que puedes hacer es envolver todo en una función que no invocas cuando construyes la instantánea. Y luego colocas esa función como la función principal de deserialización en la instantánea. Entonces, cuando deserializas, se ejecuta toda la función. Es posible hacerlo, pero probablemente no obtendrás suficiente caché de compilación con eso porque si no están en el nivel superior, VA compilará selectivamente algunos de ellos pero no todos. Hay algunas pistas. Entonces es algo que puedes hacer, pero también si quieres un resultado óptimo optimizado, puedes intentar poner más de ellos en el nivel superior. Sí, tiene sentido, genial.

Mira, hay muchas más preguntas. Se caen al final de la página, pero se nos acabó el tiempo. Así que les recordaré a todos, tanto en la sala como en línea, que la sala de preguntas y respuestas es donde pueden continuar haciendo preguntas sobre este tema. El espacio físico está junto a la recepción, a la izquierda de la puerta, cuando estás frente a ella para salir, y aquellos en línea pueden usar la sala de preguntas y respuestas en el chat espacial, pero por favor, únanse a mí en un gran aplauso para Joy. Muchas gracias, qué charla fantástica. Gracias. Gracias. Gracias.