Nodejs Production Deployment

Recently, we’ve embarked on a journey down the nodejs path.

One of our new projects is written entirely in nodejs.  It was fun learning nodejs and it was a good fit for the project.  In the end, we achieved a very stable and very fast product that I think will serve us well.

However, it wasn’t all sunshine and roses.  The biggest hurdle we had to overcome was how to deploy our product to our production environment and maintain the high service standards that we require of all our products.  Nodejs’s biggest issues for production deployments are utilizing multi-core hardware resources and the fact that the application is the service.

The Application is the Service

This is an issue for production deployments because it means that the developer is developing the service that runs all the requests not just the script that serves a single request.  That means that a mistake on the developer’s part can take the entire service down rather than just the request where the mistake occurs.  There’s not a lot that can be done about this (as it’s part of the design of nodejs), but it can be mitigated by running multiple instances and load balancing them behind a Virtual IP address (VIP).

Utilizing Multi-Core Hardware

As nodejs is a single threaded application it cannot utilize the computing resources available to multi-core systems.  It is necessary to do this as most nodejs http frameworks (even express) load static content with blocking calls to the file system which effectively kills your page load times on a website.  This is generally solved by running multiple instances of the application on each server (i.e. via supervisor), but this causes other issues such as: binding to the same port(s) and what happens when you use sticky sessions with your load balancer (hint: you’re back to using one instance to load everything again).

Our Search

Coming from a PHP background we naturally went looking for nodejs’s equivalent of php-fpm (PHP’s Fast-cgi Process Manager).  For PHP, php-fpm solves all of the issues above so we were hopeful that there would be something similar for nodejs (especially since there are some very large organizations using it).  Our hopes were dashed.  There was nothing like php-fpm for nodejs.  Oh there were nodejs process managers and clustering modules, but they all required us to implement something per application or were abandoned or lacking other requirements.  This really seemed crazy.  How could it be that there was no way to easily provide a single point of entry to a pool of processes running our application?  We did some research and found that nodejs does support this type of access pattern with the built in cluster module, but it is just the foundation and still needs a house.

Our Solution

We wrote our own nodejs process manager based on the nodejs cluster module with the goal of being the nodejs equivalent of php-fpm.

Introducing node-pm, a simple and easy way to run nodejs applications in production environments with everything you’d expect from a product running in a high traffic web environment.  It’s released under the MIT license and you can check out the source on github: http://github.com/sazze/node-pm

It’s really easy to get started.  Just execute the following two commands on the command line:

npm install -g node-pm
node-pm app.js

The last command above will run your application (app.js) using node-pm.  The effect is that node-pm will spawn 1 process per CPU on your system that all listen on the same address and port to serve requests.  node-pm will also enforce a 30 minute maximum lifetime for each process and gracefully restart them to help mitigate the effects of memory leaks.  These (and many other) settings are fully configurable and you can tweak them to match your application and environment.  Check out the docs (or run node-pm with no arguments) to see the full list of options.

We are running the latest version of node-pm in production (0.8.0 as of this writing).

Please feel free to check out node-pm.  We’d love your feedback.