Faster wake-ups for idle Node.js applications on CloudLinux

Node.js applications on cPanel servers running CloudLinux can now wake from a snapshot, so the first visitor after a quiet period waits less. Node.js Selector runs these applications through Phusion Passenger, an application server that stops an application nobody has visited for a while and starts it again on the next request.

Until now, each of those starts was a full Node.js cold start. Passenger now restores a saved copy of a freshly started Node.js process instead, then loads the application as usual.

In our lab tests, the first request after an idle stop took about 15% to 60% less time, depending on how much the application does when it starts. One Apache directive turns it on, for the whole server or one application at a time. Currently in beta.

Why it matters on a hosting server

A Node.js application holds a process, and its memory, for as long as it’s awake. That makes Passenger’s idle timeout (PassengerPoolIdleTime) a trade between how many applications a server holds and how long their visitors wait:

• A short timeout frees idle applications’ memory sooner, so more Node.js applications fit on the server, but the next visitor to each stopped application waits for a cold start.
• A long timeout spares those visitors, but idle applications keep their memory while nobody uses them, so fewer fit on the server.

Snapshots shorten the cold start, so the short timeout costs visitors less. You can stop idle applications sooner and fit more Node.js applications on the same server, and the visitor who wakes one waits less than before.

How much faster depends on the application. A restore skips Node.js’s own startup and Passenger’s launch of it. The application’s own startup still runs on every wake with loading its code and dependencies, and connecting to its database. So the less an application does before it serves, the more it gains.

How it works

The first time an application starts with the feature on, Passenger pauses the new Node.js process just before it loads the application’s code, and saves the paused process to disk. That’s the snapshot. The process then carries on and serves as usual.

When the application has been stopped for being idle and a request arrives, Passenger restores the snapshot instead of starting a new Node.js process. The restored process goes back into the account’s LVE limits and CageFS, then loads the application exactly as a cold start would. Because the application’s code loads after the restore and isn’t part of the snapshot, code changes go live just as they do without snapshots.

▼ Request arrives

Without a snapshot

■ Node.js starts ■ Application loads

With a snapshot

■ Snapshot restored ■ Application loads □ Time saved

Illustrative timing. The saving depends on how much the application does when it starts.

If there’s no snapshot yet, or a restore fails, Passenger starts the application normally. Restarting the application (from Node.js Selector, for example), switching its Node.js version or changing its package.json or lock file discards the snapshot.

The technology underneath is CRIU (Checkpoint/Restore In Userspace), which CloudLinux already uses for PHP in mod_lsapi. Bringing it to Node.js took changes to CloudLinux’s own CRIU build, so that it can restore Node.js’s multi-threaded processes inside CageFS.

Before you turn it on

Snapshots use some disk space. Each application gets one, about 14 MB in our tests, stored in /var/cache/passenger-criu. The directory is root-only and outside every account, so snapshots count against no quota and stay out of account backups. A daily job removes snapshots unused for 30 days, but nothing caps the total. Watch the directory as you would any cache.

Account owners can opt their applications in or out. The directive also works in an application’s .htaccess.

The update starts a system service. The criu-lve package that comes with the update enables and starts the criu service, whether or not you turn snapshots on. If you want to disable the service, run systemctl disable --now criu.service.

Availability

• cPanel servers on CloudLinux 7, 8, 9 and 10, with cgroup v1 or v2
• Node.js applications served by Passenger under Apache (not Passenger under NGINX or Standalone, and not LiteSpeed)
• ea-apache24-mod-passenger 6.2.1-1.cloudlinux.3 or later (CloudLinux 9 and 10) or ea-ruby27-mod_passenger 6.2.1-1.cloudlinux.2 or later (CloudLinux 7 and 8)
• criu-lve 4.2-6 or later (3.13-12 on CloudLinux 7)

Get started

Snapshots are off by default, so applications start as they do today until you turn them on.

1. Update the packages from the beta repositories: # CloudLinux 9 and 10 yum update ea-apache24-mod-passenger --enablerepo=cl-ea4-testing --enablerepo=cloudlinux-updates-testing # CloudLinux 7 and 8 yum update ea-ruby27-mod_passenger --enablerepo=cl-ea4-testing --enablerepo=cloudlinux-updates-testing
2. Turn it on with PassengerCriuEnabled on: Each application takes its snapshot the next time it starts; there’s nothing to do per account.
3. — For every Node.js application on the server, add the line to an Apache include and restart Apache. To leave one application out, set PassengerCriuEnabled off for it as below.
4. — For one application, add the line to a block for its document root, or to its .htaccess. For an application created in Node.js Selector, put it outside the CLOUDLINUX PASSENGER CONFIGURATION block, which Node.js Selector rewrites whenever the application’s settings change.
5. Check that it works. passenger-status shows a line such as CRIU : 4 restored, 1 fell back (no image 1). “Restored” counts wakes served from a snapshot and “fell back” counts normal starts; a “no image” fallback is expected after an application’s first start or a restart. The application’s error log records CRIU: checkpointed app when a snapshot is taken.

The Node.js snapshots documentation covers the rest: every directive, where snapshots are stored, how to turn them off, and the known limitations.

If you run many Node.js applications per server, the Shared node_modules Store, also in beta, keeps one copy of each npm package version per server.

Both are betas, so tell us how they run on your servers in this short form, and if you need help, contact our support team.