feat: latency test for restore #3956
Conversation
| ); | ||
| // FIXME: should be smaller | ||
| assert!(reissue_stats.median < Duration::from_secs(4)); | ||
| assert!(ln_sends_stats.median < Duration::from_secs(6)); | ||
| assert!(ln_receives_stats.median < Duration::from_secs(6)); | ||
| assert!(restore_time < Duration::from_secs(160)); |
There was a problem hiding this comment.
It was 83 on my machine, I multiplied with factor of 2 to account for CI slow down.
There was a problem hiding this comment.
This may or may not work as you could have been at an arbitrary point inside the current session. If you start restoring at the end of a session it will take shorter, if you start at the beginning it will take longer. #3956 (comment)
But let's just see how it does on master and narrow down the allowed time as we optimize restoring.
maan2003
force-pushed
the
measure-restore-time
branch
from
fc908a7
to
7d1345a
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #3956 +/- ##
==========================================
- Coverage 56.97% 56.95% -0.03%
==========================================
Files 193 193
Lines 43180 43200 +20
==========================================
+ Hits 24602 24604 +2
- Misses 18578 18596 +18 ☔ View full report in Codecov by Sentry. |
maan2003
force-pushed
the
measure-restore-time
branch
from
7d1345a
to
343918f
Compare
|
@maan2003 Are you on latest master? |
|
During Alepbft refactor the prefetching of epochs was removed "for simplicity" and at the time I was suspecting it will lead to poor performance, so that would be my first bet. https://github.com/fedimint/fedimint/pull/3227/files#r1368997856 |
I was testing on 0.2 branch. but now rebased to master. |
|
There's also a random, constant slowdown: we wait for the session we started recovery in to end so we get all transactions we may have missed (since currently we don't have an API for fetching transactions from a running epoch) |
|
@maan2003 the restore invocation uses named arguments, that's why CI is failing. |
maan2003
force-pushed
the
measure-restore-time
branch
from
343918f
to
7c04321
Compare
| ); | ||
| // FIXME: should be smaller | ||
| assert!(reissue_stats.median < Duration::from_secs(4)); | ||
| assert!(ln_sends_stats.median < Duration::from_secs(6)); | ||
| assert!(ln_receives_stats.median < Duration::from_secs(6)); | ||
| assert!(restore_time < Duration::from_secs(160)); |
There was a problem hiding this comment.
This may or may not work as you could have been at an arbitrary point inside the current session. If you start restoring at the end of a session it will take shorter, if you start at the beginning it will take longer. #3956 (comment)
But let's just see how it does on master and narrow down the allowed time as we optimize restoring.
|
Needs rebase :( |
maan2003
force-pushed
the
measure-restore-time
branch
from
7c04321
to
a92c47b
Compare
restore has become really slow, we need to track these.