Daemon much slower than CLI for starting nodes

[CJClaude]

Package Versions

Replace the values below using the output from storjshare --version.

 * daemon: 2.1.0, core: 6.0.13, protocol: 1.1.0

Replace the values below using the output from node --version.

6.9.2

Expected Behavior

Startup speeds should be similar between the old CLI and the current Daemon approach.

Actual Behavior

I use to be able to start up 1160 nodes in slight under 20 minutes, simply by invoking a startup in backgroun followed by a 1 second sleep (in order to avoid trashing the OS). All nodes would then run as expected.

Using the daemon on the same system, each startup takes 8-9 seconds, requiring over 3 hours to spin up all 1160 nodes. Attempts to start in parallel, by running the command in background and spawning them 1 second apart like what was done with the CLI, appears to work, although nodes get started out of order and still apparently only one at a time, 8-9 seconds apart - by the time all where done, over 500 had disappeared

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

1. ...
2. ...
3. ...

[tacticalchihuahua]

Can you share the method you are using to start your nodes?

[CJClaude]

Bash script that functionally issues a bunch of:

storjsjhare start -c /storj/nodexx/config

commands.:

storj@fs2 ~ $ cat storj.begin
storjshare killall
sleep 10
storjshare start -c /storj/node000/config
storjshare start -c /storj/node001/config
storjshare start -c /storj/node002/config
storjshare start -c /storj/node003/config
storjshare start -c /storj/node004/config
storjshare start -c /storj/node005/config
storjshare start -c /storj/node006/config
storjshare start -c /storj/node007/config
storjshare start -c /storj/node008/config
storjshare start -c /storj/node009/config
storjshare start -c /storj/node010/config
storjshare start -c /storj/node011/config
storjshare start -c /storj/node012/config
storjshare start -c /storj/node013/config
storjshare start -c /storj/node014/config
storjshare start -c /storj/node015/config

[tacticalchihuahua]

Ah, so reason it is taking so long is because each command is establishing a new connection to the daemon, sending RPC, daemon receives and validates config, forks share process, responds to RPC, then closes connection. There is also a short artificial delay between the beggining of this and end to ensure the connection to the daemon is opened and closed cleanly.

The best way to start a series of nodes is to get them all running as you like and then running storjshare save to create a snapshot. This will let you later resurrect all the shares with one command storjshare load which eliminates the latency added by running each command separately. It will fork N shares with a degree of parallelism until all are running.