You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To benchmark the improvement from #789, I analysed the latency of messages between maker receiving TakerCommit and sending out Reveal, since @TheCharlatan reported seeing massive latencies between these on fc.dev (mostly running 50 swaps in parallel), and which we suspected to be due to walletd being a bottleneck, likely due to a queue of dleq proofs to produce.
Below is the CDF of latencies between maker receiving TakerCommit and sending out Reveal, comparing #789 with ed4247f (#792).
Although we also merged some other PRs inbetween, these were almost certainly unrelated, and I think the data confirms the suspicions was true:
For later reproducibility, the data is bash foo'd from our logs as follows:
This can then be piped on via sort -n | uniq -c for a rudimentary histogram ^^
I'd like to use this issue to track performance in future too, both for future performance improvements and for stress testing with more than 50 concurrent swaps to identify the next frontier of bottlenecks (although I should be done with my performance junkie fix now :P).
The text was updated successfully, but these errors were encountered:
To benchmark the improvement from #789, I analysed the latency of messages between maker receiving
TakerCommit
and sending outReveal
, since @TheCharlatan reported seeing massive latencies between these on fc.dev (mostly running 50 swaps in parallel), and which we suspected to be due towalletd
being a bottleneck, likely due to a queue of dleq proofs to produce.Below is the CDF of latencies between maker receiving
TakerCommit
and sending outReveal
, comparing #789 with ed4247f (#792).Although we also merged some other PRs inbetween, these were almost certainly unrelated, and I think the data confirms the suspicions was true:
For later reproducibility, the data is bash foo'd from our logs as follows:
This can then be piped on via
sort -n | uniq -c
for a rudimentary histogram ^^I'd like to use this issue to track performance in future too, both for future performance improvements and for stress testing with more than 50 concurrent swaps to identify the next frontier of bottlenecks (although I should be done with my performance junkie fix now :P).
The text was updated successfully, but these errors were encountered: