CPU bound at high download speeds – need resource management

[dcposch]

What version of WebTorrent?
WebTorrent Desktop 0.17.2

What operating system and hardware?
MacOS Sierra

2016 12" Macbook, plugged in

What did you expect to happen?
Download speed limited only by available network bandwidth and peers.

What actually happened?
It looks like WebTorrent is saturating the CPU during fast downloads:

[dcposch]

@feross two ideas:

1. We could use the node profiler to figure out where WebTorrent is spending time in JS
2. If it turns out as I suspect and a lot of time is spent in Chromium because of WebRTC, then we could try setting a global limit on the number of peers we talk to at once. We'd prioritize the fastest peers.

[DiegoRBaquero]

My guess is that the hashing to verify the pieces is the CPU-consuming monster.

[feross]

@dcposch We ought to do both IMO

[sliterok]

Also ram consumption is really heavy

[catchstar]

@sliterok
i have the same issue. Webtorrent can't release the memory even i have removed the torrent by client.remove(). When i add some more magnet it occurs an memory leak error.
Do you have solve the problem? please tell me.
the same issue: #1104

[sliterok]

@catchstar
Hm, i've experienced memory leaks only when i download something.
BTW I haven't solved this trouble, but now i'm using qbittorrent.

[catchstar]

@sliterok
i see. Thank you.

[crzidea]

I have the same issue. Can't release memory after remove torrent.

[crzidea]

Solved, this issue is caused by dht options. Tune the option to reduce resource usage.

[catchstar]

@crzidea
i don't think this is a good solution because when use webtorrent to download by magnet it will fail because of tune the dht option to false.
i still can't solve this issue.

[crzidea]

@catchstar No need to set the option to false, just tune the numbers for torrent-dht.

[catchstar]

@crzidea
Thanks a lot. it works.

[CyberShadow]

Here is a trace I did back in April for webtorrent-cli. The process becomes so CPU-bound, that the player can't even request more chunks quickly enough for continuous playback, despite webtorrent-cli having already downloaded a big % of the file.

Looking at the trace, it looks like validateWire is the likely culprit. It seems to be called from a lot of places and seems to do a lot of work.

[vankasteelj]

subscribing (from #1224 )

What's your DHT tuned option? I'm only using this so far:

Streamer.client = new (require('webtorrent'))({
  maxConns: 40,
  tracker: {
    wrtc: false
  }
});