Scaling Node.JS across multiple cores / servers

Ok so I have开发者_如何学JAVA an idea I want to peruse but before I do I need to understand a few things fully.

Firstly the way I think im going to go ahead with this system is to have 3 Server which are described below:

The First Server will be my web Front End, this is the server that will be listening for connection and responding to clients, this server will have 8 cores and 16GB Ram.

The Second Server will be the Database Server, pretty self explanatory really, connect to the host and set / get data.

The Third Server will be my storage server, this will be where downloadable files are stored.

My first questions is:

• On my front end server, I have 8 cores, what's the best way to scale node so that the load is distributed across the cores?

My second question is:

• Is there a system out there I can drop into my application framework that will allow me to talk to the other cores and pass messages around to save I/O.

and final question:

• Is there any system I can use to help move the content from my storage server to the request on the front-end server with as little overhead as possible, speed is a concern here as we would have 500+ clients downloading and uploading concurrently at peak times.

I have finally convinced my employer that node.js is extremely fast and its the latest in programming technology, and we should invest in a platform for our Intranet system, but he has requested detailed documentation on how this could be scaled across the current hardware we have available.

On my front end server, I have 8 cores, what's the best way to scale node so that the load is distributed across the cores?

Try to look at node.js cluster module which is a multi-core server manager.

Firstly, I wouldn't describe the setup you propose as 'scaling', it's more like 'spreading'. You only have one app server serving the requests. If you add more app servers in the future, then you will have a scaling problem then.

I understand that node.js is single-threaded, which implies that it can only use a single core. Not my area of expertise on how to/if you can scale it, will leave that part to someone else.

I would suggest NFS mounting a directory on the storage server to the app server. NFS has relatively low overhead. Then you can access the files as if they were local.

Concerning your first question: use cluster (we already use it in a production system, works like a charm).

When it comes to worker messaging, i cannot really help you out. But your best bet is cluster too. Maybe there will be some functionality that provides "inter-core" messaging accross all cluster workers in the future (don't know the roadmap of cluster, but it seems like an idea).

For your third requirement, i'd use a low-overhead protocol like NFS or (if you can go really crazy when it comes to infrastructure) a high-speed SAN backend.

Another advice: use MongoDB as your database backend. You can start with low-end hardware and scale up your database instance with ease using MongoDB's sharding/replication set features (if that is some kind of requirement).