-
Notifications
You must be signed in to change notification settings - Fork 110
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
test: add benchmark for long-running sessions clean up task. #2564
test: add benchmark for long-running sessions clean up task. #2564
Conversation
google-cloud-spanner/src/test/java/com/google/cloud/spanner/LongRunningSessionsBenchmark.java
Outdated
Show resolved
Hide resolved
google-cloud-spanner/src/test/java/com/google/cloud/spanner/LongRunningSessionsBenchmark.java
Outdated
Show resolved
Hide resolved
client.singleUse().executeQuery(StandardBenchmarkMockServer.SELECT1)) { | ||
while (rs.next()) { | ||
// introduce random sleep times to have long-running sessions | ||
randomWait(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pure theoretically this random function could end up never adding a long wait time if random.nextBool
returns false every time. Would it maybe make sense to let this method update an atomic integer every time it sets a long wait time, and then at the end of the test verify that the number of sessions that was removed is equal to that atomic integer (instead of just checking that it's greater than zero, which could in theory fail)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a very good idea. Let me do this. It will make the benchmark even more precise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this logic and then realised that the number of sessions removed may not be equal to the value of the atomic integer since
- The background task may not have run and thus there may be a few dangling sessions which would be pending to be cleaned up.
- Even if we force run a maintenance task, there may still be other reasons why the session may not get cleaned. For ex - If session hasn't breached the idle threshold.
#1 is easy to mitigate by force running a maintenance loop at the end of the test. But for #2 we will require to setup our fake clock setup and play around with the timestamps. Since we already do this for all other tests that were part of the other PR, I was thinking we can keep this benchmark close to real setup and avoid all the mocking.
What do you think?
…ngRunningSessionsBenchmark.java Co-authored-by: Knut Olav Løite <[email protected]>
fa745e8
into
googleapis:main
Adding benchmarks for long running sessions cleanup feature introduced as part of - #2419 .