Open jannikluhn opened 3 weeks ago
Here's some real world timing measurements of message validation and handling during a stress test: https://gist.github.com/konradkonrad/b3c6157bfb9170ecce29df7cf35203e5
Most extreme lines:
2024/06/12 07:13:55.653711 DBG [ messaging.go:40] validated message duration=302.575809ms topic=decryptionKeyShares
2024/06/12 07:13:55.808521 DBG [ messaging.go:304] handled message duration=366.220828ms message-name=p2pmsg.DecryptionKeyShares
2024/06/12 07:13:57.143916 DBG [ messaging.go:40] validated message duration=769.346693ms topic=decryptionKeys
2024/06/12 07:13:57.167785 DBG [ messaging.go:304] handled message duration=21.959567ms message-name=p2pmsg.DecryptionKeys
So it appears the issue is in message validation and handling, not in chain syncing or network propagation.
go test -bench=. ./medley/testkeygen -cpuprofile profile.out
goos: linux
goarch: amd64
pkg: github.com/shutter-network/rolling-shutter/rolling-shutter/medley/testkeygen
cpu: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz
BenchmarkKeyperComputeSecretShares-8 22 52727480 ns/op
BenchmarkSecretKeyGeneration-8 33 36374355 ns/op
BenchmarkFullBlock-8 2 815570668 ns/op
PASS
ok github.com/shutter-network/rolling-shutter/rolling-shutter/medley/testkeygen 116.344s
During key generation, the following steps might take a non-negligible amount of time:
We should investigate how much time each of those steps take when there's few or many keys to produce. We should also check if there's potentially other steps missing in this list. As a result, we will know where to look for optimization potential.