Improving Caching Headers & Hit Counters
fabiocicerchia opened this issue · comments
I think would be better to have some cache headers for each request allowing the proxy to efficiently cache the requests.
For example, the badge for the stable version can be cached longer than the number of downloads, let's say for 6h? As for the number of downloads once the approximation reaches the order of millions maybe could be 24h? Whereas at smaller numbers could be hourly.
This would enable to reduce the requests at the backend and increase the stability of the system.
In regards to the hit counters I guess we could change the system in place and move it away from the PHP code and trigger the counters in another way, it could be via some processing of logs in AWS, it could be by triggering events from nginx to store into redis (eg. nginx&lua). Just brainstorming a couple of ideas.
I think would be better to have some cache headers for each request allowing the proxy to efficiently cache the requests.
For example, the badge for the stable version can be cached longer than the number of downloads, let's say for 6h? As for the number of downloads once the approximation reaches the order of millions maybe could be 24h? Whereas at smaller numbers could be hourly.This would enable to reduce the requests at the backend and increase the stability of the system.
It's a very good idea for me! ;)
In regards to the hit counters I guess we could change the system in place and move it away from the PHP code and trigger the counters in another way, it could be via some processing of logs in AWS, it could be by triggering events from nginx to store into redis (eg. nginx&lua). Just brainstorming a couple of ideas.
If move the hit on nginx how could we verify that the requested package really exists?
Currently if I'm not mistaken we are tracking many kinds of statistics on redis. Could it help to do some cleaning and only track things we show?
let's say for 6h? As for t
maybe we can reuse the cache-header from packagist, or maybe etag can work with image?
ops there's already a PR sorry.
It could be considered as a work in progress PR, open to anyone ;)
@fabiocicerchia we can close this?