-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[release/6.0-rc1] [wasm] spread WS based timers over next 6 minutes to prevent heavy throttling #58160
Conversation
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackport of #57745 to release/6.0-rc1 /cc @pavelsavara Customer ImpactTestingRisk
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsBackport of #57745 to release/6.0-rc1 /cc @pavelsavara Customer ImpactAs discussed by community in #51041, the way how Chromium throttles inactive/hidden pages is causing problems in reliability of SignalR or other code which relies on dotnet Timers. If the page received WS message in last 6 minutes, the fix prevents browser from heavy throttling (60sec). Light throttling to timer tick (1sec) could not be prevented. This PR improves dotnet timers behavior in those scenarios, but it does not bring it on par with desktop targets. TestingAutomated test on developer machine that proves it works. The code is executed on all unit tests of WASM implementation of ClientWebSocket in our CI pipeline. That should prove that the PR doesn't break any existing functionality. RiskIt introduces small method with new logic
|
Unrelated failure
|
runtime (CoreCLR Product Build windows arm64 release) failure is #48070 |
approved in email |
Backport of #57745 to release/6.0-rc1
Fixes #51041
/cc @pavelsavara
Customer Impact
As discussed by community in #51041, the way how Chromium throttles inactive/hidden pages is causing problems in reliability of SignalR or other code which relies on dotnet Timers.
https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#intensive-throttling
If the page received WS message in last 6 minutes, the fix prevents browser from heavy throttling (60sec). Light throttling to timer tick (1sec) could not be prevented.
This PR improves dotnet timers behavior in those scenarios, but it does not eliminate all throttling.
Testing
It needs to be tested with browser with UI, headless browsers do not throttle the timers.
Automated test written as part of the PR, executed on developer machine that proves it works.
Tested with Chrome, Edge.
The code is executed on all unit tests of WASM implementation of ClientWebSocket in our CI pipeline. That should prove that the PR doesn't break any existing functionality.
Also tested with with Firefox locally, which is not addressed by this PR.
Risk
It introduces small method with new logic
prevent_timer_throttling
which in turn calls existing methods in the mono VM, to execute pending timers and threadpool jobs.