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

Make analytics calls faster #45

Closed
smithjw1 opened this issue Aug 9, 2023 · 0 comments · Fixed by #48
Closed

Make analytics calls faster #45

smithjw1 opened this issue Aug 9, 2023 · 0 comments · Fixed by #48
Assignees

Comments

@smithjw1
Copy link
Contributor

smithjw1 commented Aug 9, 2023

Currently, the longest part of the Block Data API response is the analytics call to MC Stats. We are tracking every single request.

The goal of the analytics is to understand two things:

  1. Who is using the Block Data API?
  2. How is their usage changing over time?

We don't need to slow down every request to be able to answer these questions. We can use some naive sampling that will give us the data we need. Naive sampling will be fast because it doesn't have to be perfectly accurate, just directionally helpful.

I would suggest sending the pixel at a regular time interval. For example, we could only send the pixel when the minute is equal to 10.

That sort of naive sampling is useful because the use case for the read methods of the Block Data API is fairly consistent use. People will be making requests throughout the day, and we will catch those.

We would miss "burst" usage because of some job, but we could mitigate that by checking more frequently, like when the second equals 10. That may miss very spotty consistent usage.

Combining the two may be best. With the data we have, we should be able to determine intervals that make our code execute quickly, but still provide the directional data we need to access the use of the feature over time.

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

Successfully merging a pull request may close this issue.

2 participants