Mode sleep PRNext : réduire la RAM au repos et gérer le réveil

#Ce qui reste actif pendant la veille

Dans le mécanisme mesuré ici, le serveur Rust reste à l’écoute et les workers Node s’arrêtent après une période d’inactivité. La prochaine requête ayant besoin du rendu recrée les workers nécessaires. Ce cycle diffère d’un arrêt du VPS ou d’une suspension du système.

Le framework possède également une commande locale prnext host, qui peut mettre une application entière en veille derrière une passerelle. Le service managé PRNext Host est encore une autre couche. Les valeurs de cet article concernent l’arrêt des workers du serveur applicatif et ne chiffrent pas ces deux autres dispositifs.

#Ce que montre la sonde de réveil

Sur le petit VPS de la campagne du 29 octobre, une page SSR simple a été testée avec un délai d’inactivité accéléré à deux secondes. Après arrêt des workers, la PSS de l’arbre de processus descend à environ 10,5 Mio. Le maintien à chaud utilise 106,8 Mio dans cette sonde.

La requête de réveil prend environ 1 130 ms, contre 22,6 ms en maintien à chaud. Chaque réglage n’a fait l’objet que d’une observation. Il s’agit du candidat de développement identifié, pas d’une nouvelle mesure du paquet npm final ni de la consommation totale du VPS. Ces valeurs illustrent le compromis sans le généraliser à votre application.

Consulter la sonde, le candidat et les conditions de mesure

#Choisir la réponse chaude quand la latence prime

Après compilation, --prewarm prépare le framework avant d’accepter les requêtes. Cette préparation ne lance pas les pages ou API métier et n’empêche pas une mise en veille ultérieure. Le réglage --worker-idle-seconds 0 conserve les hôtes de rendu utilisés au lieu de les arrêter pour inactivité.

La commande ci-dessous demande un démarrage préparé et un maintien à chaud des workers utilisés. Elle ne promet pas qu’une route jamais visitée a déjà chargé toutes ses dépendances. Mesurez aussi la première visite d’une route coûteuse et le comportement après un déploiement.

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

#Tester un délai de veille explicite

Pour observer le cycle, un délai explicite de 60 secondes facilite un essai sur une instance isolée. Visitez la page, attendez l’arrêt effectif des workers, puis mesurez la requête suivante. Le chiffre 60 sert de réglage d’exemple et ne constitue pas une recommandation pour tous les sites.

Une sonde de disponibilité qui appelle continuellement une route de rendu peut empêcher la veille. Vérifiez ce que votre supervision demande et comment le serveur le traite. Testez aussi plusieurs visites arrivant au même réveil : un cas isolé ne décrit pas ce pic.

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

#Sortir les données durables des processus

L’arrêt d’un worker supprime son état en mémoire. Une session stockée uniquement dans ce processus, un cache applicatif ou une tâche de fond peuvent donc disparaître. Les données à conserver ont besoin d’un stockage durable ou d’un service adapté.

Avant d’activer la veille, parcourez une connexion, une écriture et une relecture après réveil. Contrôlez aussi les abonnements, timers et travaux asynchrones. Une requête terminée ne prouve pas qu’un travail de fond lancé sans suivi est protégé contre l’arrêt du processus.

#Choisir selon les périodes creuses de votre application

Les démonstrations, environnements de prévisualisation et outils consultés ponctuellement sont des candidats à étudier. Pour un parcours où la première réponse doit rester rapide, le maintien à chaud peut être préférable. Le trafic réel, les sondes et le nombre de réveils déterminent le résultat.

Comparez le temps passé en veille, la mémoire libérée et la latence des visites qui réveillent le service. Pour plusieurs applications, mesurez leurs pointes simultanées avant de conclure qu’un serveur pourra en héberger davantage. Notre campagne ne fournit pas un nombre de sites supplémentaires ni une économie de facture.

Budgéter plusieurs applications React sur un VPS