webtorrent.io icon indicating copy to clipboard operation
webtorrent.io copied to clipboard

Published 20 hours ago • verified publisher icon webtorrent

Speed up WebTorrent Desktop downloads with a CDN

Open feross opened this issue 8 years ago • 8 comments

GitHub is silly slow. I bet they're throttling us, since we're using around 600GB of bandwidth per month at the moment. We've received 2 reports of this, and I just experienced a crawling download on a 40Mbps connection. I bet this is affecting our download rates.

Looking into Fastly and MaxCDN at the moment: https://twitter.com/feross/status/780555558713643008

If neither of those can offer us free CDN, then we can try CloudFlare.

feross avatar Sep 27 '16 00:09 feross

With a decent CDN we can create a simple deb repository to provide a native update system for Debian/Ubuntu users.

grunjol avatar Sep 27 '16 00:09 grunjol

@grunjol Do you have a link so I can learn about deb repositories?

feross avatar Sep 27 '16 00:09 feross

You can check the offiical doc here https://wiki.debian.org/HowToSetupADebianRepository

grunjol avatar Sep 27 '16 00:09 grunjol

All the alternatives in the page require a linux installation to run. A month ago I started a node project (not published) to create a simple deb repository, is not functional yet, but i think I can squeeze some time next week to make it happen.

grunjol avatar Sep 27 '16 00:09 grunjol

@grunjol Nice effort -- that would be great to have! Worst case, we can run those commands on the linux server that powers webtorrent.io each time we do a release, but it would be best to have something cross-platform.

feross avatar Sep 27 '16 01:09 feross

Still waiting on Fastly, MaxCDN, and Cloudflare to get back to me with a free CDN account.

In the meantime, I've enabled CloudFlare on the webtorrent.io site, on the Free plan, to evaluate it. Downloads are still linked to github.com in the meantime. DNS propagation will take ~24 hours.

feross avatar Sep 30 '16 06:09 feross

@dcposch I just realized that if we put Cloudflare in front of GitHub releases, then our download stats will get messed up since we pull those numbers from the GitHub API right now.

We probably want to track downloads differently. Most sites seem to direct users to a new page after they click "Download".

See https://www.mozilla.org/en-US/firefox/new/ for example. Then, we can just track hits to that page directly on the server-side.

Thoughts?

feross avatar Sep 30 '16 07:09 feross

We also will need to tell Cloudflare to cache our downloads, since they don't do it for .exe, .dmg, etc. by default:

Which file extensions does CloudFlare cache for static content? https://support.cloudflare.com/hc/en-us/articles/200172516-Which-file-extensions-does-CloudFlare-cache-for-static-content-

Instructions to add new cache rules, e.g. for static HTML https://support.cloudflare.com/hc/en-us/articles/200172256

feross avatar Sep 30 '16 07:09 feross