-
Notifications
You must be signed in to change notification settings - Fork 5.3k
[wasm] spread WS based timers over next 6 minutes to prevent heavy throttling #57745
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
[wasm] spread WS based timers over next 6 minutes to prevent heavy throttling #57745
Conversation
|
Right now, I'm not clear if 6 minutes is right time span. |
|
This is necessary infrastructure change for the automated test. It's still quite fragile. |
|
/azp run runtime-libraries-mono outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
bec2dfc to
043e566
Compare
|
New xharness binaries are in. |
aa34508 to
42fc2ea
Compare
|
/azp run runtime-libraries-mono outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-libraries-mono outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-libraries-mono outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-libraries-mono outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Outerloop issue is |
|
IIRC there are ways to run chromium headless with a 'fake' framebuffer, window etc. Not sure which one we'd use here, or whether it would actually trigger this. Another option would be a headless X instance paired to VNC, I know people do that for tests sometimes. |
|
I just excluded the test from CI, making it manual test. |
kg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks fine to me
src/libraries/System.Net.WebSockets.Client/System.Net.WebSockets.Client.sln
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.WebSockets.Client/tests/wasm/BrowserTimerThrottlingTest.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.WebSockets.Client/tests/wasm/BrowserTimerThrottlingTest.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.WebSockets.Client/tests/wasm/BrowserTimerThrottlingTest.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.WebSockets.Client/tests/wasm/BrowserTimerThrottlingTest.cs
Show resolved
Hide resolved
|
/backport to release/6.0-rc1 |
|
Started backporting to release/6.0-rc1: https://github.com/dotnet/runtime/actions/runs/1169555771 |
Problem
Chromium browsers throttle
setTimeoutfrequency on inactive pages to 1 sec almost immediately.5 minutes later they throttle heavily to wakeup each 60 seconds.
That breaks dotnet
Timerexpectations and also threadpool.The heavy throttling could be lifted back to 1sec if there was WebSocket activity.
https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#intensive-throttling
Implementation
The idea is to cover the future 6 minutes with "wakeup" timer, each 1 second apart from each other.
1 second, because is the light throttling rate, so it would not help to try to do it more often.
It should be triggered from WS event, so that it's only 1 deep from it.
Every subsequent call would schedule only for uncovered future.
There is
[OuterLoop]unit test for this.Fixes #51041