Caching

[andrewreid]

To make best use of a platform like Heroku for hosting, I think caching of the content pages needs to be fairly aggressive. I'm a bit of a caching n00b but it's an interesting area. Where's Schnitzelpress at as far as caching is concerned? I'd love to contribute to this particular area, once I have my head around it all and what the plans are.

[andrewreid]

I should have read more source before posting :-) Perhaps what I'm thinking of is as simple as playing with the options being passed to cache_control in blog.rb. Whilst a blog certainly isn't static, it's fair enough to say that the content itself isn't "dynamic". It can afford to be fairly aggressively cached. More than anything, I see the aim as reducing load on the app server (i.e., squeezing more and more requests from a Heroku dyno).

Could the cache_control parameters be moved into the config database document?

[hmans]

The thing with caching is that you'll want to give different max-ages for shared (Rack::Cache et al) and private (browser) caches, and ideally not cache content pages for too long since after all their content may change (in most cases by being edited through you).

The current setting in Schnitzelpress is to cache documents in your browser for 60 seconds (with revalidation), and for 2 seconds in shared caches. This setting has proven very successful so far as in documents expiring "soon enough" after being edited, while easily being able to deal with traffic coming from Hacker News and friends. For a content page, Schnitzelpress will currently give you around 1400req/s on a single, free Heroku dyno. This number could probably be increased even further by adding another reverse proxy cache (like Varnish), which Heroku unfortunately doesn't offer on the Cedar stack.

I hope this clears things up. I hope you don't mind if I'm closing this issue for now.

[andrewreid]

It does, thank you.