Re: Question about the IntensiveWakeUpThrottlingEnabled

[François Doray]

Hi Marcio,

The feature throttles Javascript Timers (setTimeout and setInterval) and Web scheduling tasks (scheduler.postTask) only. It does not affect Web Sockets. You can launch Chrome with the feature disabled by specifying --disable-features=IntensiveWakeUpThrottling on the command line, to see how it affects the behavior of your application. You can also learn more about the feature in this blog post https://developer.chrome.com/blog/timer-throttling-in-chrome-88/

Have a nice day,

François

On Thu, Jun 16, 2022 at 1:35 PM Developer Invoxcontact <deve...@invoxcontact.com> wrote:

Good afternoon,

We are one of the biggest telecom companies in Spain (numintec.com) and we suspect the "IntensiveWakeUpThrottlingEnabled" feature introduced to Chrome last year is affecting thousands of our users, so I hope you can help us understand if this is really the issue and how to overcome it.

We have many contact center web products that are used by thousands of agents worldwide. These web applications use a WebSocket to continuously receive live events about the contact center (call events, agents logging in and out, etc) to keep the UI updated in real-time. Since last year our clients started reporting some data mismatch (an agent who is showing "on-call" when the call was already terminated, for example) and we suspect this happens when leaving the browser tab on the background for a while, which led us to find out about the "IntensiveWakeUpThrottlingEnabled".

For the past 10 months or so, we tried many different strategies in our back and frontend to resolve the issue, and although we could reduce the frequency of the issues, we couldn't resolve it completely and we are still struggling with it today.

I would like to confirm with you that this feature could actually be causing the issue by cutting the WebSocket connection and causing the browser to miss some real-time events. Also, I would like to ask you for a code example of how our page could opt out from this feature as we saw this is possible.

I hope to hear from you soon.

Kind regards,

Marcio Maia

[Developer Invoxcontact]

Hello François,

Thank you very much for your fast reply. I have reviewed our WebSocket connection and it uses libraries that use JS Timers (setTimeout and setInterval) so maybe that could be causing the problem. We are investigating the possibility of using our socket as a Web Worker as apparently Chrome doesn't throttle the web workers, is that correct?

Would you or any of your colleagues be available to help us find a solution as a freelancer?

I really appreciate your help. Have a wonderful weekend ahead!

Kind regards,

Marcio

[François Doray]

Hi Marcio,

As explained here https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#intensive-throttling, timers are only intensively throttled after some recursion depth is reached. A one-off timer fired from a Websocket event handler won't be intensively throttled. Would it be possible to adjust your code to avoid deep timer recursion?

Feel free to share links to the library you're using, code snippets and/or repro steps that we could try. However, I cannot promise dedicated support.

Have a nice day,

François

[Developer Invoxcontact]

Hello François,

The challenge is that we use some WebSocket libraries that use timers and we have no control over what they are doing. We are trying to get rid of these libraries and accomplish the same WebSocket functionalities while eliminating all the timers. In parallel, we will prepare an HTML example where you can reproduce the issue we are facing. Please allow me a few days and I will send it to you once we have it.

Thank you very much once again for your assistance.

Have a wonderful week ahead!

Regards,

Marcio