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:
Who is using the Block Data API?
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.
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:
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
minuteis 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
secondequals 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.