-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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 #30875
Comments
We have checked tracing impact, according to this comment: #30629 (comment), but I am not sure how that changes anything? It just confirms, that writing trace make tests run slower, but it does not explain timeouts for those tests in UI mode: |
No I don't have anything new. But what I have are tests which run around 1s on OSX regardless whether it is one worker, multiple workers, console or UI mode. |
The processor that we run it on (i7-12850HX) has 16 cores and 24 threads. I have a feeling that this 80% worker setting in playwright is actually either resulting in 16 or more workers. If it wasn't then it wouldn't matter If I would use 5 workers or 15 workers - the time increase would be the same because of trace or something else that UI does. Buy this is not the case. Maybe try to run it on a similar processor. Not sure though why do I need to try to figure out ways to find the issue? |
Performance difference on Mac for me is similar to Windows (https://github.com/microsoft/playwright/assets/9798949/94dd6273-55a9-4a3e-9877-1d2ec82f3bc8, https://github.com/microsoft/playwright/assets/9798949/9adafec5-6673-4f44-8b9f-5a394e0f0a88) Removing
That does not match what I see, on macOS they are also at least 2x slower in parallel mode.
Neither me nor @dgozman have been able to reproduce 10x difference, the tests run ~5x slower on Windows in UI mode. This is probably due to difference in the hardware (disk?) and system configuration. The UI mode is expected to be slower than normal execution. The more parallel workers you run, the more contention that may cause. 10x slow down is too high, but it appears to be specific to your environment which we cannot reproduce locally. |
This includes two major changes: - reuse `SerializedFS` for live test runner tracing; - merge scheduled `appendFile` operations into a single `fs` call. In some cases, this improves performance of UI mode by 61% and performance of `trace: on` mode by 38%. Note that performance improvement on the average test will not be as noticeable. References #30875, #30635.
We have tried to narrow down the issue. The only thing we see in the UI that it is the browser setup that takes majority of time - like 9.5s when the test times out at 10. We tried various tools like "Process Monitor" on Windows to see what is happening, but there is not much there. We only see process creating files with trace for the UI. |
@pbrzosko I am not really sure how to help you. Perhaps launching a browser triggers some security checks on your Windows? We did some general improvements to tracing performance that will be released in v1.45 release. I'll look into windows-specific issues more closely for the next v1.46 release as well. |
Version
1.42.1
Steps to reproduce
Expected behavior
All tests should run similar amount of time and not time out. Here is a screenshot of them running on OSX:
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:
Additional context
When run with one worker, it seems to work fine.
Environment
The text was updated successfully, but these errors were encountered: