| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
The active worker check compared the time from sending message till response arrived from worker with the complete time the worker was running till it responses to the spin request. If sending back the message is slow for some reason the test fails. Adapt the test to compare the time seen inside the worker with the time read from main thread.
|
@trevnorris Would be nice if you could take a look. Maybe I misunderstood your test. |
Sorry, something went wrong.
|
Stress test on master, no concurrency: https://ci.nodejs.org/job/node-stress-single-test/191/ ✅ Stress test with this PR, no concurrency: https://ci.nodejs.org/job/node-stress-single-test/192/ ✅ Stress test on master run with -J: https://ci.nodejs.org/job/node-stress-single-test/193/ ❌ (11 failures in 1000 runs) Stress test with this PR and -J: https://ci.nodejs.org/job/node-stress-single-test/194/ ❌ (1 failure in 1000 runs) |
Sorry, something went wrong.
Based on these results, this change greatly improves things but won't completely solve the problem. (I'll take "greatly improves" for sure!) However moving the test to sequential (along with these changes or without) will resolve the issue. (The question is whether that should resolve the issue or if the fact that it does is also indicative of a bug.) |
Sorry, something went wrong.
|
@Trott Thanks for running the perf tests. The fail remaining is at a different location. I will look into this further once I'm back on my work place. |
Sorry, something went wrong.
|
I am also thinking whether the spin time 50 ms is too small in comparison with the message overhead (looking at the failure data in freebsd, these come to 200 - 300 ms range), and as the later could potentially depend on the system characteristics (such as cpu count, load on the system etc.) , I doubt if the value idleActive(w2) is reflective of anything at all! |
Sorry, something went wrong.
|
Fixed the issue seen in last stress test by exchanging the two calls to get elu to be compared. Seems if OS decides to schedule an other process between these two lines the test failed. new (2000) run: https://ci.nodejs.org/job/node-stress-single-test/195/ ✅ Considering that this test heavily depends on timing it's maybe better to move it into sequential to avoid/reduce side effects of high os load/low number of CPUs. |
Sorry, something went wrong.
|
Hi all. Finally got done with my NodeConf Remote talk. Will prioritize looking at this and helping get it fixed (nothing worse than flakey tests failing CI). Give me a bit to review everything. |
Sorry, something went wrong.
There was a problem hiding this comment.
Make this additional change:
--- a/test/parallel/test-worker-eventlooputil.js
+++ b/test/parallel/test-worker-eventlooputil.js
@@ -50,12 +50,13 @@ let workerELU;
if (eventLoopUtilization().idle <= 0)
return setTimeout(mustCall(r), 5);
+ mainElu = eventLoopUtilization();
+
worker = new Worker(__filename, { argv: [ 'iamalive' ] });
metricsCh = new MessageChannel();
worker.postMessage({ metricsCh: metricsCh.port1 }, [ metricsCh.port1 ]);
workerELU = worker.performance.eventLoopUtilization;
- mainElu = eventLoopUtilization();
metricsCh.port2.once('message', mustCall(checkWorkerIdle));
metricsCh.port2.postMessage({ cmd: 'elu' });
// Make sure it's still safe to call eventLoopUtilization() after the workerThe ELU of the main thread should be stored the moment it's ready for testing.
Sorry, something went wrong.
| const tmpMainElu = eventLoopUtilization(mainElu); | ||
| const perfWorkerElu = workerELU(); | ||
| const tmpMainElu = eventLoopUtilization(mainElu); | ||
| const eluDiff = eventLoopUtilization(perfWorkerElu, mainElu); |
There was a problem hiding this comment.
Completely remove the eluDiff test. I don't remember what I was thinking when I added this, but the syntax is invalid. The diff between different ELU's is only valid for the same thread. This does a diff between worker and parent.
Sorry, something went wrong.
There was a problem hiding this comment.
done.
We could add worker.threadId into the elu result and throw on mismatch as it is a clear wrong use.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM with change suggested by @trevnorris
Sorry, something went wrong.
|
CI: https://ci.nodejs.org/job/node-test-pull-request/34032/ |
Sorry, something went wrong.
The active worker check compared the time from sending message till response arrived from worker with the complete time the worker was running till it responses to the spin request. If sending back the message is slow for some reason the test fails. Adapt the test to compare the time seen inside the worker with the time read from main thread. PR-URL: #35891 Fixes: #35844 Refs: #35886 Refs: #35664 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
The active worker check compared the time from sending message till response arrived from worker with the complete time the worker was running till it responses to the spin request. If sending back the message is slow for some reason the test fails. Adapt the test to compare the time seen inside the worker with the time read from main thread. PR-URL: #35891 Fixes: #35844 Refs: #35886 Refs: #35664 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
The active worker check compared the time from sending message till response arrived from worker with the complete time the worker was running till it responses to the spin request. If sending back the message is slow for some reason the test fails. Adapt the test to compare the time seen inside the worker with the time read from main thread. PR-URL: nodejs#35891 Fixes: nodejs#35844 Refs: nodejs#35886 Refs: nodejs#35664 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Backport-PR-URL: nodejs#37163
The active worker check compared the time from sending message till response arrived from worker with the complete time the worker was running till it responses to the spin request. If sending back the message is slow for some reason the test fails. Adapt the test to compare the time seen inside the worker with the time read from main thread. PR-URL: #35891 Fixes: #35844 Refs: #35886 Refs: #35664 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Backport-PR-URL: #37163
The active worker check compared the time from sending message till response arrived from worker with the complete time the worker was running till it responses to the spin request. If sending back the message is slow for some reason the test fails. Adapt the test to compare the time seen inside the worker with the time read from main thread. PR-URL: nodejs#35891 Fixes: nodejs#35844 Refs: nodejs#35886 Refs: nodejs#35664 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Backport-PR-URL: nodejs#37165
The active worker check compared the time from sending message till response arrived from worker with the complete time the worker was running till it responses to the spin request. If sending back the message is slow for some reason the test fails. Adapt the test to compare the time seen inside the worker with the time read from main thread. PR-URL: #35891 Fixes: #35844 Refs: #35886 Refs: #35664 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Backport-PR-URL: #37163
| Back | FazBrowse Home | New Git URL |
The active worker check compared the time from sending message till response arrived from worker with the complete time the worker was running till it responses to the spin request.
If sending back the message is slow for some reason the test fails.
Adapt the test to compare the time seen inside the worker with the time read from main thread.
Fixes: #35844
Refs: #35886
Refs: #35664