IPFS Virtual Meetups, 11 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sharing IPFS: Optimizing for Web Browsers - Irakli Gozalishvili

Description

You don’t want to miss the pure artistry that went into this lightning talk that perfectly illustrates the relationship between IPFS and web browsers.

For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS

Sign up to get IPFS news, including releases, ecosystem updates, and community announcements in your inbox, each Tuesday: http://eepurl.com/gL2Pi5

A

I've been working with some people at protocollabs on some optimization work, uh for I sharing ipfs node in the browsers, um so it's a gonna be a brief crash course. The conventional web browsers tend to expect that all the data are gonna, be funneled to them through one server farm, and that can be really really efficient and it works great.

A

However, it has downsides if you have multiple devices that are also trying to get the same data, so even if they're in the same room, they will still have to go over through that server farm to get it.

A

Ipfs works slightly differently than that. It usually creates many many network connections uh and then tries to talk to those peers directly. So if you use jsipfs in the browser like this demo shows, this is briefly how it works.

A

However, if you kind of look under the covers, there are some issues with that. uh There are a lot of stuff happening, there's a lot of connections, data being processed. So all this kind of adds up, and especially because it runs in the main thread.

A

Browser is pretty busy executing stuff on the main thread, so at least on my machine, which is macbook air. I usually get around 6.3 megabytes usage per one tab in the browser and I don't exactly know how many network connections. However, once you open another tab, you wind up with doubling the amount of memory you use and doubling the number of connections you create, even though you share the same data store, and this number just kind of keeps increasing linearly multiplied by the number of tabs you have open.

A

That is because we don't necessarily share anything other than store within the between the browser tabs. uh There's also some few other problems that arise by that, because they end up sharing the same data source. They end up sharing the same peer id and then network gets a little confused because you wind up with multiple peers with the same id, and usually only one of them gets really connected so again like if you just open, 10 tabs with ipfs same apps that I showed you will have around 64 megabytes memory use.

A

But we can do better than that, and this is the work that I've been doing here. We were trying to do some ipfs node sharing, so you see the same example application, but this one uses a shared node.

A

The thing that changed here is, instead of connecting directly to the network, we have a shared worker in the browser and that's where ipfs node is running and it's sharing uh in connect to the network.

A

If you look at the memory profile of this, it's slightly worse for the single tab use case, because we have about six megabytes taken by the worker around 2.3 by the main thread.

A

However, as you kind of end up, creating more tabs you'll start seeing benefits even with two tabs, you suddenly equation changes. You will still use the same six megabytes in the shared worker, but then two different apps will connect to it and they each use about 2.3 megabytes of memory and even nicer thing is. uh We don't have that issue with a network connections anymore because they are shared. So we don't increase network connections and all the subsequent tabs.

A

They don't need to bootstrap node because they all share and as number increases like, if we look at the same number of 10 tabs, you will have same end. Connections and you'll have about 30 megabytes memory usage, which is about a half as you would. Otherwise, um what's even more starking is a cpu load, um I'm a little pr, not sure if my numbers are here correct, but I see in this demo I tried to profile 10 tabs on chrome, which was taking about 18 percent of my cpu load.

A

uh Then I tried the demo that uses a share node and with 4 40 tabs. It takes about 2 of cpu.

A

If you want to know how to use it or start using it. Today uh there are packages on npm and it's part of github igs ipfs repo.

A

There are two pieces, one is a client and a server. So client is very similar to how http client works. You can you can spawn a worker with a server uh with the js ipfs in it, and then you can connect through the message port to the client and then client implements the ipfs api. So you can add files and read files and do stuff like that on the server side, you just create a server and pass it the js ipfs instance, and it will serve it to all of its clients.

A

um So what's there a lot of patches there? Still in the pipelines that will be coming, that will reduce some overhead. All that current implementation has um at the moment. All of this work is focused on the sharing node across the same browser origins.

A

uh Getting it to work across multiple origins is slightly more work, so that's what will be coming next and so the process we sort of also identified some of the things that uh maybe it makes sense to have something like ipld with ipfs network and we're calling it for now dag service, uh because that seems to be the subset of apis that most of the users we talk to are using cs4.

A

I want to say thank you to everyone who helped make this happen, both within ipl, fs or sorry. Protocol labs and outside specifically, three books, textile orbit and flick were instrumental to providing feedback, look and uh sharing what they use, how they use. So we can so we could calibrate the work to that.

A