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

chore(storage): add warmup option [benchmarks] #8418

Merged
merged 9 commits into from
Aug 29, 2023

Conversation

BrennaEpp
Copy link
Contributor

@BrennaEpp BrennaEpp commented Aug 15, 2023

Extra telemetry set up to test SSB - will revert those changes.

This runs w1r3 benchmarks (discarding output) to warm up.

It does write/read from disk to warmup - we can change that in the future but this should do for now

@BrennaEpp BrennaEpp requested review from a team as code owners August 15, 2023 02:45
@product-auto-label product-auto-label bot added size: m Pull request size is medium. api: storage Issues related to the Cloud Storage API. labels Aug 15, 2023
Copy link
Contributor

@tritone tritone left a comment

Choose a reason for hiding this comment

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

Thanks for adding this, just 1 question.

storage/internal/benchmarks/directory_benchmark.go Outdated Show resolved Hide resolved

for deadline := time.Now().Add(opts.warmup); time.Now().Before(deadline); {
warmupGroup.Go(func() error {
benchmark := &w1r3{opts: opts, bucketName: opts.bucket}
Copy link
Contributor

Choose a reason for hiding this comment

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

So, I guess this uses the same level of parallelism as was specified for the main workload? I am wondering if it makes more sense to have a fixed/higher level of parallelism, or to be able to specify this separately.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It does; I am open to changing it to a fixed parallelism level - say 16? I think being able to specify this separately may create unnecessary confusion - unless we determine it would be beneficial to have different levels of parallelism for warmups for different workloads, in which case we can always add this in.

The way it is now gives consistency in terms of bucket traffic: the bucket always sees the same level of parallelism; but ultimately for the long term a fixed parallelism makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah I think 16 (or numCPUs) is appropriate. We could make it configurable if/when we refactor all the CLI opts into some kind of config file eventually...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea - I changed it to num cpus

@BrennaEpp BrennaEpp enabled auto-merge (squash) August 29, 2023 20:10
@BrennaEpp BrennaEpp merged commit b9cd7c7 into googleapis:main Aug 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: storage Issues related to the Cloud Storage API. size: m Pull request size is medium.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants