You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We now have tarballs behind the CDN, but not html pages. This is pretty good, but we have the issue where the download counts are now wildly inaccurate again, because the CDN is in the middle. We can either import cdn stats, or we can configure the cdn to just give a little ping on each download -- e.g. for an ecache tag?
The text was updated successfully, but these errors were encountered:
The etag idea sounds interesting; etag pinging tarballs ought to be super-cheap in hackage-server anyway, as I'd expect it to be an O(1) lookup. The downside might be that we'd force the CDN to check the etag for something that's (almost) guaranteed to never change (at least for the primary index; obviously not for candidates), possibly adding latency to the CDN. Can the CDN configured to check the etag after it already served a previously cached copy?
(another thing to consider is that we have also fallback mirrors in place; but those would ideally only be consulted if the primary endpoint fails; so missing those counts should be neglectable -- unless we start implementing more agressive fallback and/or load-balancing over multiple mirrors rather than relying on the CDN layer)
We now have tarballs behind the CDN, but not html pages. This is pretty good, but we have the issue where the download counts are now wildly inaccurate again, because the CDN is in the middle. We can either import cdn stats, or we can configure the cdn to just give a little ping on each download -- e.g. for an ecache tag?
The text was updated successfully, but these errors were encountered: