-
Notifications
You must be signed in to change notification settings - Fork 258
chore: improve dal integration test performance #8332
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
Conversation
|
/try |
Dependency Review✅ No vulnerabilities or OpenSSF Scorecard issues found.Scanned FilesNone |
|
Okay, starting a try! I'll update this comment once it's running... |
51b7fa1 to
791eedf
Compare
|
/try |
|
Okay, starting a try! I'll update this comment once it's running... |
|
/try |
|
Okay, starting a try! I'll update this comment once it's running... |
7b1d46b to
58cda4a
Compare
|
/try |
|
Okay, starting a try! I'll update this comment once it's running... |
Adds arguments to the dal test macro that enable and disable specific "servers" per test. By default, only the rebaser and pinga will be started, and you can enable the rest with: enable_veritech enable_edda enable_forklift Note that I have not enabled edda for any test, and all tests pass, so it looks like we don't have any real integration testing for edda at the moment. The one you'll want the most is enable_veritech, which you should be sure to enable any time you will have to execute functions. This took about 10-30 seconds off my test runs.
In read_wait_for_memory we spin checking if the requested object has landed in the memory cache (via the events stream) and then we look at disk and durable storage. This adds a 2+ second overhead for many fetches, which either are not about to land in the memory cache because they are for old objects which have been evicted, or because we just don't propagate data fast enough across NATS for it to land. Checking the normal read path before trying to spin has a huge performance result for the integration tests, easily 100 seconds faster in CI, and will likely have a positive impact throughout the stack.
58cda4a to
fd02731
Compare
|
/try |
|
Okay, starting a try! I'll update this comment once it's running... |
| use pretty_assertions_sorted::assert_eq; | ||
|
|
||
| #[test] | ||
| #[test(enable_veritech)] |
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.
Okay I've wanted this idea for like ~3-4 years and I am SO happy to finally see it! Yes yes yes!
| // Conditionally start servers based on macro arguments | ||
| if args.should_start_server("forklift") { | ||
| expander.setup_start_forklift_server(); | ||
| } | ||
| if args.should_start_server("veritech") { | ||
| expander.setup_start_veritech_server(); | ||
| } | ||
| if args.should_start_server("pinga") { | ||
| expander.setup_start_pinga_server(); | ||
| } | ||
| if args.should_start_server("edda") { | ||
| expander.setup_start_edda_server(); | ||
| } | ||
| if args.should_start_server("rebaser") { | ||
| expander.setup_start_rebaser_server(); | ||
| } |
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.
Ended up being simple! Nice.
| const DEFAULT_SERVERS: &[&str] = &["rebaser", "pinga"]; | ||
|
|
||
| impl Args { | ||
| /// Check if a specific server should be disabled | ||
| pub(crate) fn should_skip_server(&self, server_name: &str) -> bool { | ||
| let skip_ident = format!("skip_{server_name}"); | ||
| self.vars.iter().any(|v| v == &skip_ident) | ||
| } | ||
|
|
||
| pub(crate) fn should_enable_server(&self, server_name: &str) -> bool { | ||
| let skip_ident = format!("enable_{server_name}"); | ||
| self.vars.iter().any(|v| v == &skip_ident) | ||
| } | ||
|
|
||
| /// Check if a specific server should be started | ||
| pub(crate) fn should_start_server(&self, server_name: &str) -> bool { | ||
| if DEFAULT_SERVERS.contains(&server_name) { | ||
| !self.should_skip_server(server_name) | ||
| } else { | ||
| self.should_enable_server(server_name) | ||
| } | ||
| } | ||
| } |
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.
Ah this is it. I never took the time to get deep into the idea, but I'm glad it was relatively small in the end.
Two changes here:
Adds arguments to the dal test macro that enable and disable specific
"servers" per test. By default, only the rebaser and pinga will be
started, and you can enable the rest with:
enable_veritech
enable_edda
enable_forklift
Note that I have not enabled edda for any test, and all tests pass, so
it looks like we don't have any real integration testing for edda at the
moment.
The one you'll want the most is enable_veritech, which you should be
sure to enable any time you will have to execute functions.
This took about 10-30 seconds off my test runs.
And
In read_wait_for_memory we spin checking if the requested object has
landed in the memory cache (via the events stream) and then we look at
disk and durable storage. This adds a 2+ second overhead for many
fetches, which either are not about to land in the memory cache because
they are for old objects which have been evicted, or because we just
don't propagate data fast enough across NATS for it to land.
Checking the normal read path before trying to spin has a huge
performance result for the integration tests, easily 100 seconds faster
in CI, and will likely have a positive impact throughout the stack.