Optimize diagnostics file management#1194
Conversation
| ) { | ||
| companion object { | ||
| const val DIAGNOSTICS_FILE_PATH = "RevenueCat/diagnostics/diagnostic_entries.jsonl" | ||
| const val DIAGNOSTICS_FILE_LIMIT_IN_KB = 500 |
There was a problem hiding this comment.
This is TBD, this is a pretty big file already, but not sure how big these files might get... From my estimations, this might be ~1k events.
| name = DiagnosticsEventName.MAX_EVENTS_STORED_LIMIT_REACHED, | ||
| properties = mapOf( | ||
| "total_number_events_stored" to totalEventsStored, | ||
| "events_removed" to eventsRemoved, |
There was a problem hiding this comment.
I thought these properties don't make sense anymore. We could send the file size, but in general, these files shouldn't get much bigger than the limit (currently of 500kb) so I thought it wouldn't be that useful.
| @@ -0,0 +1,6 @@ | |||
| package com.revenuecat.purchases.utils | |||
|
|
|||
| interface DataListener<T> { | |||
There was a problem hiding this comment.
Since I'm using this in the FileHelper, it should have a pretty generic name... Still not completely in love with it... Lmk if you have any other thoughts.
| var currentEventsToSync = 0 | ||
| diagnosticsFileHelper.readDiagnosticsFile(object : DataListener<JSONObject> { | ||
| override fun onData(data: JSONObject) { | ||
| eventsToSync.add(data) |
There was a problem hiding this comment.
Note how we currently still read the whole file and keep it in memory. I'm thinking about splitting things in a future PR, so we post diagnostics in batches. That's slightly tricky since we don't have much control over the listener (we can't stop it midway, nor ask for new events on demand).
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1194 +/- ##
==========================================
- Coverage 85.92% 85.88% -0.04%
==========================================
Files 181 183 +2
Lines 6217 6229 +12
Branches 900 905 +5
==========================================
+ Hits 5342 5350 +8
- Misses 533 534 +1
- Partials 342 345 +3 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
This is something that I don't fully like... But I didn't want to leak the responsibility of closing the readers.
There was a problem hiding this comment.
Adding a limit to the events in memory/per request was done previously in a separate PR, but I decided to move it to this PR for simplicity
There was a problem hiding this comment.
What do you think about a more "functional" test that adds say 500 events and verifies that it's not considered too big?
As a way to validate that the size limit allows for some number of events that we're happy with.
There was a problem hiding this comment.
Do we need to put this in the docs too?
There was a problem hiding this comment.
We haven't added diagnostics to the docs yet since we were planning to add extra functionality before that, so nothing to update
265d1f6 to
2914d17
Compare
2914d17 to
7202adb
Compare
**This is an automatic release.** ### Performance Improvements * Optimize SDK initialization when requests executed before any activity starts (#1204) via Toni Rico (@tonidero) * Optimize diagnostics file management (#1194) via Toni Rico (@tonidero) ### Other Changes * Use real debug view dependencies in magic weather compose (#1203) via Toni Rico (@tonidero) --------- Co-authored-by: revenuecat-ops <ops@revenuecat.com> Co-authored-by: Toni Rico <antonio.rico.diez@revenuecat.com> Co-authored-by: Toni Rico <toni.rico.diez@revenuecat.com>
Description
This PR is the first part of a possible approach to avoid loading huge files in memory in diagnostics at once. Basically, in here we change to reading the file per lines instead of reading everything in one go.
Behavior changes
MAX_EVENTS_STORED_LIMIT_REACHEDevent since they don't make sense with the new approach. (This will require backend changes)