PRNext modo de suspensión: reduce el RAM inactivo y gestiona el despertar

Una herramienta interna puede estar disponible para unas pocas personas sin recibir una solicitud durante horas. Sus procesos todavía ocupan memoria. PRNext puede retirar trabajadores de nodo inactivos y recrearlos cuando llega una solicitud de procesamiento.

Esto cambia parte de la memoria inactiva por el trabajo de despertador. Esta guía explica las medidas, configuraciones y comprobaciones necesarias para decidir si la bicicleta se adapta a su aplicación. La configuración describe PRNext 0.1.18-alpha.

¿Qué sigue funcionando durante el sueño?

En el mecanismo medido aquí, el servidor Rust sigue escuchando mientras los trabajadores del Nodo se retiran después de un intervalo de inactividad. La siguiente solicitud que requiere prestación recrea los trabajadores necesarios. Esto difiere de detener el VPS o suspender el sistema operativo.

El comando de host local prnext también puede suspender una aplicación completa detrás de una puerta de enlace. El servicio PRNext Host administrado vuelve a ser otra capa. Los valores aquí describen la jubilación de los trabajadores del servidor de aplicaciones, no el costo total de esos otros mecanismos.

Lo que muestra la sonda de despertador

En el VPS pequeño de la campaña 29 de octubre, se probó una página SSR simple con un intervalo de inactividad acelerado de dos segundos. Después de que los trabajadores se jubilaron, el PSS del árbol de procesos cayó a aproximadamente 10.5 MiB. Para mantener calientes a los trabajadores se utilizó 106.8 MiB en esa sonda.

La solicitud de despertador tardó aproximadamente 1,130 ms, en comparación con 22.6 ms cuando estaba caliente. Cada escenario tuvo solo una observación. La sonda utilizó el candidato de desarrollo identificado, no una nueva medición del paquete npm final o de todo el VPS. Estos valores ilustran la compensación sin predecir su aplicación.

Lea la sonda, la identidad del candidato y las condiciones de medición.

Mantenga a los trabajadores calientes cuando la latencia es más importante

Después de construir, --prewarm prepara el marco antes de aceptar solicitudes. No ejecuta páginas de aplicaciones ni API y no evita una posterior retirada inactiva. --worker-idle-segundos 0 conserva los hosts de procesamiento usados ​​en lugar de retirarlos por inactividad.

El siguiente comando solicita un inicio preparado y retiene a los trabajadores una vez utilizados. No promete que una ruta nunca visitada haya cargado todas las dependencias. Mida también la primera visita a rutas costosas y el comportamiento después del despliegue.

Terminal
npx --no-install prnext build
npx --no-install prnext start --hostname 127.0.0.1 --port 3001 --prewarm --worker-idle-seconds 0

Probar un intervalo de inactividad explícito

Un intervalo 60-second explícito hace que el ciclo sea fácil de observar en una instancia aislada. Visite la página, espere a que los trabajadores se jubilen y mida la próxima solicitud. Sesenta segundos es un ejemplo de configuración, no una recomendación para todos los sitios.

Una sonda de salud que solicita continuamente una ruta de procesamiento puede impedir el sueño. Verifique qué solicitudes de monitoreo y cómo las maneja el servidor. Pruebe también varias visitas que llegan durante un despertar: una sola solicitud no describe ese pico.

Terminal
npx --no-install prnext start --hostname 127.0.0.1 --port 3001 --worker-idle-seconds 60

Mantenga los datos duraderos fuera del proceso

Al jubilar a un trabajador se elimina su estado en memoria. Las sesiones realizadas únicamente en ese proceso, los cachés de aplicaciones y el trabajo en segundo plano pueden desaparecer. Los datos que deben sobrevivir necesitan un almacenamiento duradero o un servicio externo adecuado.

Antes de habilitar la suspensión, pruebe el inicio de sesión, una escritura y una lectura después de despertarse. Consulta también las suscripciones, los temporizadores y el trabajo asincrónico. Una solicitud completa no prueba que el trabajo en segundo plano sin seguimiento esté protegido contra el retiro del proceso.

Elija entre los períodos de inactividad de su aplicación

Las demostraciones, los entornos de vista previa y las herramientas visitadas ocasionalmente son candidatos a investigar. Para viajes en los que la primera respuesta debe ser rápida, puede ser preferible contar con trabajadores cálidos. El tráfico real, las sondas de seguimiento y la frecuencia de activación determinan el resultado.

Compara el tiempo de sueño, la memoria liberada y la latencia de las visitas que despiertan el servicio. Para múltiples aplicaciones, mida los picos simultáneos antes de concluir que un servidor puede albergar más proyectos. Nuestra campaña no establece ni un recuento adicional de sitios ni un ahorro en la facturación.

Presupuesto para múltiples aplicaciones React en un VPS

Fuentes y lecturas adicionales

volver al blog