Skip to content

Add a simple send-funds benchmark in channelmanager #860

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Apr 1, 2021

Conversation

TheBlueMatt
Copy link
Collaborator

I saw https://twitter.com/bottlepay/status/1376918214249218049 and was curious, so I benchmarked sends.

We're doing pretty good - on my local machine somewhere in the neighborhood of 5-6ms for two full back-and-forth sends, ignoring all IO latency.

While its not necessarily a common operation on a running node,
`get_our_node_id()` is used incredibly heavily in tests, and there
is no reason to not eat the extra ~64 bytes to just cache it.
@codecov
Copy link

codecov bot commented Apr 1, 2021

Codecov Report

Merging #860 (1424b28) into main (6fcac8b) will increase coverage by 0.02%.
The diff coverage is 100.00%.

❗ Current head 1424b28 differs from pull request most recent head 8a9f0b8. Consider uploading reports for the commit 8a9f0b8 to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##             main     #860      +/-   ##
==========================================
+ Coverage   90.60%   90.62%   +0.02%     
==========================================
  Files          51       51              
  Lines       27193    27195       +2     
==========================================
+ Hits        24637    24646       +9     
+ Misses       2556     2549       -7     
Impacted Files Coverage Δ
lightning-persister/src/lib.rs 95.61% <ø> (ø)
lightning/src/ln/functional_test_utils.rs 95.21% <ø> (ø)
lightning/src/ln/channelmanager.rs 83.23% <100.00%> (+0.01%) ⬆️
lightning/src/util/test_utils.rs 82.95% <100.00%> (ø)
lightning/src/ln/functional_tests.rs 97.02% <0.00%> (+0.12%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6fcac8b...8a9f0b8. Read the comment docs.

@TheBlueMatt
Copy link
Collaborator Author

Our naive persister...not so much, its currently showing around 100ms for a full back-and-forth send, at least after some time as the ChannelMonitor has been allowed to grow to some size.

@TheBlueMatt
Copy link
Collaborator Author

Note that if you swap to flushing the ChannelMonitorUpdates instead (which we should do eventually, but not today), you get a much more reasonable 69ms (+/-35).

@TheBlueMatt
Copy link
Collaborator Author

If you go even further and cut out the duplicate fsync and file rename for ChannelMonitorUpdate writes we get down to 19ms-per-two-sends, which is much more reasonable. Branch is at https://git.bitcoin.ninja/index.cgi?p=rust-lightning;a=shortlog;h=refs/heads/2021-03-optimize-chanmon-persist if anyone wants to go implement the reading logic for it so we can take it https://git.bitcoin.ninja/index.cgi?p=rust-lightning;a=shortlog;h=refs/heads/2021-03-optimize-chanmon-persist

Copy link
Contributor

@arik-so arik-so left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it might make sense to also make a slightly more complicated benchmark with one routing node in between?

Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approve mod CI warning :)

use test::Bencher;

struct NodeHolder<'a, P: Persist<InMemorySigner>> {
node: &'a ChannelManager<InMemorySigner,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be curious to compare this to an Arc'd version (i.e. using arcs instead of refs)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be astounded if it made a difference - we aren't actually cloning the Arcs anywhere that I know of here and our runtime is dominated by cryptographic operations. Non-Arc objects are nice mostly because we'd like to eventually support non-threaded applications, so we don't need trait implementations to implement Sync+Send.

@TheBlueMatt TheBlueMatt force-pushed the 2021-03-bench-sends branch from 1424b28 to 8a9f0b8 Compare April 1, 2021 19:15
@TheBlueMatt
Copy link
Collaborator Author

Only difference from previous ACKs is fixed the compile warning:

$ git diff-tree -U2  79b3e5d6dfabf1e4fd3fb79589b6afa7d4a33d0d 8a9f0b8cedaf63a921456a27dea9ecba88f3ebcd
diff --git a/lightning/src/ln/functional_test_utils.rs b/lightning/src/ln/functional_test_utils.rs
index 8021a4ace..3c641dd74 100644
--- a/lightning/src/ln/functional_test_utils.rs
+++ b/lightning/src/ln/functional_test_utils.rs
@@ -867,4 +867,5 @@ macro_rules! expect_pending_htlcs_forwardable {
 }
 
+#[cfg(any(test, feature = "unstable"))]
 macro_rules! expect_payment_received {
 	($node: expr, $expected_payment_hash: expr, $expected_recv_value: expr) => {
$

@TheBlueMatt
Copy link
Collaborator Author

Do you think it might make sense to also make a slightly more complicated benchmark with one routing node in between?

Hmm, there should be almost no difference there, forwarding vs initial send should be completely dwarfed by cryptographic operations. If you don't mind, I'd prefer to just take this as-is and we can follow up with more benchmarking if we think its merited later.

@TheBlueMatt TheBlueMatt merged commit df732f4 into lightningdevkit:main Apr 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants