Ipfs-companion: Companion is always at [medium] in about:performance in Firefox

[autonome]

[lidel]

Thank you for noticing this.
I made a quick check and it is caused by setInterval running in the background page.

Companion is polling IPFS API every 3 seconds to refresh the peer count displayed on browser action badge and detect IPFS node going online/offline. IIRC we use setInterval instead of browser.alarms because Chrome hardcoded min interval to be 1 minute.

We could increase IPFS API poll interval but it would impact UX around online/offline detection.

Potential mitigation:

• Remove peer count from browser badge to hide the fact we refresh state
  
  
  
  • been thinking about it anyway, peer count is just a vanity number without practical value. what is actually important is the icon color (aqua == online, grey == offline).
  
  
• Pick bigger polling interval (10s? 30s?) in 'idle' mode (when browser action UI is hidden)
• Poll API every 2s when browser action UI is visible

Thoughts?

[autonome]

What is the use-case for seeing the peer count? What decisions are
companion users making that is based on seeing that number change?

On Sun, May 19, 2019 at 1:27 PM Marcin Rataj [e-mail]
wrote:

Thank you for noticing this.
I made a quick check and it is caused by setInterval running in the
background page.

Companion is polling IPFS API every 3 seconds to refresh the peer count
displayed on browser action badge and detect IPFS node going
online/offline. IIRC we use setInterval instead of browser.alarms
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/alarms
because Chrome hardcoded min interval to be 1 minute.

We could increase IPFS API poll interval but it would impact UX around
online/offline detection.

Potential mitigation:

• Remove peer count from browser badge to hide the fact we refresh
  state
• Pick bigger polling interval (10s? 30s?) in 'idle' mode (when
  browser action UI is hidden)
• Poll API every 2s when browser action UI is visible

Thoughts?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ipfs-shipyard/ipfs-companion/issues/721?email_source=notifications&email_token=AAAMHNZHKMCW6E2U6YKD7Q3PWGZ35A5CNFSM4HNYQCNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVXJ5YI#issuecomment-493788897,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAMHNY5ENIQTTHPG45DYSDPWGZ35ANCNFSM4HNYQCNA
.

[lidel]

It is an indicator of connectivity health:

• 0 - no peers, means we are still connecting to the swarm or that there is a network issue
• > 0 - number of connected peers, mostly a vanity number
  (the goal of adding it to browser action badge was to highlight participation in p2p network)
• -1 - internal value (never shown in UI) indicating API is offline (ipfs icon and UI is greyed out)

User does not do much with this, but IPFS Companion makes various decisions based on peering state. Peer count >= 0 means API is online, which in turn enables features that require access to API (quick upload) or Gateway ("Automatic Mode" enables/disables redirect to local node based on connectivity state).

[autonome]

In that case, the mitigation sounds good. The decision state is "connected"
or not, and that's conveyed in a reasonable enough way even at every 30s
(for now).

When the stack as a whole is faster, maybe there's argument for
near-real-time updates... but at that point we'll likely have a better way
of getting this information than polling.

I like the idea of using peer count to hint at participation level for good
feels, but it doesn't trump battery life.

Network requests on an interval are basically a "perfect storm" wrt battery
consumption. Do we not have any other options?

A couple of other thoughts, but maybe pre-optimizing:

• Trigger peer update when any part of Companion is interacted with, or we
  detect webui being opened, etc? Maybe would reduce the (already small, even
  with the mitigation) chance that connection state is out of sync.

• Instead of our own timer, use idle interval callbacks so that we never
  eat battery without reason:
  https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/idle

[lidel]

I've been thinking about "triggering peer update when any part of Companion is interacted with" and we may be able to make it pretty "lazy":

• remove peer count from badge
  
  
  
  • (ux decision)
    
    add unique icons for -1 and 0 states
    
    OR
    
    repurpose browser action icon to indicate if current page is hosted on IPFS
  
  
• keep a timestamp of the last peer count check
• poll 'close realtime' (eg. every 3s) when browser action or other part of UI that requires API is open
• stop polling when mentioned UIs are hidden (or do it once a minute+ via alarm)
• use requests for IPFS resources as hints to do the API availability check
  
  
  
  • when IPFS resource is detected in web​Request​.onBefore​Request check if timestamp of last refresh is within some threshold before deciding if request should be redirected to local gateway
  
  
  • if peer count value is too old, perform peer count update
  
  
• respect IdleState from browser.idle (we already run update only in active state, but we could decrease default idle threshold from 60s to a lower value)

Does it sound sensible?

[autonome]

Nice to have: Some instrumentation so we can check different before/after these changes.

[olizilla]

Here because I just hit the same issue.

Of note, I'm seeing this with "all ipfs integrations" set to off.

I'm a big plus 1 of removing the peer count from the badge. I think we should generally reduce the prominence of how many peers you are connected to; it's doesn't tell you if you're going to have a good time finding the content you want. Zero peers means you are going to have a bad time, so we could special case that, but... for companion, I think it's way more interesting to focus the badge on "hey! this page comes in IPFS flavour", when we lazily check for a dnslink after letting the http request have a go... #710

[lidel]

Related: Firefox 76 will ship with a new profiler marker to include information about the webRequest blocking handlers registered by extensions (Bug 1625006).