What does HackerNews think of pm2?

Have you tried using a process manager like supervisord[1] or pm2[2]? The former has a pretty clean declarative interface that you could view as a replacement for something like a docker-compose file or a k8s pod config.

You don't get any containerization/isolation benefits obviously, but it sounds like you've already accepted that.

[1] http://supervisord.org/ [2] https://github.com/Unitech/pm2

Promises and now async/await go a long way to remedy the discrepancy between synchronous exceptions and asynchronous errors, by helping ensure that they both end up as promise rejections (as long as promises/async functions are your de facto async abstraction) while also being handleable with try/catch. The Koa framework (and in the future Express I believe) is designed around this concept, so middleware-level promise rejections can be handled in a single place, and by default simply produce an HTTP error response. It is a shame that it's going to take a while for the Node stdlib to catch up, however.

Also I thought something like PM2 (https://github.com/Unitech/pm2) or Forever (https://github.com/foreverjs/forever) was pretty much standard for production Node apps?

The idea of systemd isn't bad. What's annoying is the friction involved in using it.

It's just a shade too ornate, a little too magical, in both cases only by a small degree, but it's an important one.

Creating a workable systemd init script is actually pleasant. Getting it running is easy. Checking for errors with status is nice, but searching the logs is annoying.

pm2 (https://github.com/Unitech/pm2) has a neat feature where you can watch logs easily, someting that systemd should totally steal and pack into journalctl, like "systemctl logs sshd" shows it in real-time, an alias to the obnoxiously verbose "journalctl -u sshd -f"

How about clustering the Node server? By default, node uses only one process. Making the server use all available processes requires a bit more work (see https://nodejs.org/docs/latest/api/cluster.html or https://github.com/Unitech/pm2) but will probably do more justice to Node.js vs Python.

> Please note that this describes something you would do for a toy project.

Exactly my thoughts... this is for toy projects.

It's 2016 and we have proper tools like PM2 [0], StrongPM [1], or even better, Serverless [2] (this is only for AWS but sooo cool) ...

[0] https://github.com/Unitech/pm2

[1] http://strong-pm.io/

[2] https://github.com/serverless/serverless

In Java (and C, and C#, and a bunch of others), if your server has 16 cores, you will be running a single process on 16 cores and probably 32 concurrent threads, and they can all access some shared data (notably, database cache) with low intra-process latency, using some simple sharing primitives.

You're right but there are downsides to this approach.

First, you're creating a single point of failure. If any part of the application crashes for whatever reason it brings everything down with it.

If you intend to have fault tolerance, maintain uptime during updates and/or provide A/B testing capabilities, you'll still require at least a redundant server and a load balancer to funnel incoming requests between the two.

Second, sharing memory across cores comes at a cost.

A simple mutex/lock strategy will work but will be inefficient as it blocks on both reads and writes to shared data.

You could choose to use a CAS (Compare and Swap) strategy to avoid locks altogether. As long as you can ensure your models as well as all of the internal data structures they use are immutable and thread safe. Considering the nested nature of OOP inheritance as well as language level access restrictions on classes/methods/members, it can be difficult/impossible to ensure immutability without hand-rolling your own data structures.

Third, sharing state across contexts comes with hidden costs that need to be taken into consideration. For instance, if the shared state for all threads is updated (ie a cached value is added/updated) it will invalidate the L1, L2, and L3 caches on the processor. The overhead of cache invalidation increases in proportion to the number of cores/processors involved.

Source: http://www.drdobbs.com/architecture-and-design/sharing-is-th...

I assume you have experience with multi-threaded programming. I won't touch on the transient nature and inherent difficulty in replicating bugs introduced in multi-threaded programming. Other than to say, I've done enough of it in the past to develop a very healthy fear.

-----------------------

What about Node...

You're right to assume that Node instances will run as a cluster. Ideally one instance per core, to reduce context switching and prevent cache invalidations between the foreground and background workers internal to a Node instance.

As for a cache layer between the DB and Node instances. Since communication between Node instances will happen at the OS level via IPC, there's no benefit to implementing a global cache internal to the Node application. Instead, it would be better to offload the responsibility to a separate service that is specialized for caching (ex redis). This reduces the complexity of the application, surface area for bugs, and development time.

Load balancing will be required anyway, so it makes sense to use Nginx. Nginx is much more fault tolerant, providing sane limits for incoming requests, as well as the ability to define routes that short-circuit requests to static files.

What's interesting about deploying a Node cluster is its 'redundant by default' nature including auto-respawning of cluster instances https://www.npmjs.com/package/express-cluster.

If you desire a more granular control over cluster management you could use https://github.com/Unitech/pm2.

To make this work the servers themselves will need to be stateless. Which means, handling session management requires additional work-arounds.

-----------------------

Java is likely 'faster' when deployed in a strictly vertically scaled setup. Node.js is more geared to horizontal scaling by default. Just like Java now includes good support for async request handling, I have no doubt the community will design tools that also favor scaling out.

Either way, I don't think raw performance is going to be the deciding factor. Choice of platform is a business decision that depends on the resources and skills and/or preference of the team responsible for development.

You can use PM2 pretty easy https://github.com/Unitech/pm2

Or better yet, use PM2 instead of forever. As someone who has spent years with forever, I was ultimately happy to drop it into the trash after discovering PM2.

https://github.com/Unitech/pm2

It's significantly more advanced. Create a "process.json" file in your project directory (As you would a nodemon.json), like so:

    {
    		"name"				: "someApp"
    	,	"script"			: "./index.js"
    	,	"node_args"			: "--harmony"
    	,	"log_file"			: true
    	,	"merge_logs"			: true
    	,	"exec_mode"			: "fork_mode"
    	,	"ignoreWatch"			: [
    			"\\.(css|styl|log)$"
    		,	"static/.*"
    		,	"views/.*"
    		]
    }

This will show logs intertwined just like forever, merge logs from seperate forked processes and you can even throw in watch rules like nodemon.

    pm2 start process.json

Then to make all of your processes always restart do this:

    pm2 save
    pm2 startup centos

Replacing centos with your distro. Couldn't be easier. There are a lot of other features I don't use (such as deployment, which I suspect will be significant for some big websites), but definitely consider dropping forever/supervisord and even nodemon in favor of PM2. They merge pull requests quickly it seems, too.

The only issue I've had is that for some reason using the "watch" functionality on a lot of files causes massive CPU overload, or at least it did, it may be fixed by now. If you're going to use the watch functionality (to reload stuff like nodemon), consider whitelisting and not blacklisting files.

Maybe that one? https://github.com/Unitech/pm2