On May 1, 4:30 pm, Matt wrote:
> Often you'll find a cluster()'d node app favouring one process to do most
> of the work, rather than spreading the load more evenly.
>
> This is due to how the OS schedules the load balancing between processes.
> I'm assuming Bert is talking about maybe migrating s
Often you'll find a cluster()'d node app favouring one process to do most
of the work, rather than spreading the load more evenly.
This is due to how the OS schedules the load balancing between processes.
I'm assuming Bert is talking about maybe migrating some of that load
balancing logic into Nod
Why "load balancing is not very optimal at the moment. " ? any background
story?
--
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.
On May 1, 11:37 am, jason.桂林 wrote:
> Oh, thanks, you explain this problem very clearly.
>
> I think this could be optimize by cluster
>
> if (cluster.isMaster) {
>for (var i = 0; i < numCPUs; i++) {
> cluster.fork();
> }} else {
>
>// helloworld + redis
>
> }
>
> But, it seems no
I run 4 node instance listen on different port, use nginx load balance
module, with keep-alive connection, this problem fixed. Very fast.
2012/5/1 jason.桂林
> Oh, thanks, you explain this problem very clearly.
>
> I think this could be optimize by cluster
>
> if (cluster.isMaster) {
>for (var
Oh, thanks, you explain this problem very clearly.
I think this could be optimize by cluster
if (cluster.isMaster) {
for (var i = 0; i < numCPUs; i++) {
cluster.fork();
}
} else {
// helloworld + redis
}
But, it seems not very much
WITH cluster
GET:/
> done:3
> 200 OK: 3000
The math on that works out almost perfectly. You can't do math on
"responses per second" and get anything intuitive, but you can on
"seconds per response".
redisClient standalone = 27k RPS = 0.04ms/response
helloworld = 7.5 RPS = 0.13ms/response
Expected sum = 0.17ms/response = 5.8k RPS, which is
