0.6.0 Clusters

[Chris Ackerman]

I'm really enthused about the sharing of network ports between forked processes using the new cluster framework, but what I can't figure out from the documentation is: Which processes gets which requests? How is the load actually balanced?

[Mark Hahn]

This may be a worthless answer, but I remember someone on this list saying it was controlled by the OS, whatever that means.

On Sat, Nov 5, 2011 at 10:37 AM, Chris Ackerman <bluejean...@gmail.com> wrote:

I'm really enthused about the sharing of network ports between forked processes using the new cluster framework, but what I can't figure out from the documentation is: Which processes gets which requests? How is the load actually balanced?

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Ben Noordhuis]

The master accepts the connection, then hands it off to one of the
workers. The load distribution is operating system dependent but
usually round-robin.

[Jorge]

On 06/11/2011, at 05:00, Ben Noordhuis wrote:
> On Sat, Nov 5, 2011 at 18:37, Chris Ackerman <bluejean...@gmail.com> wrote:
>> I'm really enthused about the sharing of network ports between forked
>> processes using the new cluster framework, but what I can't figure out from
>> the documentation is: Which processes gets which requests? How is the load
>> actually balanced?
>
> The master accepts the connection, then hands it off to one of the
> workers.

Can the master pass any context data together with the connection ?
For example, let's say, some session data ?

> The load distribution is operating system dependent but
> usually round-robin.

I don't get why, if it's the master who accepts the connection, why is the distribution operating system dependent ?

Thanks in advance,
--
Jorge.

[Wan Li]

So for web applications, it's quit hard to do session sticky if we don't have global sessions. Correct me if I'm wrong.

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
>: ~

[Mark Hahn]

I keep a session id in a cookie and pull up the session record from the db on every request.  I think this is a pretty standard technique and would work fine with anonymous workers.

[Ben Noordhuis]

Sorry, I explained it wrong: s/master accepts the connection/creates
the bound socket/

In a nutshell:

1) the master creates and binds the socket, then passes it to the
workers (using cmsg file descriptor passing on Unices)
2) the workers (and the master too) listen on the socket
3) when a connection arrives, the operating system wakes up one of the listeners

[Ben Noordhuis]

On Mon, Nov 7, 2011 at 05:13, Wan Li <wanl...@gmail.com> wrote:
> So for web applications, it's quit hard to do session sticky if we don't
> have global sessions. Correct me if I'm wrong.

Yes, but consider that a feature. If you want horizontal scalable web
apps, session affinity is one of the first things to go.

[Wan Li]

@Mark, @Ben
Thanks for the clarify.
Throwing sessions to redis or memcached did solve the problem, but I don't wanna import them to some "small" applications, it's just too heavy weighted.
 

--
>: ~

[Ted Young]

Throwing sessions to redis or memcached did solve the problem, but I don't wanna import them to some "small" applications, it's just too heavy weighted.

If you want to hold session data in memory, with no persistence, you can just use another node process.  Or, you could use worker.send to broadcast session changes to all the workers and keep a copy of the data in each process.  If your data is less than a couple MB it would be cheaper than starting another node process.  Or maybe you don't actually need a cluster for some of these smaller projects?

Ted 

[Wan Li]

Throwing sessions to redis or memcached did solve the problem, but I don't wanna import them to some "small" applications, it's just too heavy weighted.

If you want to hold session data in memory, with no persistence, you can just use another node process.  Or, you could use worker.send to broadcast session changes to all the workers and keep a copy of the data in each process.  If your data is less than a couple MB it would be cheaper than starting another node process.  Or maybe you don't actually need a cluster for some of these smaller projects?

We are using modified HAProxy to do the load balance with session sticky during V0.4.x. I just wanna take free lunch from build-in cluster support and not saying current design is a big problem. :)

--
>: ~

[Aaron Krill]

I'm really surprised anyone is doing server-side sessions these days.
Why not just use a signed/encrypted cookie? That scales infinitely...
doesn't require maintenance on the server side... and is pretty damn
secure. Are you really storing /that/ much data in your session?

[Ryan Schmidt]

On Nov 7, 2011, at 03:06, Aaron Krill wrote:

> I'm really surprised anyone is doing server-side sessions these days.

...I was not aware there were viable alternatives. Coming from the PHP world, it's pretty damn ubiquitous to store things in $_SESSION, and the node tutorials I've seen so far do similarly.

[Richard Marr]

I use the same method. Sign & encrypt a small amount of session data in a cookie and it makes an entire class of headaches go away. Admittedly it opens you up to some other ones, but in a lot of cases the trade-off is worth it.

--
Richard Marr

[ilya]

@Felix would you elaborate a little on how you did it, please? I'm trying to solve the same question (socket.io + clusters).