CloudLinux ha añadido una opción en beta para que las aplicaciones Node.js en servidores cPanel que usan Node.js Selector y Phusion Passenger puedan «despertar» a partir de una instantánea (snapshot) de proceso en lugar de efectuar un arranque en frío completo. El resultado es que la primera petición tras un periodo de inactividad tarda menos en responder.
Qué cambia y cómo funciona
Hasta ahora, cuando Passenger reanudaba una aplicación que había sido detenida por inactividad, realizaba un arranque en frío completo de Node.js. Con la nueva función, la primera vez que se inicia la aplicación con la opción activada, Passenger pausa el proceso de Node.js justo antes de cargar el código de la aplicación y guarda ese proceso pausado en disco como snapshot.
Cuando la aplicación está parada por inactividad y llega una nueva petición, Passenger restaura la instantánea en lugar de iniciar un proceso nuevo. La ejecución restaurada vuelve a las limitaciones del LVE y a CageFS del cuenta, y a partir de ahí carga el código y dependencias de la aplicación exactamente como en un arranque en frío normal. Por tanto, los cambios en el código (por ejemplo, modificar package.json o reinstalar dependencias) entran en vigor como siempre, porque la carga del código ocurre tras la restauración.
Impacto en rendimiento y uso de recursos
Según pruebas de laboratorio de CloudLinux, el primer request tras una parada por inactividad puede tardar entre un 15% y un 60% menos, dependiendo de cuánto haga la aplicación al arrancar. La mejora más significativa se obtiene en aplicaciones cuyo propio inicio hace poco trabajo antes de atender la primera petición; la restauración evita el tiempo de arranque del binario de Node.js y el lanzamiento desde Passenger, pero no omite la carga del código de la aplicación, las dependencias ni las conexiones a bases de datos.
Esto cambia la ecuación del tiempo de espera frente a la cantidad de aplicaciones en memoria: al acortar el arranque en frío, los administradores pueden configurar un tiempo de inactividad más corto (PassengerPoolIdleTime) y así detener antes procesos ociosos sin penalizar tanto a los visitantes. En la práctica, permite ajustar mejor la densidad de aplicaciones Node.js por servidor.
Administración, requisitos y consideraciones
- La función se activa con una directiva de Apache que puede aplicarse al servidor entero o a aplicaciones concretas; también puede controlarse desde el .htaccess del usuario.
- Si no existe aún snapshot o si la restauración falla, Passenger iniciará la aplicación de forma normal.
- Reiniciar la aplicación, cambiar su versión de Node.js o modificar archivos clave de dependencias invalida el snapshot y obliga a crear uno nuevo en el siguiente arranque.
- Los snapshots se almacenan en /var/cache/passenger-criu; CloudLinux indica que ocupan en torno a 14 MB por aplicación en sus pruebas. El directorio es de acceso root y queda fuera de las cuotas y de las copias de seguridad de las cuentas.
- Existe un trabajo diario que elimina snapshots sin uso durante 30 días, pero no hay un límite total automático: conviene vigilar el directorio como se hace con cualquier caché.
- La tecnología de bajo nivel usada es CRIU (Checkpoint/Restore In Userspace), que CloudLinux ya emplea para PHP en mod_lsapi; adaptar CRIU a Node.js requirió cambios en la compilación de CloudLinux para restaurar procesos multihilo dentro de CageFS.
Estado, opt-in y pasos recomendados
La característica se encuentra en beta y está desactivada por defecto; las aplicaciones continúan arrancando como antes hasta que el administrador la active. La actualización instala un servicio del sistema (criu) que se habilita y arranca automáticamente, aunque el snapshot solo entra en juego cuando la directiva se activa. Si se desea deshabilitar el servicio, CloudLinux propone parar y desactivarlo con systemctl.
Recomendaciones prácticas para administradores y dueños de sitios web:
- Si gestionas servidores con múltiples aplicaciones Node.js, prueba la beta primero en entornos de staging o en un subconjunto de aplicaciones para medir la mejora y el uso de disco en tu infraestructura.
- Vigila el directorio /var/cache/passenger-criu y define procedimientos de monitorización o limpieza si alojas muchas apps.
- Ten en cuenta que no reduce la carga que la propia aplicación haga al arrancar (conexiones a bases de datos, carga de ficheros, compilaciones), por lo que las apps que realizan mucha inicialización seguirán notando parte del coste.
- Comunica a desarrolladores del proyecto que los cambios en código y dependencias se aplican con normalidad tras reinicios u operaciones que invaliden el snapshot.
CloudLinux solicita feedback de los usuarios de la beta y ofrece soporte para quienes necesiten ayuda con la función.
Lee también:
- VodafoneThree inicia en Londres el despliegue del radio AIR 3266 de Ericsson, preparado para IA
- AlmaLinux publica paquetes de prueba para corregir error ‘no buffer space in script copy’ en nginx
Fuente: CloudLinux
