-
-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve initial performance for ws #199
Comments
@feross thoughts? |
I was actually thinking of doing the opposite. WebTorrent Desktop has 100% CPU at startup with many torrents active because we need to create so many If you have 10 torrents, with 3 trackers each, that's 30 RTCPeerConnection objects created every few minutes. There's lots of heavyweight stuff happening under the hood in WebRTC unfortunately, so we really need to reduce this number, or do something more clever. I think we need a way to ask the tracker for the peer_ids of the peers that are connected, so we can generate the exact right number of offers. |
300 offers would be generated immediately. That's a lot to start up. But it's something that could be managed in WebTorrent Desktop. I think that generating the peer objects doesn't consume lots of CPU, each. But when taking that to 300 in WD it's a different scenario. In that case we could delay initial discovery with escalation; having complete torrents as last. When adding a new torrent, specially without full torrent and webseeds, the more offers sent => more answers received, initially. 3 trackers right now allow up to 30 initial offers. In a good swarm, things work perfectly. In a bad swarm, or one which peers are firewalled, not so much. Metadata takes time and delays initial render. Sintel infoHash: https://direct.btorrent.xyz/view#6a9759bffd5c0af65319979fb7832189f4f3c35d This infoHash (2nd most peers [12 to be exact] at time of commenting): https://btorrent.xyz/view#42e8de7cf73b3d84a359f0372d454ea04b62bca6. It loads VERY slow. And connects to 2-3 peers within 10 seconds. Up to 5 within 30 seconds. 7 within 2 minutes. Metadata within 7 seconds (Almost twice) |
@feross @DiegoRBaquero could the following be a way to improve start up performance? I noticed that the In the simple-peer documentation it says the following about
In my own testing with simple-peer I found that I get a useful RTC candidate immediately if I set this option to When it was set to p.on('signal', function (data) {
if (data.type == "offer" || data.type == "answer") {
// do something useful with the offer/answer
}
}) Would you accept a patch here that allowed the user to set |
@chr15m Nice. I'm wondering, what type of signal do we receive when set to true that are "useless"? |
@DiegoRBaquero when for offering client: {"type":"offer","sdp":"v=0\r\no=- 1057...00 webrtc-datachannel 1024\r\n"} for answering client: {"type":"answer","sdp":"v=0\r\no=mozilla...THIS_IS_SDPARTA-61.0.1 39 ... tpmap:5000 webrtc-datachannel 256\r\na=setup:active\r\na=max-message-size:1073741823\r\n"} Then signals like this follow afterwards: {"candidate":{"candidate":"candidate:225 ....","sdpMLineIndex":0,"sdpMid":"data"}} {"candidate":{"candidate":"candidate:842163...ork-cost 50","sdpMLineIndex":0,"sdpMid":"data"}} I don't think these candidates can't be used by WebTorrent when doing the websocket signalling introduction. I wonder if there's some good reason why I saw in the |
Looking back through the git history I see that the first implementation already had bittorrent-tracker/lib/websocket-tracker.js Line 122 in 1ff5769
An idea I had was to start some |
After running some tests with |
Maybe we could do 80% trickle in false, 20% trickle in true then. There MIGHT be some usable trickle ice candidates and improve connectivity when there's lots of peers? |
@DiegoRBaquero probably best to gather some data on different devices & networks and see if this ever actually happens before making such a change. I think on good networks trickle=false will return quickly anyway. |
@DiegoRBaquero I did some more testing and I think we can get significantly better connection time performance for some clients without too many changes. I noticed that on my office network initial WebTorrent announce time is very slow, usually incurring a 45 second delay between seed/add & first peers seen. I built a little test page with trickle = true
trickle = false (WebTorrent default)
SuggestionsNote that in the first example with So possible solution:
|
On some networks the iceStateChange=complete will not fire until the browser times out adding tens of seconds of latency even though all valid candidates have been recieved. This patch makes _iceComplete fire early and current offer return after some timeout if we've received valid candidates. See webtorrent/bittorrent-tracker#199 for further discussion.
@DiegoRBaquero I've filed a pull-request against simple-peer which fixes the above issue at that layer. Testing on my "bad" office network where I was getting 45 second delays before WebTorrent peer connections it's now reduced to 5 seconds (the default simple-peer offer timeout setting in that patch). If @feross thinks it should not go into simple-peer I have a patch ready against this repository instead which will implement the fix in Thanks for your time and sorry for all the noise! |
On some networks the iceStateChange=complete will not fire until the browser times out adding tens of seconds of latency even though all valid candidates have been recieved. This patch makes _iceComplete fire early and current offer return after some timeout if we've received valid candidates. See webtorrent/bittorrent-tracker#199 for further discussion.
Hi everyone, The reason that I initially wrote this to use I'm open to reconsidering this decision, but we'd need to make sure that the server load on trackers is reasonable since likely 10x as many messages would need to get sent, though they would be smaller messages. But I think that @chr15m's solution in |
@feross thanks you, yes, very much agree.
I also agree with this. Reducing the number of listening-but-unused WebRTC connections is good. In my testing I've found that Firefox is fine with a huge number of WebRTC offers, but Chrome gets very sad because of this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=825576 |
Yep, I see the Chrome errors about this issue all the time now. |
Since there is a limit in the number of webrtc connections, I think this is a good approach. By adding a new type of message (in the |
On some networks the iceStateChange=complete will not fire until the browser times out adding tens of seconds of latency even though all valid candidates have been recieved. This patch makes _iceComplete fire early and current offer return after some timeout if we've received valid candidates. See webtorrent/bittorrent-tracker#199 for further discussion.
This would improve the initial connection time to other peers.
The text was updated successfully, but these errors were encountered: