perf(issues): add pseudo-cache to test_frequency_rates in GroupSnooze

[vartec]

Reducing unnecessary Snuba queries by only querying when Redis count reached.
Follows exactly same pattern as #69556

[JoshFerge]

TTL is further into the future than it needs to be

if we want the cacheing to be less aggressive shouldn't the ttl be less into the future?

[vartec]

It short-circuits to say that the threshold is not reached when the number is less than threshold, by extending the caching window further into the future we guarantee to be overcounting, rather then undercounting, while keeping the cache as long as possible.

OTOH, if we'd like to have short lived cache, that would work too. On expired cache it falls back to +inf sentinel value, and triggers Snuba query

[JoshFerge]

ah i see now 👍🏼

[sentry-io]

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ RateLimitExceeded: Query on could not be run due to allocation policies, details: {'ConcurrentRateLimitAllocationPol... sentry.tasks.post_process.post_process_group View Issue
• ‼️ SnubaError: HTTPConnectionPool(host='127.0.0.1', port=10006): Max retries exceeded with url: /events/snql (Ca... sentry.tasks.post_process.post_process_group View Issue
• ‼️ RateLimitExceeded: Query on could not be run due to allocation policies, details: {'ConcurrentRateLimitAllocationPol... sentry.tasks.post_process.post_process_group View Issue
• ‼️ SnubaError: HTTPConnectionPool(host='127.0.0.1', port=10006): Read timed out. (read timeout=30) sentry.tasks.post_process.post_process_group View Issue

_{Did you find this useful? React with a 👍 or 👎}