4 ms·
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
by briandoll 15y ago
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.
- FooBarWidget 15y agoPage 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.
- alinajaf 15y agoNot 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.
- davedx 15y agoThe 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.
- bhousel 15y agoIn Rails that's called "Fragment Caching", which is different from "Page Caching".
- huxley 15y agoNot 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/ 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/tutorial.html http://codysoyland.com/projects/django-phased/documentation/...