Skip to content
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 additional metrics to core engine #83

Open
masih opened this issue Sep 12, 2022 · 2 comments
Open

Add additional metrics to core engine #83

masih opened this issue Sep 12, 2022 · 2 comments
Assignees

Comments

@masih
Copy link
Member

masih commented Sep 12, 2022

Add metrics to report:

  • Put latency 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.
@masih
Copy link
Member Author

masih commented Sep 12, 2022

@gammazero please edit the issue description as you see fit. Also please feel free to reduce the scope of metrics if you think some of them are YAGNI.

@gammazero
Copy link
Collaborator

gammazero commented Sep 30, 2022

Notes/questions on proposed metrics:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants