Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

AriPerkkio
Copy link
Member

@AriPerkkio AriPerkkio commented Jan 26, 2024

Description

Switches default pool option from 'threads' to 'forks'. Adds new documentation pages describing common errors with pool: 'threads': segfaults and process hangs.

Motivation

Main goal is to provide stability over small performance boosts.

The pool: 'threads' runs code in node:worker_threads, pool: 'forks' runs code in node:child_process. While threads may be slightly faster than forks, it has been causing bugs that are very difficult to debug. Typically these errors are coming when users' test code contains native node module (e.g. Node packages that utilize C++, Go, Rust via Node-API).

There are also some NodeJS bugs in node:worker_threads that can lead to Worker's being stuck. So far I've been able to reproduce these issues by using Node's native fetch, dompurify and fastify.

All the cases mentioned above and links below work fine when using pool: 'forks'.

Segfaults and other native module crashes:

Process hangs:

Related issues:

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

  • It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
  • Ideally, include a test that fails without this PR but passes with it.
  • Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

  • Run the tests with pnpm test:ci.

Documentation

  • If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

  • Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

Copy link

netlify bot commented Jan 26, 2024

Deploy Preview for fastidious-cascaron-4ded94 ready!

Name Link
🔨 Latest commit 624b180
🔍 Latest deploy log https://app.netlify.com/sites/fastidious-cascaron-4ded94/deploys/663cb0c67663ea00085a354c
😎 Deploy Preview https://deploy-preview-5047--fastidious-cascaron-4ded94.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@hi-ogawa
Copy link
Contributor

stability over small performance boosts.

I'm not familiar with entire story of node:worker_threads issues, but I agree that "stability" is more important and this change makes sense to me. Having a dedicated docs/guide/improving-performance.md page looks good enough for performance-sensitive people to discover threads pool.

When people are thinking to migrate from more old-ish test framework to either Jest or Vitest, hitting this minor stability issue of the default setting could potentially move some people away from Vitest.

@AriPerkkio
Copy link
Member Author

migrate from more old-ish test framework to either Jest or Vitest

By the way, Jest also has an option for switching node:child_process to node:worker_threads. They also link to discussion about performance benefits: https://jestjs.io/docs/configuration#workerthreads.

I was also able to reproduce process hangs on Jest using their workerThreads option and code from #3077. By default Jest uses node:child_process so most users are not running into issues like this.

@silverwind
Copy link
Contributor

Been using forks for a long time now without any issues to avoid the hangs, so I think it'd be a good default.

@hi-ogawa
Copy link
Contributor

hi-ogawa commented Apr 1, 2024

I shared this before but here is a Github search result of pool: "forks". This can not be complete usage stats, but I guess it can still show how much it's battle-tested in the wild.

https://github.com/search?q=%22pool%3A+%27forks%27%22+OR+%22pool%3A+%5C%22forks%5C%22%22+language%3ATypeScript&type=code&l=TypeScript

@AriPerkkio AriPerkkio force-pushed the fix/default-pool-forks branch 4 times, most recently from c8a4e21 to b591930 Compare April 3, 2024 07:22
@AriPerkkio
Copy link
Member Author

/ecosystem-ci run

@vitest-ecosystem-ci
Copy link

vitest-ecosystem-ci bot commented Apr 3, 2024

📝 Ran ecosystem CI: Open

suite result
nuxt ✅ success
nuxt-test-utils ✅ success
vite ✅ success
vitest-vscode ✅ success
vitest-sonar-reporter ✅ success
vitest-github-actions-reporter ✅ success
vitest-browser-simple ✅ success
vitest-coverage-large ✅ success
vitest-reporters-large ✅ success

@AriPerkkio AriPerkkio marked this pull request as ready for review April 3, 2024 07:54
@sheremet-va
Copy link
Member

Can you resolve the conflicts, please? 👀

@AriPerkkio AriPerkkio force-pushed the fix/default-pool-forks branch from b591930 to 1effe5b Compare May 9, 2024 11:13
@AriPerkkio AriPerkkio marked this pull request as draft May 9, 2024 11:14
@AriPerkkio
Copy link
Member Author

AriPerkkio commented May 9, 2024

Some new errors after rebase 🤔

Oh right, this one is showing up: tinylibs/tinypool#85. Time to update Tinypool to Vitest's repo.

@AriPerkkio AriPerkkio force-pushed the fix/default-pool-forks branch 3 times, most recently from b932703 to 7e6de16 Compare May 9, 2024 14:24
@AriPerkkio AriPerkkio force-pushed the fix/default-pool-forks branch from 7e6de16 to a6d4fc6 Compare May 9, 2024 15:05
@TimKochDev
Copy link

FYI, the test runs in my enterprise project became significantly slower with forks.

342 tests in 152 files. Mostly using @testing-library/react.
Vitest v1.0.4: 82s
Vitest v2.1.5: 160s
Vitest v2.1.5 with --pool=threads: 90s

+Many test timed out now after reaching the 5s default test time out.

Can I provide you with more data?

@AriPerkkio
Copy link
Member Author

Can I provide you with more data?

Sure, would be interesting to see why NodeJS becomes that much slower with multi-processing instead of multi-threading. We've also mentioned this on https://vitest.dev/guide/improving-performance.html#pool but we've never seen that much of an impact.

Please create new issue with reproduction: https://github.com/vitest-dev/vitest/issues/new/choose

@vitest-dev vitest-dev locked as resolved and limited conversation to collaborators Nov 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants