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

feat: add maxConcurrency option #1483

Merged
merged 1 commit into from Jun 14, 2022

Conversation

sheremet-va
Copy link
Member

Closes #1212

@netlify
Copy link

netlify bot commented Jun 14, 2022

Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit a05ff1c
🔍 Latest deploy log https://app.netlify.com/sites/vitest-dev/deploys/62a82eec730f7d000814f1e4
😎 Deploy Preview https://deploy-preview-1483--vitest-dev.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 settings.

@sheremet-va sheremet-va requested a review from antfu June 14, 2022 06:58
@antfu
Copy link
Member

antfu commented Jun 14, 2022

It's better to release this with the next minor bump.

@sheremet-va
Copy link
Member Author

It's better to release this with the next minor bump.

I am waiting for you to review --shard before releasing a new version 😄

@sheremet-va sheremet-va merged commit 348a008 into vitest-dev:main Jun 14, 2022
@sheremet-va sheremet-va deleted the feat/max-concurrency branch June 14, 2022 17:58
@gajus
Copy link

gajus commented Oct 19, 2023

Is there a way to set this globally?

Usage:
  $ vitest run [...filters]

Options:
  -r, --root <path>                      Root path
  -c, --config <path>                    Path to config file
  -u, --update                           Update snapshot
  -w, --watch                            Enable watch mode
  -t, --testNamePattern <pattern>        Run tests with full names matching the specified regexp pattern
  --dir <path>                           Base directory to scan for the test files
  --ui                                   Enable UI
  --open                                 Open UI automatically (default: !process.env.CI))
  --api [api]                            Serve API, available options: --api.port <port>, --api.host [host] and --api.strictPort
  --threads                              Enabled threads (default: true)
  --single-thread                        Run tests inside a single thread, requires --threads (default: false)
  --experimental-vm-threads              Run tests in a worker pool using VM isolation (default: false)
  --experimental-vm-worker-memory-limit  Set the maximum allowed memory for a worker. When reached, a new worker will be created instead
  --silent                               Silent console output from tests
  --hideSkippedTests                     Hide logs for skipped tests
  --isolate                              Isolate environment for each test file (default: true)
  --reporter <name>                      Specify reporters
  --outputFile <filename/-s>             Write test results to a file when supporter reporter is also specified, use cac's dot notation for individual outputs of multiple reporters
  --coverage                             Enable coverage report
  --run                                  Disable watch mode
  --mode <name>                          Override Vite mode (default: test)
  --globals                              Inject apis globally
  --dom                                  Mock browser api with happy-dom
  --browser [options]                    Run tests in the browser (default: false)
  --environment <env>                    Specify runner environment, if not running in the browser (default: node)
  --passWithNoTests                      Pass when no tests found
  --logHeapUsage                         Show the size of heap for each test
  --allowOnly                            Allow tests and suites that are marked as only (default: !process.env.CI)
  --dangerouslyIgnoreUnhandledErrors     Ignore any unhandled errors that occur
  --shard <shard>                        Test suite shard to execute in a format of <index>/<count>
  --changed [since]                      Run tests that are affected by the changed files (default: false)
  --sequence <options>                   Define in what order to run tests (use --sequence.shuffle to run tests in random order, use --sequence.concurrent to run tests in parallel)
  --segfaultRetry <times>                Return tests on segment fault (default: 0) (default: 0)
  --no-color                             Removes colors from the console output (default: true)
  --inspect                              Enable Node.js inspector
  --inspect-brk                          Enable Node.js inspector with break
  --test-timeout <time>                  Default timeout of a test in milliseconds (default: 5000)
  --bail <number>                        Stop test execution when given number of tests have failed (default: 0)
  --retry <times>                        Retry the test specific number of times if it fails (default: 0)
  --diff <path>                          Path to a diff config that will be used to generate diff interface

We have a problem where vitest hogs too much CPU and ends up suffocating database operations (which is hosted on the same machine). I am not clear on how to tell Vitest to at most parallelize 80% CPU worth of threads.

@gajus
Copy link

gajus commented Oct 19, 2023

Found it:

+ import os from 'node:os';
import path from 'node:path';
import { defineConfig } from 'vitest/config';

export default defineConfig({
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
  test: {
    deps: {
      interopDefault: true,
    },
+    maxThreads: Math.ceil(os.cpus().length * 0.5),
    mockReset: true,
    outputFile: './src/__generated__/vitest/results.xml',
    reporters: ['verbose', 'junit'],
    testTimeout: 60_000,
  },
});

@gajus
Copy link

gajus commented Oct 19, 2023

On a related note, I am not sure if defaulting to 100% of the CPUs is a great idea. It diminishes test stability.

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.

max concurrency setting for test.concurrent
3 participants