Runtime Support: mobile performance

[xuruijing]

When I first ran the program, from a log point of view, identity generated very slowly, It takes a few minutes, I don't know what caused it。The log is as follows：
2018-06-08T04:14:59.157Z jsipfs EXPERIMENTAL Relay is enabled 2018-06-08T04:14:59.564Z jsipfs booting 2018-06-08T04:14:59.664Z jsipfs boot:done 2018-06-08T04:14:59.664Z jsipfs init 2018-06-08T04:14:59.664Z jsipfs repo exists? false 2018-06-08T04:14:59.664Z jsipfs generating peer id: 2048 bits 2018-06-08T04:19:30.065Z jsipfs identity generated

[mistakia]

Follow the steps here to speed up the nodejs process.

[mistakia]

Also - bundling the nodejs files (using browserify) seem to make a huge difference in performance. I'll push an update in the near future.

[xuruijing]

I've updated the nodemobility. framework, but it doesn't seem to have a significant impact on performance. At present, I am mainly blocking the "jsipfs identity generated" place at the first run time (which will not be run later), and waiting time is longer to start the "main.js" run

[mistakia]

Strange - that made a pretty big difference for me - cut it down from 6-7 mins down to 1-2 mins. The other thing to try is bundling via browserify - that made the biggest difference for me.

Inside nodejs-assets/nodejs-project run the following:

browserify -o bundle.js --node --im -u "leveldown" main.js

Then in src/views/components/app/App.native.js change the nodejs script location from main.js to bundle.js. Then make sure to then build the ios bundle (via npm run build:ios) before running on a device.

[mistakia]

You can also lower the bits to 1024 via the ipfs config - that'll speed up key generation but you'll have a weaker key which shouldn't be an issue for most applications.

[xuruijing]

Running on the iOS simulator runs out of nearly all the CPU resources. If there are other threads, it will be difficult to run. Is there any way to optimize performance, such as reducing the number of ipfs connections

[mistakia]

libp2p just merged libp2p-connection-manager.

Once js-ipfs updates libp2p you should be able to limit connections.

However, I think the cpu/memory performance has more to do with nodejs-mobile.

Are you bundling your nodejs script with browserify before running?

[xuruijing]

Ipfs does start up a lot faster with bundle.js (the current code), and the CPU load continues to change between 100% and 0% after startup, much lower than it was before at 99%. But memory usage is much higher. So it seems that nodejs-mobile uses CPU/memory more than libp2p

[xuruijing]

Is there any further optimization

[mistakia]

hmm - for me I saw improvement in memory usage as well. What is your ipfs config?

[xuruijing]

I used ipfsd-ctl.
const optionsIpfsd = { disposable: false, repoPath: repoFile, exec:IPFS, config:{ Addresses: { Swarm: [ ] } } }
I think the current memory usage is still acceptable, mainly about whether the use of CPU can be reduced

[mistakia]

The only thing I do differently is set Bootstrap: [] and then point it to my own lib-p2p-websocket-star rendezvous service which only has 1-2 peers.

[mistakia]

I also use the js-ipfs lib directly but that shouldn't make a difference

[xuruijing]

const ipfsConfig = { init: { bits: 1024 }, repo: path.resolve(recorddir, './ipfs'), EXPERIMENTAL: { dht: false, // TODO: BRICKS COMPUTER relay: { enabled: true, hop: { enabled: false, // TODO: CPU hungry on mobile active: false } }, pubsub: true }, config: { Bootstrap: [], Addresses: { Swarm: [ '/ip4/159.203.117.254/tcp/9090/ws/p2p-websocket-star' ] } } }
The above is your ipfs config, which is different from mine. Will it affect performance?

[mistakia]

see above - for my explanation of the difference.

It will impact performance mainly because it will be interacting with fewer peers - thus less muxing, etc.

I wouldn't quite classify this as a performance enhancement though. Your best bet on this front is to wait for the connection manager to get integrated.

[xuruijing]

Is there a performance difference between adding Swarm: [ '/ip4/159.203.117.254/tcp/9090/ws/p2p-websocket-star' ] and not adding this to your configuration file? And is there any difference in CPU performance between running your code on your phone and running it in the simulator? In my case, it's no different. Once run the IPFS code, the CPU goes up to 100% and it continues

[mistakia]

I find that simulator is more performant than my iPhone 6+.

There shouldn't be too much difference between adding that swarm address because there's usually only one peer thats connected to that one, as its my own personal websocket discovery service.

For me, the CPU goes up to 100% on load but then drops back down after a minute or so.

[xuruijing]

Do you mean connectionManager in jsipfs configuration items? The latest version of 0.30 should already be supported. What is the maximum number of connections?

[mistakia]

Yes - by default the maximum number of connections is Infinity. More info under connectionManager in IPFS Constructor.

[xuruijing]

I set the maximum number of connections to 5, and it doesn't seem to change anything

[mistakia]

It's because of this: libp2p/js-libp2p#224

[xuruijing]

This problem has been closed, does it mean that this problem has been solved and we can use it directly?

[mistakia]

It'll be available in the upcoming [email protected] version. You can pull it directly from github and override the dep in ipfs for now.

[xuruijing]

I have used [email protected] version, and the situation has not improved. My current situation is that once a cat or add method is called on a slightly larger file (using a local file), the CPU immediately jumps to 99%, causing the wait time to be particularly long, and the situation is so bad that it feels unusable. Is there any other possibility of improvement, nodeJs or ipfs?

[xuruijing]

Ipfs starts up very quickly after browserify. Could you also use browserify when executing other ipfs commands (such as cat,add, etc.)? I don't know about browserify, so could you give me some guidance in this regard?

[xuruijing]

The use of the latest nodejs package has significantly improved the running speed