feat: support aggregating metrics across workers in a Node.js worker_…#403
feat: support aggregating metrics across workers in a Node.js worker_…#403rafixer wants to merge 3 commits intosiimon:masterfrom
Conversation
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
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! |
SimenB
left a comment
There was a problem hiding this comment.
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
| 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.
| request.pending += message.workerRequests || 0; | |
| if (message.workerRequests) { | |
| request.pending += message.workerRequests; | |
| } |
| if (message.type === GET_METRICS_REQ) { | ||
| let workerRequests = 0; | ||
| workersQueue.forEach(worker => { | ||
| if (worker && worker instanceof Worker) { |
There was a problem hiding this comment.
| if (worker && worker instanceof Worker) { | |
| if (worker instanceof Worker) { |
There was a problem hiding this comment.
should we check this when instantiating/pushing into workersQueue rather than when receiving messages? We should probably throw
| process.on('message', message => { | ||
| if (message.type === GET_METRICS_REQ) { | ||
| let workerRequests = 0; | ||
| workersQueue.forEach(worker => { |
There was a problem hiding this comment.
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.
can we use async-await rather than .then and .catch?
…threads
this PR is connected with this issue: #401 (comment)