Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I feel the need to point out that regardless of how you're "pre-warming" the cache, you're missing the primary benefit of page caching.

By default, Rails' page caching persists to disk. An immense advantage of this solution is that you can use your web server to serve these pages directly, without ever hitting the Rails stack.

You're saving the page generation time, but you're still hitting the Rails stack + Redis for every single page request, both of which are entirely unnecessary.



Page caching is only useful if your page looks the same for everybody, e.g. it has no 'Welcome $LOGGED_IN_USER' bar. Which already rules out 99% of all web apps.


Not necessarily. A possible solution for that is to render the same thing for everyone and then bring in the user specific stuff after page load via ajax. Fairly common practice.


Not sure if it exists in other platforms but with Django, some people have experimented with two-phased template rendering as described here:

http://www.holovaty.com/writing/django-two-phased-rendering/

and there's a permissive license (BSD, I think) implementation:

http://codysoyland.com/projects/django-phased/documentation/...


The last big web app I worked on cached the page components. For example, the "Latest images" section is cached, but the "Logged in user (11 new mails)" section isn't. (Or as another poster suggests, use AJAX for that stuff).

You can still get away with caching large parts of your pages though.


In Rails that's called "Fragment Caching", which is different from "Page Caching".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: