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

[Bug]: UI seems to lock on Windows making tests time out #30629

Closed
pbrzosko opened this issue May 2, 2024 · 7 comments
Closed

[Bug]: UI seems to lock on Windows making tests time out #30629

pbrzosko opened this issue May 2, 2024 · 7 comments

Comments

@pbrzosko
Copy link

pbrzosko commented May 2, 2024

Version

1.42.1

Steps to reproduce

  1. Clone my repo at https://github.com/pbrzosko/playwright-lock-issue
  2. Run npm install
  3. Run npm run pw on a Windows machine
  4. Execute tests in the UI

Expected behavior

All tests should run similar amount of time and not time out. Here is a screenshot of them running on OSX:
image

Actual behavior

On Windows, it seems like tests are locking each other on some resource. Thus they start to time out and run very slowly:
image

Additional context

When run with one worker, it seems to work fine:
image

Environment

System:
    OS: Windows 10 10.0.19045
    CPU: (24) x64 12th Gen Intel(R) Core(TM) i7-12850HX
    Memory: 6.77 GB / 31.69 GB
  Binaries:
    Node: 18.12.0 - C:\Program Files\nodejs\node.EXE
    npm: 8.19.2 - C:\Program Files\nodejs\npm.CMD
  IDEs:
    VSCode: 1.87.2 - C:\Users\rgzc\AppData\Local\Programs\Microsoft VS Code\bin\code.CMD
  Languages:
    Bash: 5.0.17 - C:\Windows\System32\bash.EXE
  npmPackages:
    @playwright/experimental-ct-vue: ^1.42.1 => 1.42.1
@pbrzosko
Copy link
Author

pbrzosko commented May 2, 2024

Seems like problem also exists when running from command line, but with smaller impact:

image

@dgozman
Copy link
Contributor

dgozman commented May 2, 2024

@pbrzosko I have played with your repro a bit. Things are slowing down indeed, but some of that is expected due to increased parallelization between single worker and many workers. However, I did not reach 10 seconds.

UI mode is noticeably slower. I think this is due to trace being recorded by UI mode, and disk access slowing everything down. Perhaps the shared disk access may even slow down all workers in parallel, which looks like "locking effect".

@pbrzosko
Copy link
Author

pbrzosko commented May 2, 2024

How about every worker using its own directory to gather trace and then everything is combined at the end of the run?
Why it doesn't happen on OSX?
What times do you get? It might be some of the company installed software that spoils things but we have no idea where to look?

@dgozman
Copy link
Contributor

dgozman commented May 2, 2024

How about every worker using its own directory to gather trace and then everything is combined at the end of the run?

Each worker has its own directory already.

Why it doesn't happen on OSX?

I guess the filesystem is implemented differently? Note that it was just my first idea, and the problem might be entirely different.

What times do you get?

Everything is ~1.8x slower in UI mode. Going up to 8 workers slows down each test ~2x.

It might be some of the company installed software that spoils things but we have no idea where to look?

That could easily be the case with the antivirus. You can check that by running with --workers=1 and --trace=on/--trace=off without UI mode. This way you can isolate the impact of tracing, which writes to disk, on the test timing. Something like an antivirus could slow things down significantly.

@pbrzosko
Copy link
Author

pbrzosko commented May 2, 2024

I will check the trace impact. But when we run with 1 worker in UI mode, times are as expected. So it seems like some locking issue which is only visible with many workers running.

@dgozman
Copy link
Contributor

dgozman commented May 8, 2024

I'll close this issue, because there is no action item for Playwright right now. If you come up with some new findings, please file a new issue and link to this one, so we can continue the discussion.

@dgozman dgozman closed this as completed May 8, 2024
@pbrzosko
Copy link
Author

pbrzosko commented May 8, 2024

Yyy, say that again @dgozman? You have clear evodence that tests run over 10s instead of one and you say there is nothing to do from your side?

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

No branches or pull requests

2 participants