Conversation
Could this be why my |
Hmm, I don't think so: this was lightningd. connectd does do all the crypto now, so perhaps it's a bottleneck on large nodes? The best way to know for sure is: And let it run for 30 seconds, then ^C and do perf report? |
2070043 to
872aa9a
Compare
wallet should really be a subdir of lightningd. Signed-off-by: Rusty Russell <[email protected]>
They're used in several places, and we're about to add more. Signed-off-by: Rusty Russell <[email protected]>
872aa9a to
10ce921
Compare
|
Rebased, fixed another test which assumed peer order. |
|
The python linter seems not to be happy with this one: |
Hash table coming up makes it random! Signed-off-by: Rusty Russell <[email protected]>
After connecting 100,000 peers with one channel each (not all at once!), we see various places where we exhibit O(N^2) behaviour. Fix these by keeping a map of id->peer instead of a simple linked-list. Signed-off-by: Rusty Russell <[email protected]>
Otherwise, loading up when we have 100k peers is *painful*! Signed-off-by: Rusty Russell <[email protected]>
10ce921 to
3672dcd
Compare
|
"This time for sure!" |
| } | ||
|
|
||
| /* We need to define a hashing function. siphash24 is a fast yet | ||
| * cryptographic hash in ccan/crypto/siphash24; we might be able to get away |
There was a problem hiding this comment.
I had to dig into this a bit, it seems the hash function is collision resistant if keyed with a random key, which we do here. It is not generally cryptographically secure, and loses collision resistance if the attacker knows the key.
| if result['channels'][0]['peer_id'] == l3.info['id']: | ||
| result['channels'] = [result['channels'][1], result['channels'][0]] |
There was a problem hiding this comment.
result['channels'] = sorted(result['channels'], key=lambda c: c['peer_id'])
| /* FIXME: We should notify onchaind about NORMAL fee change in case | ||
| * it's going to generate more txs. */ |
There was a problem hiding this comment.
Is this comment no longer necessary?
There was a problem hiding this comment.
Technically still true, but my branch which does zero-fee anchors fixes this (onchaind no longer makes its own txs). Overzealous removal I guess.
|
Weird, this was already merged by @endothermicdev . Not sure why GH didn't notice. |
(Based on #5868 which changes htables to need to be tal'ocated, simply to avoid merge hell!)
I hacked the code to ignore signatures so I could quickly open 100k peers with one channel each, and looked at how the node responded. Two simple fixes (linked lists were the culprit) and such a node is manageable (though not exactly speedy!).
Before this, reconnecting to all the peers took longer and longer (noticeable before we even had 10k peers). And startup was extremely slow (not sure how bad it was, I gave up!).
It still takes 9 seconds to listpeers, and almost a minute to startup, and database is about 185MB.
Changelog-None Not user visible.