If each website is its own `node.js` process

Question

We host about 150 websites (possibly scaled to 300+), which we plan to transfer to node.js Most sites have fairly low traffic and page views per month.

Should each website be its own node.js process, or should we serve all websites using the same node.js process (or a small set of load-balanced processes). Is there a technical limit or a reasonable limit on the number of node processes per server?

Process on the site: Feels ineffective, but I do not know if it is really ineffective. Ensure that one buggy site does not affect other sites.

Kernel process / small set of processes: Probably high performance, but what happens when I need to update the code base of sites, will it not be deleted on other sites? In addition, code errors on one site affect other sites.

Ideally, I would prefer one process per site so that we can host all sites from each production server. Thus, with an increase in load, we can simply deploy another identical working server and balance the load between them without having to arbitrarily say that SiteA goes to ServerA, and SiteB goes to ServerB. Any node.js gurus available to offer some wisdom?

All static file requests will probably be handled by Nginx or something like Varnish.

Answer 1

There are a lot of problems. The answer to the big picture is that it depends ... as it always happens when you bring “performance” to the discussion. In this case, the easiest way to get a solid Node is to note the following basic facts about NodeJS, and I will also comment on their consequences, as they relate to your questions.

• The concurrency that you get with Node really works in certain situations, namely in heavy I / O. What we are talking about minimizes downtime while waiting for the next request. Because of this, Node works fine in an environment where the machine has one process per core. Node really helps maximize the number of CPUs available to handle requests under heavy load. At the same time, if you have literally another ZERO operation in your even cycle, you can see a slight increase in performance (in terms of the maximum number of requests / second / processor core) due to the presence of several Node processes per core. But I have never seen any benefit from increasing this number in the past. Even in conditions when the entire cycle of events was literally just a file server.

• About the process for commenting a site. This is a bad idea for many reasons. Firstly, a server consisting of Node can process thousands of requests per second. Our servers with company names are omitted, hosted via Amazon EC2 on medium clusters (many sheep, CPU clock, 4 cores), as a rule, about 3,000 requests per second per cluster do not work. Our servers do the honest work of the processor, for simple file servers I am sure that you can do much better. Strictly speaking, of course, for each site you can submit more requests, quickly launching each site in its own process / core / escalation! But this is not necessary because of the cost and complexity of complicating your architectural point of view. I would recommend investing in an installation with lots of RAM. The ability to cache frequently requested files will lead to the fact that your performance will be infinitely greater than starting a large number of processes for this machine.

• In general, RAM. The number of processes that you want to run for a given kernel depends on two factors. First, how much synchronous work has been done in your event loop. The more synchronous operation, the more time between this request and the event loop will be ready to send the next. If you have a busy cycle, you will find yourself in a situation where you need more processes / CPU Core. Another that may affect this, especially true for file servers, is the amount of RAM. Node works much better in a high noise immunity environment, but you can say that about ANY file server in fact ... What this has to do with this is the number of active asynchronous operations. One drawback of the Node path works, it is under heavy loads, you can immediately get a large number of event handlers. This is great for concurrency / simplicity, however, if your server is busy waiting for a lot of asynchronous disk / I / O, it will slow down and crash much earlier than if you had a lot of RAM. If you do not have enough RAM to handle all of these event handlers, you will want to stick to 1 process / kernel. Otherwise, it is easier for Node to deploy many event handlers and crash again sooner than otherwise.

Actually, I don’t have enough information to tell you what you should do. It completely depends on the architecture of your specific server, sites, the size of your sites, the amount of data ... etc. But these three parts of knowledge are the main things that will help you maximize the capabilities of the Node server. Honestly, your idea of ​​load balancing, mixed with the above considerations, should be good for you. Of course, micro-optimizations are possible, but if you do, you should easily see requests / seconds in thousands before you start an emergency due to conditions like DDOS.

Answer 2

No, do not do this. Be more simple! And check out http://12factor.net/ .

Several hundred processes are nothing compared to the simplicity that you otherwise lose. It would be a scary decision at so many levels to have more than one site (or, a "logical application unit") served by a single Node process.

If you ask this question, you may need to study Node before you upgrade to Node. Error handling and problem separation are more complex in Node than in other situations. In particular, neither the domain API nor the cluster are mature. But it’s actually a philosophy of clean and easy application deployment that you would violate. I could go on and on.