Skip to content
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

Let the user choose worker implementation #64

Merged
merged 36 commits into from
Jun 22, 2023

Conversation

yurynix
Copy link
Contributor

@yurynix yurynix commented Jun 18, 2023

Hi 👋
In this PR, we let the user choose worker implementation, either default thread (using worker_threads) or process (using child_process.fork()). Closes #63

Other notable changes:

  • I've added for most tests the workerType argument, so the tests will run for both implementations, all the Uint8Array tests are hard-coded to thread implementation, so are resource-limits tests, which is a worker_threads concept.
  • The test that tests infinite loop was not actually verifying the worker was able to exit, IMO, it was never getting the exit message, since it's event loop was busy with the while(true);, I've added a timer to handle that.
  • Since there are much more tests now, and many of those are actually spawning multiple threads/processes, IMO it's wise to limit ava's concurrency, I chose the value 2 (don't have a reason why 2 🙃 ) concurrency 1 seems more stable on CI.

Let me know what you think 🙃

@yurynix
Copy link
Contributor Author

yurynix commented Jun 18, 2023

This one is failing in a few configurations, but does not reproduce locally so far:

  auto-start › should result in spawn of the workers before the first call if active workerType: process

  e2e/auto-start.spec.js:37

   36:         // then                             
   37:         t.true(workerStartTime <= callTime);
   38:     });                                     

need to look into it...

yurynix added 6 commits June 18, 2023 20:43
That is because minWorkers default is 0, so pool is immieadtly ready,
but test passes in thread scenario becuase the uptime is coming from parent process.
@yurynix
Copy link
Contributor Author

yurynix commented Jun 19, 2023

I think I should bring the Transport from v1, I will work on it later today.

@bgalek
Copy link
Member

bgalek commented Jun 19, 2023

This one is failing in a few configurations, but does not reproduce locally so far:

  auto-start › should result in spawn of the workers before the first call if active workerType: process

  e2e/auto-start.spec.js:37

   36:         // then                             
   37:         t.true(workerStartTime <= callTime);
   38:     });                                     

need to look into it...

it seems that only windows is affected ;)

@yurynix
Copy link
Contributor Author

yurynix commented Jun 19, 2023

That's solved @bgalek 🙃

I want to understand why the current windows tests are failing, and test it E2E on our system as well.

@bgalek
Copy link
Member

bgalek commented Jun 19, 2023

nice!

package.json Outdated
@@ -1,5 +1,6 @@
{
"name": "worker-nodes",
"version": "2.5.0-alpha",
Copy link
Member

@bgalek bgalek Jun 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove this version before releasing new one ;) for testing npm link should use 0.0.0 version - if that was the matter ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm running that on our project's CI, so I'm installing it via yarn like so:

yarn add worker-nodes@yurynix/node-worker-nodes#8010dc0fbc322c2022a057f758fa9207363ebceb

and then pushing to github for the CI to run.

yarn add from github fails if there is no version field unfortunately, due npm pack failing behind the scenes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I'll think how to handle this

@bgalek
Copy link
Member

bgalek commented Jun 20, 2023

ready for review? :)

@yurynix
Copy link
Contributor Author

yurynix commented Jun 20, 2023

@bgalek soon 🙏 I'll comment here, ok?


const EXIT_WAIT_TIME_MS = 200;

const execArgsProcessor = {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comes from v1, haven't wrote that myself.

}
};

function createChannel(workerId, onConnect) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's adaptation from:
https://github.com/mcollina/autocannon/pull/145/files
because of
nodejs/node#14046

To make Windows work.

const BUFFER_INITIAL_SIZE = 1024 * 1024; // 1MB
const BUFFER_GROW_RATIO = 1.5;

class Transport extends EventEmitter {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's from v1 as well

@@ -252,28 +252,15 @@ class WorkerNodes extends EventEmitter {
* @returns {Worker}
*/
pickWorker() {
if (this.options.lazyStart) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, lazyStart only matters for startup,
i.e. do we start up to minWorkers or maxWorkers, so IMO this block can be simplified.

Also previous code would break if the worker took time to startup, that is because the called of pickWorker() in the lazyStart option would receive a worker that was not yet isProcessAlive (line 259 & 263) and would try to dispatch work to it in processQueue:

            const worker = this.pickWorker();
            if (worker) {
                this.dispatchTaskTo(worker);
            }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that wasn't entirely true, but it still can be simplified to:

        if (this.canStartWorker() && (!this.options.lazyStart || !worker)) {
            this.startWorker();
        }

@yurynix
Copy link
Contributor Author

yurynix commented Jun 20, 2023

@bgalek now I think it's ready for review 🙃

I've also ran E2Es with it on our project (workerType: "process"), seems fine.
We are currently on worker-nodes@1.6.1

@yurynix
Copy link
Contributor Author

yurynix commented Jun 22, 2023

Hey @bgalek 👋
Hope you're doing well 🙏
Just heads up, I will be AFK next week from 26/June and I'll be back on the 2nd of July.

@bgalek
Copy link
Member

bgalek commented Jun 22, 2023

@yurynix LGTM, do You want to release it today so you can update it before your vacation? :)

@yurynix
Copy link
Contributor Author

yurynix commented Jun 22, 2023

Thank you for taking the time to review that 🙏
No problem if you want to release it today, but unless I want my colleagues to hate me forever,
I'll upgrade to the new version once I'm back 🙃

@bgalek bgalek merged commit adb07c1 into allegro:main Jun 22, 2023
@yurynix yurynix deleted the choose-worker-implementation branch June 22, 2023 08:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Worker implementation selection
2 participants