-
Notifications
You must be signed in to change notification settings - Fork 30
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
[F] Track CTA downloads in analytics #3797
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small performance change, but otherwise looks fine on the API side!
@@ -99,6 +101,10 @@ def total_user_count | |||
User.count | |||
end | |||
|
|||
def total_download_count | |||
Analytics::Event.where(name: DOWNLOAD_EVENT_NAMES).count |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to put a small cache on this to prevent a count scan from being executed on a potentially large table on each request. You'd just wrap the interior of the method body like this:
def total_download_count
Rails.cache.fetch("statistics/total_download_count", expires_in: 5.minutes) do
Analytics::Event.where(name: DOWNLOAD_EVENT_NAMES).count
end
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. The whole request is also cached for longer:
def show
expires_in 3.hours, public: true
render_single_resource Statistics.new,
serializer: ::V1::StatisticsSerializer,
location: "[:api, :v1, :statistics]"
end
Should we adjust the 3 hour timeline at all? It seems reasonable for most cases, but if anyone is testing this on Edge, it's a long wait.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ope, was not aware of that. I would reduce it to 10 minutes. That only sets cache headers, which is easily bypassed by direct API access, but three hours seems excessive to me. We don't want these counts to run on every request, but a bunch every 10 minutes should be fine.
Given that in the request, I'd go ahead and ignore the rails.cache.fetch I advised above, since I wasn't looking at the whole class in context, really, and we'll improve the caching on this in another pass sometime in the future. Bigger scope than this, though.
No description provided.