-
Notifications
You must be signed in to change notification settings - Fork 128
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
Add option to defer ping lifetime metric persistence #530
Conversation
1f91292
to
15bd43b
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.
This looks reasonable to me from an high level look. Let's make sure @badboy also gives this a look.
glean-core/src/database/mod.rs
Outdated
@@ -443,6 +534,14 @@ impl Database { | |||
.write() | |||
.expect("Can't access app lifetime data as writable") | |||
.clear(); | |||
|
|||
let ping_lifetime_data = &self.ping_lifetime_data; |
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.
When we do for lifetime in [Lifetime::User, Lifetime::Ping].iter()
on line 522, if the deferred write is on, we don't need to also clear the RKV store. Maybe not a big deal, but could save us some I/O.
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.
This is going to require some refoactoring of this function and I don't know if it makes sense to do it, because if I do that it will be removed in my next PR.
} | ||
}; | ||
|
||
db.iter_store_from(Lifetime::Ping, test_storage, None, &mut snapshotter); |
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.
One thing you should probably do is manually check if data was written to rkv. You might want to do something like this.
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 code related to this (database/mod.rs 850-859), I am not sure it works 🤔
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.
What makes you think this is not working?
15bd43b
to
10c6059
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #530 +/- ##
============================================
- Coverage 75.61% 75.17% -0.44%
+ Complexity 334 333 -1
============================================
Files 98 98
Lines 5736 5820 +84
Branches 715 741 +26
============================================
+ Hits 4337 4375 +38
- Misses 879 905 +26
- Partials 520 540 +20 ☔ View full report in Codecov by Sentry. |
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.
One major note here: we need to reload data on startup.
(Haven't looked super-closely at the tests yet, I will do that in a follow-up-review)
b8038c2
to
b864069
Compare
e888a33
to
3bd01c7
Compare
@Dexterp37 @badboy this is ready for review. I still need to see what's going on with CI and the new cbindgen version, but that shouldn't get much in the way. For context: I just downloaded cbindgen in version 0.10.0 and that broke some things and changed the generated header files (because CI was using 0.9.10). I added a commit with the update + header file changes to this PR, but that is still breaking the build. iOS integration test is also failing in the CI, but that doesn't look like it is related to these chages. |
3bd01c7
to
77b6d8b
Compare
glean-core/android/src/main/java/mozilla/telemetry/glean/config/Configuration.kt
Outdated
Show resolved
Hide resolved
glean-core/android/src/main/java/mozilla/telemetry/glean/config/Configuration.kt
Outdated
Show resolved
Hide resolved
f371ae7
to
b6a6153
Compare
66261e4
to
24129ce
Compare
24129ce
to
1c4a1a1
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.
Got one question left, but that's for @Dexterp37.
When that is answered we can land it I think.
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.
This looks good to me with the nits below addressed.
} | ||
}; | ||
|
||
db.iter_store_from(Lifetime::Ping, test_storage, None, &mut snapshotter); |
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.
What makes you think this is not working?
1c4a1a1
to
759937d
Compare
db.iter_store_from(Lifetime::Ping, test_storage, None, &mut snapshotter); | ||
assert_eq!(1, found_metrics, "We only expect 1 Lifetime.Ping metric."); | ||
|
||
let store: SingleStore = unwrap_or!( |
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.
We discussed over Slack and agreed to slightly change this to make sure that something is being written to rkv at all :)
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.
Would the comment I added suffice here or do you mean for me to add the whole experiment I did to lower my confusion?
I personally don't think the experiment adds to the test and makes it a little confusing (since it is code that is not related), but I want to know your opinion :)
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.
No, that's fine :)
759937d
to
5ebc4bf
Compare
5ebc4bf
to
02dfd1d
Compare
db.iter_store_from(Lifetime::Ping, test_storage, None, &mut snapshotter); | ||
assert_eq!(1, found_metrics, "We only expect 1 Lifetime.Ping metric."); | ||
|
||
let store: SingleStore = unwrap_or!( |
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.
No, that's fine :)
Fixes Bug 1596440
Opening this as WIP so I can get validation that I am on the right way and also to discuss the name of the
defer_collection
configuration option -- keeping in mind that we might change this config option to a interval right after this gets PR accepted (see comment #9 and comment #10).I think the biggest part of this is done, that was adding the option and changing the way metrics are stored when the config option is set. I thought I had to change a little bit the
PingMaker
, but after looking at the code seems like my changes toDatabase
were all that was necessary.In my test I wasn't sure how to check that things were actually saved to the map and not rkv. I am not sure
assert!(db.ping_lifetime_data.is_some());
is enough...Finally, I hard-coded the value of
defer_collection
on the ffi, so I still need to change that.