Skip to content
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

Benchmark message handling #455

Draft
wants to merge 9 commits into
base: main-gnosis-merge
Choose a base branch
from

Conversation

jannikluhn
Copy link
Contributor

@jannikluhn jannikluhn commented Jun 17, 2024

To run them try the following commands:

go test ./keyper/epochkghandler/... -bench ^BenchmarkValidateKeysIntegration$ -run ^$
go test ./keyper/epochkghandler/... -bench ^BenchmarkHandleKeysIntegration$ -run ^$
go test ./keyper/epochkghandler/... -bench ^BenchmarkHandleFirstKeySharesIntegration$ -run ^$
go test ./keyper/epochkghandler/... -bench ^BenchmarkValidateFirstKeySharesIntegration$ -run ^$
go test ./keyper/epochkghandler/... -bench ^BenchmarkHandleFirstKeySharesIntegration$ -run ^$
go test ./keyper/epochkghandler/... -bench ^BenchmarkValidateSecondKeySharesIntegration$ -run ^$
go test ./keyper/epochkghandler/... -bench ^BenchmarkHandleSecondKeySharesIntegration$ -run ^$

jannikluhn and others added 8 commits June 13, 2024 18:16
The tests use the eon instead of the keyper config index in the eon
fields of messages. They also prevented messages with duplicate
identity preimages which are used in Shutterized Gnosis Chain.
This simplifies the tests. We use the underlying EonKeys struct instead.
The only functionality we lose is automatically generating a new eon key
after a set number of identity preimages. However, we don't cycle
through eon keys in production anyway.
Shared preparation is done in dedicated setup functions. Key share
benchmarks come in two flavors, first and second. First benchmarks the
first arriving share, second the second. The idea is that the second
results in a decryption key being generated. The first doesn't have
enough key material to do so yet.
@konradkonrad
Copy link
Contributor

I had to start a local postgres instance in order for this to run:

docker run --rm -it -e POSTGRES_USER=pguser -e POSTGRES_PASSWORD=password -e POSTGRES_DB=testdb --net=host cimg/postgres:13.9

Then I had to set an environment variable:

export ROLLING_SHUTTER_TESTDB_URL=postgres://pguser:password@localhost:5432/testdb

@konradkonrad
Copy link
Contributor

Are these results comparable to what you are seeing?

goos: linux
goarch: amd64
pkg: github.com/shutter-network/rolling-shutter/rolling-shutter/keyper/epochkghandler
cpu: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz
BenchmarkValidateKeysIntegration-8                      1000000000               0.6120 ns/op
BenchmarkHandleKeysIntegration-8                        1000000000               0.09876 ns/op
BenchmarkValidateFirstKeySharesIntegration-8            1000000000               0.2187 ns/op
BenchmarkHandleFirstKeySharesIntegration-8              1000000000               0.1358 ns/op
BenchmarkValidateSecondKeySharesIntegration-8           1000000000               0.2173 ns/op
BenchmarkHandleSecondKeySharesIntegration-8             1000000000               0.6793 ns/op
PASS
ok      github.com/shutter-network/rolling-shutter/rolling-shutter/keyper/epochkghandler        125.678s

@jannikluhn
Copy link
Contributor Author

Yes, for a few hunderd identity preimages or less. If I increase the number to 500 - 1000 it goes way up. Note that you also have to increase MaxNumKeysPerMessage if you try that.

@konradkonrad
Copy link
Contributor

If I increase the number to 500 - 1000 it goes way up.

that doesn't sound linear.

@konradkonrad
Copy link
Contributor

okay, there is definitely something odd going on.
I configured MaxNumKeysPerMessage = 512 and numIdentityPreimages = 500.
Then I did variations on -benchtime=Nx (see https://pkg.go.dev/cmd/go#hdr-Testing_flags).
The ns/op goes down dramatically with higher N. Also the overall run time was very similar in all tests I ran (about 42s).

go test -bench=. ./keyper/epochkghandler -cpuprofile keyhandler512.profile.out -run=^# -benchtime=10000x
goos: linux
goarch: amd64
pkg: github.com/shutter-network/rolling-shutter/rolling-shutter/keyper/epochkghandler
cpu: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz
BenchmarkValidateKeysIntegration-8                         10000            297247 ns/op
BenchmarkHandleKeysIntegration-8                           10000             42700 ns/op
BenchmarkValidateFirstKeySharesIntegration-8               10000            108306 ns/op
BenchmarkHandleFirstKeySharesIntegration-8                 10000             31613 ns/op
BenchmarkValidateSecondKeySharesIntegration-8              10000            108203 ns/op
BenchmarkHandleSecondKeySharesIntegration-8                10000            322352 ns/op
PASS
ok      github.com/shutter-network/rolling-shutter/rolling-shutter/keyper/epochkghandler        42.261s
go test -bench=. ./keyper/epochkghandler -cpuprofile keyhandler512.profile.out -run=^# -benchtime=10x   
goos: linux
goarch: amd64
pkg: github.com/shutter-network/rolling-shutter/rolling-shutter/keyper/epochkghandler
cpu: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz
BenchmarkValidateKeysIntegration-8                            10         305131048 ns/op
BenchmarkHandleKeysIntegration-8                              10          29710135 ns/op
BenchmarkValidateFirstKeySharesIntegration-8                  10         111074644 ns/op
BenchmarkHandleFirstKeySharesIntegration-8                    10          38698010 ns/op
BenchmarkValidateSecondKeySharesIntegration-8                 10         110245458 ns/op
BenchmarkHandleSecondKeySharesIntegration-8                   10         334928515 ns/op
PASS
ok      github.com/shutter-network/rolling-shutter/rolling-shutter/keyper/epochkghandler        43.328s

@konradkonrad
Copy link
Contributor

okay, there is definitely something odd going on.

it turns out, the benchmark wasn't looping. that is fixed now.

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.

2 participants