Chrome aggressive resource throttling policy - Slow perf between Chrome tabs
victorb opened this issue · 9 comments
I'm playing around with js-ipfs in the browser and made a example on how to send/receive data based on hashes that you can see the source to here and see working in the browser over here.
However, it seems Chrome is a lot slower than Firefox. I'm waiting until I can see that the peers are connected before trying to load.
- Chrome -> Chrome, same tab = Time to load: 21 milliseconds (expected)
- Chrome -> Chrome, separate tabs = Time to load: 28.936 seconds (unexpected)
- Firefox -> Firefox, same tab = Time to load: 43 milliseconds (expected)
- Firefox -> Firefox, different tab = Time to load: 546 milliseconds (expected)
- Firefox -> Chrome = Time to load: 382 milliseconds (expected)
- Chrome -> Firefox = Time to load: 369 milliseconds (expected)
So what I can see, the performance issue only happens when it's between Chrome and Chrome.
Versions
OS: Ubuntu 16.04.1 LTS
Chrome: 54.0.2840.100
Firefox: 49.0.2
@victorbjelkholm to help debugging, did you run these tests in any special network setup? (ie. home router, using VPN, etc)
@fippo does this look like a Chrome issue to you?
@diasdavid at my home connection, no VPN/proxy or anything special, haven't had any issues with IPFS before here so shouldn't be a problem.
After @pgte finding and testing this situation (see #840 (comment)), he discovered that Chrome has aggressive resource throttling for backaground tabs and unfortunately that isn't something we can change.
See this report from TNW https://thenextweb.com/apps/2017/01/26/chrome-throttle-background-tabs-google/#.tnw_WzhZt1q4
are you using http://w3c.github.io/webrtc-pc/#dom-rtcdatachannel-onbufferedamountlow ? If that is throttled... @taylor-b who could look into that? https://twitter.com/webrtc/status/843799556823433217 says webrtc is exempted from this.
Interesting, thanks for jumping in! I need to investigate more and narrow down the throttle, but if that clause exists on Chrome, the slowness we notice might be caused from all the other APIs we use (ie: WebCrypto and IndexedDB).
Btw, you probably have a way to replicate these situations super quickly, any tips and tricks you could share? Thanks :)
@fippo I just did some testing with tip-of-tree with a page that uses "bufferedamountlow" and saw no evidence of it being throttled; it was called thousands of times a second with no problem.
Thanks @taylor-b :) It might be in fact not that WebRTC gets throttled, but the whole app and since we run so many things in user thread land, it gets affected as well.
- Add a distilled version of this issue to the FAQ on the README.