base::BindOnce(&RecordLocalStorageOnDiskSizeKB,Do we want the `RecordLocalStorageOnDiskSizeKB` to record even when `open_status` is not OK? The histogram "LocalStorage.DatabaseOnDiskSizeKB" summary says it is recorded when the database is opened. which sounds like a successful open.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Do we want the `RecordLocalStorageOnDiskSizeKB` to record even when `open_status` is not OK? The histogram "LocalStorage.DatabaseOnDiskSizeKB" summary says it is recorded when the database is opened. which sounds like a successful open.
Good question! In this histogram's previous emission location in dom_storage_context_wrapper.cc, we didn't have visibility into whether the DB opened successfully or not. To not bias data going forward, I decided to always fire this telemetry. I think it's worth adjusting the verbiage in the histograms.xml to reflect this. So I've updated it. Thanks!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Adding leimy@ for OWNERS review of storage/histograms.xml.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
base::saturated_cast<int>(base::ComputeDirectorySize(db_path) / 1024);Not a problem from your change, but maybe we need a better way to measure SQLite diskspace usage. This computation omits the WAL file, which for DOMStorage might be significant since we're currently using the default checkpointing strategy.
base::saturated_cast<int>(base::ComputeDirectorySize(db_path) / 1024);nit: Can we use the ByteSize helper here?
db_runner->PostTask(FROM_HERE,Since this calculation does not depend on any database state, should we post to a random background sequence like the deleted code? That way, the operation won't block any DOMStorage database operations.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
base::saturated_cast<int>(base::ComputeDirectorySize(db_path) / 1024);nit: Can we use the ByteSize helper here?
Done
base::saturated_cast<int>(base::ComputeDirectorySize(db_path) / 1024);Not a problem from your change, but maybe we need a better way to measure SQLite diskspace usage. This computation omits the WAL file, which for DOMStorage might be significant since we're currently using the default checkpointing strategy.
Done! ComputeDirectorySize would return 0 when not passed a directory path. So we just sum together the sqlite + sqlite-wal files for that backend.
Since this calculation does not depend on any database state, should we post to a random background sequence like the deleted code? That way, the operation won't block any DOMStorage database operations.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
base::StrCat({"LocalStorage.DatabaseOnDiskSizeKB",Should we also record disk space usage for Session Storage, maybe in a future change?
base::ByteSize(base::checked_cast<uint64_t>(size_bytes)));Do we need to convert bytes to kilobytes maybe using base::ByteSize?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
Should we also record disk space usage for Session Storage, maybe in a future change?
Added a TODO
base::ByteSize(base::checked_cast<uint64_t>(size_bytes)));Do we need to convert bytes to kilobytes maybe using base::ByteSize?
UmaHistogramMemoryKB already takes care of calling the ByteSize
helper `InKiB()` for us.
https://source.chromium.org/chromium/chromium/src/+/main:base/metrics/histogram_functions.cc;drc=f929a0c3e751200212538123bfb58c0b491c3f62;l=326
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Thanks for the review Steve!
@le...@chromium.org this is now ready for your OWNERS review of storage/histograms.xml. I updated the Experimental version of the histogram to use the OnDiskExperimental suffix like you'd suggested on the other CL!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
<histogram name="LocalStorage.DatabaseOnDiskSizeKB{Suffix}" units="KB"I feel that it might be better to give the token a more meaning name, like SqliteRolloutExperimentStatus instead of a general "Suffix".
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
<histogram name="LocalStorage.DatabaseOnDiskSizeKB{Suffix}" units="KB"I feel that it might be better to give the token a more meaning name, like SqliteRolloutExperimentStatus instead of a general "Suffix".
Good idea. Updated it to DomStorageSqliteRolloutStage. Thanks!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
13 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: tools/metrics/histograms/metadata/storage/histograms.xml
Insertions: 4, Deletions: 3.
The diff is too large to show. Please review the diff.
```
DomStorage: Move LocalStorage.DatabaseOnDiskSizeKB into storage service
Moves emission of LocalStorage.DatabaseOnDiskSizeKB from
DomStorageContextWrapper into DomStorageDatabaseFactory's Open-time
histograms helper. It now picks the right backend path (LevelDB or
SQLite) and the right DatabaseMetricsType suffix during the SQLite
on-disk rollout. The unsuffixed name keeps firing for non-experimental
on-disk databases for backwards compatibility. A ".Experimental" variant
is added for the rollout cohort.
With DomStorageContextWrapper no longer needing to resolve a database
path, DomStorageDatabase::GetPath() has no remaining production callers.
So, this deletes it and migrates the remaining test callers to
GetLevelDbPath/GetSqlitePath.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |