search

bestia-dev / cargo_crev_web

web server to query reviews from cargo-crev
https://lucianobestia.github.io/cargo_crev_web
MIT License
8 stars 0 forks source link

cache badges #12

Closed bestia-dev closed 3 years ago

bestia-dev commented 4 years ago

If a project with the badge is shared around it can receive many requests. I could cache the last 100 badges and return them from cache. That is clever. Also invalidating the cache is straightforward. Every hour after the fetch and re-index I clear the cache and start again. Because the data may change. For badges I query only the index. Super fast in memory. But it doesn't solve the problem of (maybe expensive) traffic. With an expiration policy of 1 hour should be ok. Also the data change only in one hour.

bestia-dev commented 4 years ago

@dpc wrote: In particular the badges - couple of projects will add the badge to their github README, then get on top of HackerNews and if you don't server them from memory the service will die rather quickly.

I added Cache-control max-age=3600, public to allow badges to be cached for one hour. The web-site is fetching new reviews every hour, so the data will not change in one hour. For me now the one hour resolution looks appropriate for crev. This is good to avoid multiple requests from the same site. That can happen. Some bad while loop that makes hundreds of requests in a few minutes.

dpc commented 4 years ago

I totally agree that long caching is appropriate. You might also want to add ETag support. It's a bit more difficult, but gives even better results. Caching + Etags can eliminate a lot of needless traffic.