Fix sample rate calculator estimated traffic logic#6506
Conversation
70b997a to
b26fdb5
Compare
…e is longer than site stats range
965701f to
4416b67
Compare
… than 30 days of stats
|
There's one more buggy scenario that I noticed: when the end date is far in the future, we'll overestimate events to scan and use an inappropriate sample rate. A query from the year 2026 to the year 2100 would estimate events to scan to be ~75 years worth of last 30 month average event count, while the actual events to scan would be half a year's worth, up to now. Can't have events in the future. |
apata
changed the title
|
|
||
| # A site's traffic before their stats begin date isn't queried, | ||
| # so it shouldn't figure in the traffic estimation | ||
| start_of_range_with_stats = |
There was a problem hiding this comment.
We have an existing function that clamps the query's datetime range based on the actual start date of native data here. Could it be used here to keep unified logic and code path?
| |> max(1) | ||
| end | ||
|
|
||
| defp days_of_traffic_in_window(%Query{}), do: @sampling_window_days |
There was a problem hiding this comment.
Under what circumstances is this clause expected to match? AFAIK native_stats_start_at is always filled by default and has a non-null constraint on it
3 participants
Changes
This PR fixes how we estimate traffic to calculate the sample rate for the query.
There were two issues. The first was noticed by a user, the second by me when I was fixing the first.
1) Overestimating events to scan for longer queries
We were overestimating the events the query would scan when the query start date was significantly before site stats start date, e.g. date range is 1970 to 2026, but stats actually start on 2025.
Previously, the calculator when run for this query would have estimated traffic to be 56 years worth of last month's average daily traffic.
Now, the calculator takes into account that stats start from 2025, so for this query, the estimated traffic is 1 years worth of last month's average daily traffic.
2) Underestimating events to scan for newer sites with high ingestion rate
We were underestimating the events the query would scan when the site's ingest counters have accumulated over less than 30 days.
Previously, a query for a new site ingesting 10M events per day for 3 days would not have been sampled, but a query for an older site ingesting 10M events per day for the last 30 days would have been. Expected is that both are sampled with the same rate.
Tests
Changelog
Documentation
Dark mode