-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
Use SpecialEnv + smaller testing db to speed up some slow BackupEngineRateLimitingTestWithParam #9974
Conversation
d8851e6
to
ef47919
Compare
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.
My main question/concern is whether part of the code will use a special env over Default and other code will use env over something else. Going through doing something similar on other changes in the past, I found this can lead to weird errors.
} else { | ||
engine_options_->backup_rate_limit = backup_rate_limiter_limit; | ||
} | ||
|
||
engine_options_->max_background_operations = is_single_threaded ? 1 : 10; | ||
|
||
DestroyDB(dbname_, Options()); |
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.
Should this Options() refer to special_env?
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.
Fixed
std::unique_ptr<Env> special_env( | ||
new SpecialEnv(Env::Default(), /*time_elapse_only_sleep*/ true)); |
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.
The code below uses the chroot env. Should the special wrap this env or default?
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.
Fixed
Good point - I was trying to replace as minimum env as possible but didn't foresee how this inconsistency might lead us to problem (and probably readability issue as reader might be in doubt). Let me think about it more. Thanks! |
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.
where its clock accepts fake elapse of time during rate-limiting (6582 - 28560 ms/per test)
Is it still waiting for something? Or do these tests do tens of seconds of actual work?
ef47919
to
0f49d6c
Compare
0f49d6c
to
98af232
Compare
Oh I meant the time spent for each test, not during rate-limiting (updated my description). Most of the time went into backing-up/restoring the db in the test. For that, I shrunk the test db by 10x. |
@hx235 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
FillDB(db_.get(), 0, 100000); | ||
TEST_SetDefaultRateLimitersClock(backup_engine_.get(), | ||
special_env->GetSystemClock(), nullptr); | ||
FillDB(db_.get(), 0, 10000); |
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.
Was changing the last argument an intended change or accidental>
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.
intended - see updated PR summary for that.
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.
Updated PR title for it too.
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.
LGTM. Thanks!
Thanks for the improvement! |
Context:
BackupEngineRateLimitingTestWithParam.RateLimiting
andBackupEngineRateLimitingTestWithParam.RateLimitingVerifyBackup
involve creating backup and restoring of a big database with rate-limiting. Using the normal env with a normal clock requires real elapse of time (13702 - 19848 ms/per test). As suggested in #8722 (comment), this PR is to speed it up with SpecialEnv (time_elapse_only_sleep=true
) where its clock accepts fake elapse of time during rate-limiting and by using a smaller db. This results in -90% in time (100 - 600 ms/per test)Summary:
Test plan:
BackupEngineRateLimitingTestWithParam.RateLimiting
Pre:
Post:
BackupEngineRateLimitingTestWithParam.RateLimitingVerifyBackup
Pre:
Post: