node always uses the same cluster
I created a cluster for each thread of my cpu, and for each request I wait 5 seconds to respond, and opened several tabs of the chrome and made the requests, but all of them are processed by the same cluster, and synchronously, after hold 5 seconds of the first request is that it starts processing the second request, and so on.
const cluster = require('cluster')
const numCPUs = require('os').cpus().length;
if(cluster.isMaster) {
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} died with code: ${code}, and
signal: ${signal}`);
console.log('Starting a new worker');
cluster.fork();
});
} else {
const express = require('express')
const app = express();
app.get('/', (req, res) => {
setTimeout(()=>{
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
}, 5000)
})
app.listen(3000, ()=> console.log('Listening with worker',
cluster.worker.id))
}
@Edit ---- code after sugestions ------
its works now, but on only two times, how you can see on image, the other times the process are syncronous, using only one cluster, only one time it use other cluster, how i can control it better?
const cluster = require('cluster')
const numCPUs = require('os').cpus().length;
if(cluster.isMaster) {
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} died with code: ${code}, and
signal: ${signal}`);
console.log('Starting a new worker');
cluster.fork();
});
} else {
const express = require('express')
const app = express();
function sleepSync(ms) {
let targetTime = Date.now() + ms;
while (Date.now() < targetTime);
}
app.get('/', (req, res) => {
sleepSync(5000)
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
})
app.listen(3000, ()=> console.log('Listening with worker', cluster.worker.id))
}
node.js
add a comment |
I created a cluster for each thread of my cpu, and for each request I wait 5 seconds to respond, and opened several tabs of the chrome and made the requests, but all of them are processed by the same cluster, and synchronously, after hold 5 seconds of the first request is that it starts processing the second request, and so on.
const cluster = require('cluster')
const numCPUs = require('os').cpus().length;
if(cluster.isMaster) {
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} died with code: ${code}, and
signal: ${signal}`);
console.log('Starting a new worker');
cluster.fork();
});
} else {
const express = require('express')
const app = express();
app.get('/', (req, res) => {
setTimeout(()=>{
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
}, 5000)
})
app.listen(3000, ()=> console.log('Listening with worker',
cluster.worker.id))
}
@Edit ---- code after sugestions ------
its works now, but on only two times, how you can see on image, the other times the process are syncronous, using only one cluster, only one time it use other cluster, how i can control it better?
const cluster = require('cluster')
const numCPUs = require('os').cpus().length;
if(cluster.isMaster) {
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} died with code: ${code}, and
signal: ${signal}`);
console.log('Starting a new worker');
cluster.fork();
});
} else {
const express = require('express')
const app = express();
function sleepSync(ms) {
let targetTime = Date.now() + ms;
while (Date.now() < targetTime);
}
app.get('/', (req, res) => {
sleepSync(5000)
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
})
app.listen(3000, ()=> console.log('Listening with worker', cluster.worker.id))
}
node.js
add a comment |
I created a cluster for each thread of my cpu, and for each request I wait 5 seconds to respond, and opened several tabs of the chrome and made the requests, but all of them are processed by the same cluster, and synchronously, after hold 5 seconds of the first request is that it starts processing the second request, and so on.
const cluster = require('cluster')
const numCPUs = require('os').cpus().length;
if(cluster.isMaster) {
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} died with code: ${code}, and
signal: ${signal}`);
console.log('Starting a new worker');
cluster.fork();
});
} else {
const express = require('express')
const app = express();
app.get('/', (req, res) => {
setTimeout(()=>{
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
}, 5000)
})
app.listen(3000, ()=> console.log('Listening with worker',
cluster.worker.id))
}
@Edit ---- code after sugestions ------
its works now, but on only two times, how you can see on image, the other times the process are syncronous, using only one cluster, only one time it use other cluster, how i can control it better?
const cluster = require('cluster')
const numCPUs = require('os').cpus().length;
if(cluster.isMaster) {
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} died with code: ${code}, and
signal: ${signal}`);
console.log('Starting a new worker');
cluster.fork();
});
} else {
const express = require('express')
const app = express();
function sleepSync(ms) {
let targetTime = Date.now() + ms;
while (Date.now() < targetTime);
}
app.get('/', (req, res) => {
sleepSync(5000)
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
})
app.listen(3000, ()=> console.log('Listening with worker', cluster.worker.id))
}
node.js
I created a cluster for each thread of my cpu, and for each request I wait 5 seconds to respond, and opened several tabs of the chrome and made the requests, but all of them are processed by the same cluster, and synchronously, after hold 5 seconds of the first request is that it starts processing the second request, and so on.
const cluster = require('cluster')
const numCPUs = require('os').cpus().length;
if(cluster.isMaster) {
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} died with code: ${code}, and
signal: ${signal}`);
console.log('Starting a new worker');
cluster.fork();
});
} else {
const express = require('express')
const app = express();
app.get('/', (req, res) => {
setTimeout(()=>{
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
}, 5000)
})
app.listen(3000, ()=> console.log('Listening with worker',
cluster.worker.id))
}
@Edit ---- code after sugestions ------
its works now, but on only two times, how you can see on image, the other times the process are syncronous, using only one cluster, only one time it use other cluster, how i can control it better?
const cluster = require('cluster')
const numCPUs = require('os').cpus().length;
if(cluster.isMaster) {
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} died with code: ${code}, and
signal: ${signal}`);
console.log('Starting a new worker');
cluster.fork();
});
} else {
const express = require('express')
const app = express();
function sleepSync(ms) {
let targetTime = Date.now() + ms;
while (Date.now() < targetTime);
}
app.get('/', (req, res) => {
sleepSync(5000)
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
})
app.listen(3000, ()=> console.log('Listening with worker', cluster.worker.id))
}
node.js
node.js
edited Jan 1 at 14:28
Davi Resio
asked Jan 1 at 12:18
Davi ResioDavi Resio
7218
7218
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
It takes microseconds execute setTimeout
. Timeouts are not a busy wait. In the time that your worker waits, it is freely available for other tasks. So it will take up additional requests until the 5 seconds run out consecutively. This is achieved through node's Event Loop.
More primitive implementations of servers use this technique to achieve a notion of parallelism as well.
In order to see a difference, try creating a busy wait, potentially like below, and using it in place of setTimeout
.
function sleepSync(ms) {
let targetTime = Date.now() + ms;
while (Date.now() < targetTime);
}
Thank you so much, the code works now, but not perfect, its work only two times, you know how i can control it better? i'm update my question with your sugestions
– Davi Resio
Jan 1 at 14:29
It's hard to say. It's not unlikely there's compiler optimizations in place that recognize the pattern and automatically convert it into an implicit timeout. The only way to be absolutely sure is to create actual computation work. Also I don't know enough about express with clusters. There's some black magic that happens hidden from plain sight. I'd say the solution to your problem just depends on your explicit objective?
– Kiruse
Jan 1 at 14:37
1
my objective is only for study. thank you very much, you explained it for me very well
– Davi Resio
Jan 1 at 14:51
add a comment |
You could also use async/await and avoid busy waiting and unnecessarily pinning one CPU core for 5 seconds:
const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));
app.get('/', async (req, res) => {
await sleep(5000);
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
});
To understand why busy waiting is bad, run top
while your application is looping through those 5 seconds and see that one of your CPU cores is at 100%. Replace with the code above to confirm that the CPU is not affected any longer.
When you call await
, Node.js knows that it has to pause your function execution until the promise coming from sleep()
is resolved. Meanwhile, though, it is able to run other things: other timers, other incoming HTTP requests, etc.
Node.js is single-threaded, so if you busy-wait for things, Node.js can't run anything else and your program is effectively stalled for 5 seconds with its hands tied until your loop ends.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53995373%2fnode-always-uses-the-same-cluster%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It takes microseconds execute setTimeout
. Timeouts are not a busy wait. In the time that your worker waits, it is freely available for other tasks. So it will take up additional requests until the 5 seconds run out consecutively. This is achieved through node's Event Loop.
More primitive implementations of servers use this technique to achieve a notion of parallelism as well.
In order to see a difference, try creating a busy wait, potentially like below, and using it in place of setTimeout
.
function sleepSync(ms) {
let targetTime = Date.now() + ms;
while (Date.now() < targetTime);
}
Thank you so much, the code works now, but not perfect, its work only two times, you know how i can control it better? i'm update my question with your sugestions
– Davi Resio
Jan 1 at 14:29
It's hard to say. It's not unlikely there's compiler optimizations in place that recognize the pattern and automatically convert it into an implicit timeout. The only way to be absolutely sure is to create actual computation work. Also I don't know enough about express with clusters. There's some black magic that happens hidden from plain sight. I'd say the solution to your problem just depends on your explicit objective?
– Kiruse
Jan 1 at 14:37
1
my objective is only for study. thank you very much, you explained it for me very well
– Davi Resio
Jan 1 at 14:51
add a comment |
It takes microseconds execute setTimeout
. Timeouts are not a busy wait. In the time that your worker waits, it is freely available for other tasks. So it will take up additional requests until the 5 seconds run out consecutively. This is achieved through node's Event Loop.
More primitive implementations of servers use this technique to achieve a notion of parallelism as well.
In order to see a difference, try creating a busy wait, potentially like below, and using it in place of setTimeout
.
function sleepSync(ms) {
let targetTime = Date.now() + ms;
while (Date.now() < targetTime);
}
Thank you so much, the code works now, but not perfect, its work only two times, you know how i can control it better? i'm update my question with your sugestions
– Davi Resio
Jan 1 at 14:29
It's hard to say. It's not unlikely there's compiler optimizations in place that recognize the pattern and automatically convert it into an implicit timeout. The only way to be absolutely sure is to create actual computation work. Also I don't know enough about express with clusters. There's some black magic that happens hidden from plain sight. I'd say the solution to your problem just depends on your explicit objective?
– Kiruse
Jan 1 at 14:37
1
my objective is only for study. thank you very much, you explained it for me very well
– Davi Resio
Jan 1 at 14:51
add a comment |
It takes microseconds execute setTimeout
. Timeouts are not a busy wait. In the time that your worker waits, it is freely available for other tasks. So it will take up additional requests until the 5 seconds run out consecutively. This is achieved through node's Event Loop.
More primitive implementations of servers use this technique to achieve a notion of parallelism as well.
In order to see a difference, try creating a busy wait, potentially like below, and using it in place of setTimeout
.
function sleepSync(ms) {
let targetTime = Date.now() + ms;
while (Date.now() < targetTime);
}
It takes microseconds execute setTimeout
. Timeouts are not a busy wait. In the time that your worker waits, it is freely available for other tasks. So it will take up additional requests until the 5 seconds run out consecutively. This is achieved through node's Event Loop.
More primitive implementations of servers use this technique to achieve a notion of parallelism as well.
In order to see a difference, try creating a busy wait, potentially like below, and using it in place of setTimeout
.
function sleepSync(ms) {
let targetTime = Date.now() + ms;
while (Date.now() < targetTime);
}
answered Jan 1 at 14:16


KiruseKiruse
885
885
Thank you so much, the code works now, but not perfect, its work only two times, you know how i can control it better? i'm update my question with your sugestions
– Davi Resio
Jan 1 at 14:29
It's hard to say. It's not unlikely there's compiler optimizations in place that recognize the pattern and automatically convert it into an implicit timeout. The only way to be absolutely sure is to create actual computation work. Also I don't know enough about express with clusters. There's some black magic that happens hidden from plain sight. I'd say the solution to your problem just depends on your explicit objective?
– Kiruse
Jan 1 at 14:37
1
my objective is only for study. thank you very much, you explained it for me very well
– Davi Resio
Jan 1 at 14:51
add a comment |
Thank you so much, the code works now, but not perfect, its work only two times, you know how i can control it better? i'm update my question with your sugestions
– Davi Resio
Jan 1 at 14:29
It's hard to say. It's not unlikely there's compiler optimizations in place that recognize the pattern and automatically convert it into an implicit timeout. The only way to be absolutely sure is to create actual computation work. Also I don't know enough about express with clusters. There's some black magic that happens hidden from plain sight. I'd say the solution to your problem just depends on your explicit objective?
– Kiruse
Jan 1 at 14:37
1
my objective is only for study. thank you very much, you explained it for me very well
– Davi Resio
Jan 1 at 14:51
Thank you so much, the code works now, but not perfect, its work only two times, you know how i can control it better? i'm update my question with your sugestions
– Davi Resio
Jan 1 at 14:29
Thank you so much, the code works now, but not perfect, its work only two times, you know how i can control it better? i'm update my question with your sugestions
– Davi Resio
Jan 1 at 14:29
It's hard to say. It's not unlikely there's compiler optimizations in place that recognize the pattern and automatically convert it into an implicit timeout. The only way to be absolutely sure is to create actual computation work. Also I don't know enough about express with clusters. There's some black magic that happens hidden from plain sight. I'd say the solution to your problem just depends on your explicit objective?
– Kiruse
Jan 1 at 14:37
It's hard to say. It's not unlikely there's compiler optimizations in place that recognize the pattern and automatically convert it into an implicit timeout. The only way to be absolutely sure is to create actual computation work. Also I don't know enough about express with clusters. There's some black magic that happens hidden from plain sight. I'd say the solution to your problem just depends on your explicit objective?
– Kiruse
Jan 1 at 14:37
1
1
my objective is only for study. thank you very much, you explained it for me very well
– Davi Resio
Jan 1 at 14:51
my objective is only for study. thank you very much, you explained it for me very well
– Davi Resio
Jan 1 at 14:51
add a comment |
You could also use async/await and avoid busy waiting and unnecessarily pinning one CPU core for 5 seconds:
const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));
app.get('/', async (req, res) => {
await sleep(5000);
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
});
To understand why busy waiting is bad, run top
while your application is looping through those 5 seconds and see that one of your CPU cores is at 100%. Replace with the code above to confirm that the CPU is not affected any longer.
When you call await
, Node.js knows that it has to pause your function execution until the promise coming from sleep()
is resolved. Meanwhile, though, it is able to run other things: other timers, other incoming HTTP requests, etc.
Node.js is single-threaded, so if you busy-wait for things, Node.js can't run anything else and your program is effectively stalled for 5 seconds with its hands tied until your loop ends.
add a comment |
You could also use async/await and avoid busy waiting and unnecessarily pinning one CPU core for 5 seconds:
const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));
app.get('/', async (req, res) => {
await sleep(5000);
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
});
To understand why busy waiting is bad, run top
while your application is looping through those 5 seconds and see that one of your CPU cores is at 100%. Replace with the code above to confirm that the CPU is not affected any longer.
When you call await
, Node.js knows that it has to pause your function execution until the promise coming from sleep()
is resolved. Meanwhile, though, it is able to run other things: other timers, other incoming HTTP requests, etc.
Node.js is single-threaded, so if you busy-wait for things, Node.js can't run anything else and your program is effectively stalled for 5 seconds with its hands tied until your loop ends.
add a comment |
You could also use async/await and avoid busy waiting and unnecessarily pinning one CPU core for 5 seconds:
const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));
app.get('/', async (req, res) => {
await sleep(5000);
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
});
To understand why busy waiting is bad, run top
while your application is looping through those 5 seconds and see that one of your CPU cores is at 100%. Replace with the code above to confirm that the CPU is not affected any longer.
When you call await
, Node.js knows that it has to pause your function execution until the promise coming from sleep()
is resolved. Meanwhile, though, it is able to run other things: other timers, other incoming HTTP requests, etc.
Node.js is single-threaded, so if you busy-wait for things, Node.js can't run anything else and your program is effectively stalled for 5 seconds with its hands tied until your loop ends.
You could also use async/await and avoid busy waiting and unnecessarily pinning one CPU core for 5 seconds:
const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));
app.get('/', async (req, res) => {
await sleep(5000);
console.log('worker response id: ' + cluster.worker.id)
res.status(200).end()
});
To understand why busy waiting is bad, run top
while your application is looping through those 5 seconds and see that one of your CPU cores is at 100%. Replace with the code above to confirm that the CPU is not affected any longer.
When you call await
, Node.js knows that it has to pause your function execution until the promise coming from sleep()
is resolved. Meanwhile, though, it is able to run other things: other timers, other incoming HTTP requests, etc.
Node.js is single-threaded, so if you busy-wait for things, Node.js can't run anything else and your program is effectively stalled for 5 seconds with its hands tied until your loop ends.
edited Jan 1 at 16:18
answered Jan 1 at 16:12
Lucio PaivaLucio Paiva
6,72523756
6,72523756
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53995373%2fnode-always-uses-the-same-cluster%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown