Instantáneas de inicio de Node.js

Como mencioné, soy Joy. Trabajo en Egaleo y trabajo en Node y V8. Así que he estado trabajando en la iniciativa estratégica de rendimiento de inicio en Node durante un tiempo. La iniciativa recientemente ha sido renombrada a Startup Snapshot ya que hemos realizado la integración dentro del núcleo de Node y estamos habilitando esta característica para aplicaciones de usuario, que es de lo que voy a hablar hoy.

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

Para darles una visión general desde la última versión LTS 18 hasta la próxima 20, hemos añadido soporte para VEJ, web crypto, file API, blob, un montón de web strings, y un montón de nuevas APIs bajo Yotel, como el analizador de argumentos y el analizador de tipo MIE. La lista es más larga que eso, pero ya tienen una idea. Como Node está creciendo mucho. Otra parte de este challenge es que el núcleo de Node está escrito aproximadamente la mitad en JavaScript y la mitad en C++. Así que muchos de esos internos están realmente implementados en JavaScript.

La ventaja de esto es que esto reduce la barrera de contribución. En algunos casos, reduce los costos de callback de C++ a JavaScript. Pero al mismo tiempo, esto hace que sea más difícil mantener el rendimiento de inicio. Por un lado, el código de JavaScript necesita ser analizado y compilado antes de que pueda ser ejecutado, y eso lleva tiempo. Además, la mayoría del código de JavaScript para la inicialización sólo se ejecuta una vez durante el inicio porque es sólo inicialización, por lo que no se optimiza por el motor de JavaScript.

Al implementar una biblioteca en JavaScript, tenemos que tener en cuenta la posible contaminación del prototipo. No quieres que el usuario haga explotar el tiempo de ejecución sólo porque borran algo del edificio a un prototipo, como el prototipo de cadena que comenzó con. Así que para mitigar esto, no necesitamos crear copias de estos edificios de JavaScript como inicio para el uso interno. En realidad no utilizan los métodos de prototipo que exponemos a los usuarios. Todo esto puede ralentizar el inicio a medida que crece el nodo.

Así que para mantener el costo de la inicialización de inicio bajo control, el núcleo de Node utiliza múltiples estrategias. Primero, no inicializamos todos los globales y edificios como inicio. Para las características que aún son experimentales o demasiado nuevas para ser utilizadas ampliamente o sólo sirven a un tipo específico de aplicación, sólo instalamos accesorios que los cargarán de forma perezosa cuando el usuario los acceda por primera vez. Y segundo, cuando construimos lanzamientos, precompilamos todos los módulos internos para generar el código de caché que contiene bytecode y metadatos, y los añadimos al ejecutable para que cuando tengamos que cargar módulos adicionales, una solicitud de usuario, pasamos el código de caché a V8, y V8 puede saltarse 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 es utilizado por otros internos, o como características ampliamente utilizadas como temporizadores, como tiempo, características ampliamente utilizadas como temporizadores, los capturamos en una instantánea de inicio de V8, lo que ayuda a simplemente saltar la ejecución del código de inicialización y ahorrar tiempo durante el inicio.

Así que esto es algo así como cómo solía ser construido y ejecutado el ejecutable de nodo. Inicialmente, sólo estábamos incrustando el código de JavaScript en el ejecutable, en tiempo de construcción. Y en tiempo de ejecución, necesitamos analizarlo, necesitamos compilarlo, necesitamos ejecutarlo para obtener el núcleo de nodo inicializado, y antes de que podamos 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 incrustada. Así que en tiempo de construcción, precompilamos todo el código de JavaScript interno y generamos la caché de código compilado, y luego los incrustamos en el ejecutable. Y en tiempo de ejecución, le pediremos a VA que use la caché de código y salte el proceso de análisis y compilación. Todavía mantendremos el código de 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ía de las veces, el código se utiliza, y simplemente saltamos el proceso de compilación. Y ahora, con la integración de la instantánea de inicio, simplemente ejecutamos el código de JavaScript interno en tiempo de construcción para inicializar un montón de notas y luego capturamos una instantánea y la incrustamos en el ejecutable. Los otros dos todavía se mantienen como respaldo, pero en tiempo de ejecución simplemente deserializamos la instantánea para obtener el montón inicializado. Así que no hay necesidad de analizar, compilar, ejecutar. El código interno es simplemente como, deserializas el resultado. Entonces, ¿qué son exactamente estas instantáneas de inicio de VA? Básicamente son el montón de VA serializado en un blob binario. Hay dos capas de instantáneas, una que captura todos los primitivos y las vinculaciones nativas, y una que captura los contactos de ejecución, como los objetos y funciones. Así que actualmente, NOE utiliza la instantánea de aislamiento para todos los aislamientos que puedes crear desde la tierra de los usuarios, incluyendo el aislamiento principal y los aislamientos de los trabajadores. También tenemos instantáneas de contactos incorporadas para los contactos principales, los contactos VM, y los contactos de los trabajadores, aunque la instantánea de los contactos de los trabajadores actualmente sólo contiene cosas muy mínimas.

Y todavía estamos trabajando en incluir más cosas allí. Aquí. Entonces, con la instantánea predeterminada, el inicio generalmente es como dos veces más rápido en comparación con el lanzamiento sin una instantánea. Por ejemplo, en este MacBook, pasa de unos 40 milisegundos a 20 milisegundos para iniciar Nucor. Y desde estos, entonces a la izquierda, ese es el Nucor iniciado sin la instantánea. Y a la derecha, ese es el inicio de Nucor iniciado con la instantánea. Y puedes ver que, incluso en el gráfico de llamas, hay menos que hacer, y obviamente es mucho más simple, y se ejecuta más rápido. Entonces, sí, y esto también nos brinda más sostenibilidad a medida que crecemos Nucor manteniendo el inicio bajo control. Y todavía estamos ajustando la instantánea interna para asegurarnos de que la incorporada contenga la cantidad justa de características esenciales. Pero también, al mismo tiempo, la característica ahora también está disponible para los usuarios para que las personas puedan simplemente crear instantáneas de sus propias aplicaciones. Por lo tanto, esto puede ser útil para aplicaciones donde el rendimiento de inicio importa, por ejemplo, como herramientas de línea de comandos. En particular, si la aplicación necesita ejecutar mucho code durante el inicio, o necesita cargar muchos data independientes del sistema, estas operaciones se pueden hacer al construir la instantánea en lugar de hacerse en tiempo de ejecución. Por lo tanto, el flujo de trabajo general es similar al flujo de trabajo para construir la instantánea principal. Entonces Null puede tomar un script proporcionado por el usuario, en algún lugar para hacer alguna inicialización esencial para las aplicaciones del usuario, y puede ejecutar ese script hasta su finalización. Y después de que todas las operaciones asíncronas hayan terminado, por ejemplo, todas las promesas se resuelven, Null puede tomar una instantánea del montón y escribirla en algún lugar, ya sea en un binario junto con el ejecutable Null en sí o como un bloque separado en el disco. Y al iniciar de nuevo, Null puede simplemente obtener la instantánea preconstruida de algún lugar y luego deserializar un montón de usuarios a partir de ella para omitir las configuraciones. Entonces, actualmente, la instantánea de Useline solo toma un archivo como entrada. Por lo tanto, tendrás que agrupar el code de configuración en un solo archivo. Pero también estamos buscando soporte para el módulo Useline en el script de construcción de instantáneas. Entonces sí, eso también está por venir. Y actualmente, hay dos formas de generar la instantánea de Useline. Entonces, la primera es la más difícil, que es construir null desde el código fuente con la opción de configuración --null snapshot main, que le dice a la cadena 2 para generar una instantánea utilizando el script de usuario proporcionado y reemplazar la instantánea predeterminada con una instantánea personalizada. Y el ejecutable final de node contendría la instantánea del usuario. Entonces, por ejemplo, tenemos un archivo aquí que contiene algo como global.js data. Y puse una cadena allí. Bueno, puedes poner muchas otras cosas complicadas, pero esto es solo un ejemplo. Y luego vas al directorio de código fuente de no, y luego lo construyes con esa opción de configuración. Y luego el ejecutable final que produce el proceso de compilación contendrá un binario que ya tiene la instantánea que contiene esta cosa que pusiste en el global this. Y otra opción que no requiere construir node desde el código fuente es usar la opción de tiempo de ejecución --build snapshot de la ejecutable oficial de node. Por lo tanto, eso podría ser útil si simplemente no quieres construir node desde el código fuente, lo cual puede llevar mucho tiempo.

Así que por defecto, esto genera un blob llamado snapshot.blob en el directorio de trabajo actual utilizando el script dado. Pero también puedes especificar la ruta de entrada/salida con la opción --snapshot-blob. Y cuando lanzas node usando una instantánea personalizada, puedes usar nuevamente esa opción --snapshot-blob como una forma de decirle a node que deserialice un montón de la instantánea personalizada especificada en lugar de configurar un montón Node Core predeterminado. Y eso te ayudará a omitir la compilación de análisis y la ejecución de tal vez tu propio code y te ayudará a correr más rápido. Y ahora, hay otra opción que está en progreso, que es la nueva característica de aplicación ejecutable única. Y la instantánea puede ser superpuesta a eso. Y esto significa que será posible generar una instantánea y agregarla a un solo ejecutable con Node en sí sin tener que compilar Node desde el código fuente. Así que, una vista previa rápida del actual design es, así, el usuario puede crear una configuración JSON como esa, instantánea. Especificas el script principal con snapshot main, la ruta, y luego especificas donde quieres que se escriba la salida. Y luego usas el ejecutable oficial de Node para tomar esta configuración JSON y generar el blob. Y luego copias el ejecutable a tu ruta de destino porque va a inyectar ese blob. Y usas, por ejemplo, la línea de comandos post-ject que es mantenida oficialmente por Node para inyectar ese blob en el binario, que es C allí, aplicación ejecutable única. Y luego después de inyectar el blob en ese binario, eso contendrá una instantánea y Node simplemente sabrá que, oh, tengo una instantánea incrustada en este binario. Cuando se me lance, simplemente inicializaré eso. Y con esto, no tienes que compilar no phone source para usar una instantánea incrustada. Así que eso todavía está en progreso, pero está llegando. Probablemente aterrizará en 20. Y también estamos pensando en, en lugar de hacer todo esto, proporcionaremos algún tipo de utilidad de línea única para obtener una configuración JSON. Y luego genera un solo ejecutable 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 de tiempo de ejecución en el script de instantánea. Así que por defecto, después de deserializar un blob de instantánea, Node refrescará los estados de tiempo de ejecución, como procesar el env y procesar el argv. Y si el usuario code precomputa algo de estos estados o almacena en caché estos estados antes de que la instantánea sea serializada, entonces esto debería ser refrescado durante la deserialización. Así que por ejemplo, si el usuario code calcula algún nivel de debug aquí basado en la variable de entorno nivel de debug como esto en el script de instantánea. Así que podrían haber estado haciendo esto. Cuando están construyendo la instantánea, entonces en tiempo de ejecución, pueden sincronizar esto con la sincronización de instantáneas API que proporcionamos a través del espacio de nombres V8 Startup Snapshot. Así que por ejemplo, en el script de instantánea de inicio, puedes agregar algunas devoluciones de llamada que serán llamadas. Primero será una devolución de llamada que puede ser llamada durante el proceso de serialización para restablecer ese nivel de debug. Y luego añades otra devolución de llamada serializada que puede restablecer el nivel de debug según la variable de entorno configurada en tiempo de ejecución. Y eso te ayudará a sincronizar estos estados de vuelta. O puedes simplemente aplazar el cálculo hasta la serialización si estás construyendo una instantánea.

También existe un getter llamado construyendo una instantánea que puedes usar desde la API para determinar si el code se está ejecutando para construir una instantánea. Y otra API útil es setDigitalizedMainFunction, que nos permite especificar una función principal en la instantánea sin tener que pasar otro script principal.

Entonces, por ejemplo, si la instantánea que tenemos, hay una database de, por ejemplo, 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, puedes pasar un script principal separado que hace el registro. Pero eso significa que necesitaremos una entrada adicional, que también necesita ser analizada y compilada en tiempo de ejecución. Entonces, en su lugar, puedes usar la API de JavaScript, que puede incluir una función principal en la instantánea. Entonces el code de esta función principal también será compilado y serializado en la instantánea. Entonces, un nodo en tiempo de ejecución puede simplemente deserializar esta función principal y simplemente ejecutarla. Entonces ya no necesitamos una entrada adicional. Y también es más rápido, porque ahora no hay necesidad de compilar más code.

Entonces, en resumen, hemos estado integrando instantáneas de inicio en NodeCore para iniciar, para speed up el inicio del núcleo. Y ahora hay soporte experimental para instantáneas de línea de usuario con algunas APIs de JavaScript en el espacio de nombres de la instantánea de inicio de DBA para ayudar a construirlas. Y también estamos trabajando en el soporte para una aplicación ejecutable única así como más características en la instantánea. Bueno, finalmente me gustaría agradecer a todas las personas que han estado contribuyendo a esta característica, incluyendo a Anna, Colin, James, Chen Zhong, Dasham, y muchos otros que estoy olvidando en las diapositivas, lo siento. También personalmente, me gustaría agradecer a Bloomberg e Ingaria por apoyar mi parte del trabajo en esto. Y eso es todo, gracias. Gracias. Gracias. Gracias. Gracias. Gracias. ¿Yo, okay? Gracias, Eversome, ya sabes el trato. Sí, vamos, vamos a tener una charla. Hola, muchas gracias por esa charla. Público, tanto en línea como en la sala, por favor, no duden en hacer preguntas. Slido.com, 1404, o el QR Code, ¿cuál es? Lo mismo da. Déjame sacar las preguntas. Voy a empezar con, mientras estoy faffing alrededor y consiguiendo preguntas y esperando por ellas. Hasta ahora, ¿cuáles has encontrado son los conceptos erróneos comunes en el design, que las personas tienen conceptos erróneos comunes con el design de las Instantáneas de Inicio? Creo que un concepto erróneo común sería que esto está de alguna manera relacionado, la característica en sí es de alguna manera como, la gente confunde las Instantáneas de Heap con las Instantáneas de Inicio mucho.

Utilizaron la misma infraestructura subyacente, como NVA para serializar un montón. Pero son herramientas diferentes para medios diferentes. 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, 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 empezando a aprender también.

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

Bueno, primera pregunta con más votos. ¿Se pueden usar también las instantáneas para iniciar AWS Lambdas más rápido? Así que 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 sea que ejecute Node. Creo que en este caso, recae en Amazon. Entonces, sí, como usuario de esto, yo era un incrustador de Node, eso está fuera de tu control, pero si eres alguien que puede ejecutar Node tú mismo, o como si pudieras pasar flags adicionales a Node, entonces sí, puedes hacer eso. Genial, gracias.

La siguiente pregunta es, ¿existe alguna posibilidad de filtrar accidentalmente variables de entorno sensibles a la instantánea durante el tiempo de construcción? ¿Cuál? Oh, lo siento, podemos repasarlas 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 construcción? Así que en Node core, tenemos algunas afirmaciones internas para asegurarnos de que no las filtras. Así que también estamos considerando exponer esto al uso de la tierra. Pero si estás deserializando una instantánea de inicio, normalmente no llegas a verlas. Es muy difícil que llegues a verlas porque Node las refrescará todas. Así que si de alguna manera pones algo allí, eso es posible. Pero también puedes refrescarlas más tarde. Muy bien. Sí, aunque imagino que si la gente lo hiciera, probablemente no sería un acto intencional. Definitivamente algo de lo que he sido culpable. ¿Cuánto se ha probado que se logra un impulso de inicio para las instantáneas de inicio de usuario? Así que literalmente hay un compilador de TypeScript en Node Core como un accesorio de prueba para probar que podemos hacer una instantánea del compilador de TypeScript. Así que eso es como si todavía consigues alrededor, todavía está en el rango que mencioné. Es como dos veces más rápido. Antes era como 200 milisegundos, por ejemplo, en mi máquina de prueba.

Y luego, cuando activas la instantánea, es como 100 milisegundos. También depende un poco de cuánta inicialización haces en tu aplicación. Si haces mucho, entonces vas a ahorrar más porque ni siquiera vas a ejecutar code para inicializar tu aplicación, solo vas a destruir las cosas. Entonces sí, en general, diría que puedes obtener hasta dos veces más rápido.

Genial, gracias. Tenemos tiempo para una más y tenemos un montón que tienen dos marcas. Vamos a ir con la que está aquí en la parte superior. ¿Cuáles son las limitaciones de las instantáneas? Por ejemplo, una conexión TCP a una database no será serializada o tal vez hay otras cosas a considerar también.

Sí, eso es lo que mencioné antes. Como, porque por ejemplo, eso sería una operación asíncrona que necesita ser finalizada 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 también eso no es actualmente un objetivo de esta característica. Entonces tienes que asegurarte de que no hay solicitudes asíncronas antes de tomar la instantánea y necesitas resolver las promesas. Y sí, esas son las limitaciones actuales de estas instantáneas de inicio. Sí, y espero empezar a construir 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 code en una instantánea para optimizar el inicio de toda la aplicación? Una cosa que puedes hacer es simplemente envolver todo en una función que no invocas realmente cuando construyes la instantánea. Y luego pones esa función como la función principal de deserialización en la instantánea. Entonces cuando deserializas, ejecuta toda la función. Eso es factible, pero probablemente no obtienes suficiente caché de compilación con eso porque si no están en el nivel superior, VA compilaría selectivamente algunos de esos pero no todos. Hay algunas hints. 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. Caen al fondo de la página, pero nos hemos quedado sin tiempo. Así que recordaré a todos, tanto en la sala como en línea, que la sala de preguntas y respuestas del orador es a donde deben ir para seguir haciendo preguntas sobre este tema. El espacio físico está junto a la recepción a la izquierda de la puerta como si estuvieras mirando para salir y los que están en línea, pueden usar la sala de preguntas y respuestas en el chat espacial, pero por favor únanse a mí en un enorme aplauso para Joy. Muchas gracias, qué fantástica charla. Gracias. Gracias. Gracias.