为什么Heroku在Node.js中推荐Foreman？

Question

This may be a silly question for more experienced Node and back-end guys, and let me hope there are no long debates here, but ...

Why does Heroku recommend using procfile and launch a separate web and a separate worker process with foreman?

Link: https://devcenter.heroku.com/articles/node-best-practices

Procfile:

web: bin/web
worker: bin/worker

Here is my thinking and 3 reasons they would recommend it, but I'd like somebody to help me understand if I am on the right track...

Let's imagine this scenario:

1) A "web" app is for handling APIs 2) A "worker" app is for stuff that takes time or requires a retry on failure. Ex. sending an e-mail. An API just doesn't want to wait long for an HTTP response, so yeah. 3) Then, there is a hypothetical "web + worker" app that does both.

A) Is having a separate web and worker apps better for performance?

I don't see any performance benefits in having the app separated into aa separate web and worker apps. In a 2 CPU machine, if we have 2 web processes and 2 worker processes, due to single-threaded nature of Node.js, it will be just as performant as having 2 processes of a "combined app that does both web + worker job".

B) Is separating for the sake of readability of the code?

Maybe, I can agree with this one.

We can have classes, functions, etc.. that can be only used in workers, and some that can be only used in the web part.

C) Is it for robustness?

In theory, yes... Let's say for the sake of example, 1. If we have a 2 CPU machine, 2. We don't separate into web and worker, and the app's code does both "worker and web" work, 3. We spin 2 processes of that app with the help of clusters, 4. we schedule 2 very long and time-consuming tasks (CPU BOUND, without any I/O, just for the sake of example so it actually hangs a Node process), the whole app just hangs because two processes are busy handling these 2 tasks.

However, in this case, I would create 2 web processes and just 1 worker process. That way if worker is super busy, the web on the remaining process can still take API requests and respond to clients. I think so...

Is my thinking correct? Why is Heroku recommending splitting Node.js code into worker and web apps?

Answer 1

The zen of Heroku is The 12 Factor App . Heroku encourages separate process types for web and workers, that will run on separately scalable dynos. See https://12factor.net/concurrency .

In addition, for node.js apps, Heroku makes recommendations and provides support for optimizing application concurrency using node.js clustering , to maximize performance of node.js apps running on multi-core dynos. This enables you to squeeze maximum performance out of each dyno instance, before resorting to vertical scaling (ie increasing compute resources allocated to your dynos) or horizontal scaling (ie increasing the number of dyno instances per process type in your app).

Note that it is theoretically possible for you to run both Web and Worker processes in a single dyno, but it is simply not recommended. In your procfile you could have some "main" process type that when run would spawn additional processes. However, then you will get into issues such as how to monitor whether your processes are running properly, and other issues. All of that is taken care of you automatically by Heroku, if you "play by the rules" (see eg Dyno crash restart policy ).

The bottom line of this is: You might be able to reduce your dyno costs by running both Web and Worker processes in a single dyno, but that is really not what Heroku intends for you to do, and if you do so, you may encounter unexpected problems.