Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Chrome aggressive resource throttling policy - Slow perf between Chrome tabs #611

Closed
victorb opened this issue Nov 19, 2016 · 9 comments
Closed
Labels
P0 Critical: Tackled by core team ASAP

Comments

@victorb
Copy link
Member

victorb commented Nov 19, 2016

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

@daviddias
Copy link
Member

@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?

@victorb
Copy link
Member Author

victorb commented Nov 21, 2016

@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.

@daviddias daviddias changed the title Chrome to Chrome - Slow performance Chrome to Chrome - Slow performance Nov 21, 2016
@daviddias daviddias added status/deferred Conscious decision to pause or backlog and removed js-ipfs-backlog labels Dec 5, 2016
@daviddias daviddias added exp/wizard Extensive knowledge (implications, ramifications) required help wanted Seeking public contribution on this issue labels Dec 19, 2016
@daviddias daviddias changed the title Chrome to Chrome - Slow performance Chrome aggressive resource throttling policy - Slow perf between Chrome tabs May 10, 2017
@daviddias daviddias removed exp/wizard Extensive knowledge (implications, ramifications) required help wanted Seeking public contribution on this issue labels May 10, 2017
@daviddias
Copy link
Member

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

@fippo
Copy link

fippo commented May 10, 2017

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.

@daviddias
Copy link
Member

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 :)

@taylor-b
Copy link

@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.

@daviddias
Copy link
Member

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.

Found another article referencing this "Feature"

@daviddias
Copy link
Member

daviddias commented Sep 12, 2017

  • Add a distilled version of this issue to the FAQ on the README.

@daviddias daviddias added status/ready Ready to be worked P0 Critical: Tackled by core team ASAP and removed status/deferred Conscious decision to pause or backlog status/ready Ready to be worked labels Oct 17, 2017
@daviddias
Copy link
Member

Documented with #1046. Closing this thread for now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P0 Critical: Tackled by core team ASAP
Projects
None yet
Development

No branches or pull requests

4 participants