You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Putlatency normalised by number of multihashes (similar to the existing latency measure in Get ) -- so that we know how much time was spent exclusively on core layer to put indices.
Average Put batch size of multihashes -- so that we can reason about optimisation of batching multihashes across multiple ads.
Average size of keys and values -- so that we can reason about key-value store optimisation parameters.
Average metadata size
Removal rate by context ID and by provider -- so that we can estimate garbage size.
The text was updated successfully, but these errors were encountered:
Normalized Put latency is handled by recording the number of multihashes and elapsed time as an ingestion rate record. These records are collected by the telemetry service.
Average Put batch size: I do not think we want to batch multihashes across multiple ads ever. Once we have the ad and all its entries, it is best to make sure that is committed before moving on to the next ad. If there is any interruption in indexer operation we want to only have to reindex the last complete ad. Especially when writing a CAR mirror.
Is average size of keys and values also over last N samples? Do we also want to keep a ratio of keys to values?
We currently track the overall percentage of removal ads. Tracking per provider would show which providers had the highest churn. It might makes sense for GC to track this because then we could track the number of multihashes removed, not just context IDs.
Add metrics to report:
The text was updated successfully, but these errors were encountered: