-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support aggregating metrics across workers in a Node.js worker_… #403
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for opening this and sorry it took forever to get reviewed. A few comments below, plus:
- Looks like Node.js 10 breaks - drop support
- Needs a changelog update
- Please add tests
f9dd057
to
ef9e9f7
Compare
@zbjornson node 10 met its EOL https://nodejs.org/en/about/releases/ maybe we should not test against it anymore? worker features are available from node 11.0.0 |
Dropping node 10 must be done in a major release, but we can probably do one of those? |
any chance we could push this along? I am using worker threads on a project and this would help a lot. |
@rafixer @zbjornson? :) |
This looks good. We have two other PRs staged for a semver-major release. Let's drop v10 support in that release and land this PR with it. (I can add the changelog and fix the merge conflict if @rafixer doesn't get to it.) |
@zbjornson any chances for new major? :) deprecation fix for node 16+ is also "ready to release" - it would be great if new release comes some time soon ;) |
@zbjornson? :) |
@zbjornson Any news about this feature? |
Sorry for no action about this PR. I will back to this on next week! |
c3a1be5
to
2bb230a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry about the slow response! can you update the documentation?
also, I will check why currently tests cases are failing |
there's a syntax error. Miiight be the merge? |
Fixing the syntax error gives a bunch of lint errors, so I dunno 😅 |
as I remember, I tried to refactor the implementation - I will bring back the previous one |
but still, I'm worried that implementation might not be efficient - because it depends on communication between parent < - > child, especially when using a nested tree of workers/processes. Maybe the better idea will be to create a separate process and try to communicate with him via IPC |
thread communication shouldn't be any slower than separate process, should it? |
3f25c32
to
47441a0
Compare
@rafixer could you target |
Target changed , resolving conflicts in progress! |
6aad6b5
to
e2e185b
Compare
e2e185b
to
7e1fc1f
Compare
@SimenB @zbjornson Are there any updates yet? Does this need any help? |
@SimenB @zbjornson are you waiting for tests and changes for readme.md? How can we help you? |
@SimenB @zbjornson Any update on this? Anything we can do to push this through? |
+1, this would really help me as well! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to write tests for this? Probably by spinning up some process which emulates this and making requests against it?
I can't speak to the feature itself as I've never used the cluster mode
@@ -170,6 +182,7 @@ function addListeners() { | |||
cluster().on('message', (worker, message) => { | |||
if (message.type === GET_METRICS_RES) { | |||
const request = requests.get(message.requestId); | |||
request.pending += message.workerRequests || 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
request.pending += message.workerRequests || 0; | |
if (message.workerRequests) { | |
request.pending += message.workerRequests; | |
} |
@@ -196,12 +209,38 @@ function addListeners() { | |||
// Respond to master's requests for worker's local metrics. | |||
process.on('message', message => { | |||
if (message.type === GET_METRICS_REQ) { | |||
let workerRequests = 0; | |||
workersQueue.forEach(worker => { | |||
if (worker && worker instanceof Worker) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (worker && worker instanceof Worker) { | |
if (worker instanceof Worker) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we check this when instantiating/pushing into workersQueue
rather than when receiving messages? We should probably throw
@@ -196,12 +209,38 @@ function addListeners() { | |||
// Respond to master's requests for worker's local metrics. | |||
process.on('message', message => { | |||
if (message.type === GET_METRICS_REQ) { | |||
let workerRequests = 0; | |||
workersQueue.forEach(worker => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use for-of
instead of forEach
parentPort.on('message', ({ type, requestId, port } = {}) => { | ||
if (type === GET_METRICS_REQ) { | ||
Promise.all(registries.map(r => r.getMetricsAsJSON())) | ||
.then(metrics => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we use async-await rather than .then
and .catch
?
…threads
this PR is connected with this issue: #401 (comment)