Posted by malc_b on November 21, 2009 at 6:12pm
3 followers
Jump to:
| Project: | Views |
| Version: | 6.x-2.7 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Views seems to have time based caching, does this work now? It has two options, cache the query and/or cache the html. What is the cost benefit trade off of these? Does this have any effect for anonymous users if drupal cache is on? We could do with some rules or guidelines to follow on this. And for AJAX for that matter. When should this be enable and when not?
Comments
#1
#2
This is independent from anonymous page caching and will have no effect on it. Anonymous page caching will do whatever it does if it is on and Views will never get called.
Caching the results means the query is not run but the results are still rendered. This is nice if you're doing some real-time data in rendering, but generally you just want to cache both the result and the output.
It's kind of hard to answer really general questions, though, because so much of the answers of "Should I use this or not" are specific to a particular setup.
#3
Thanks.
On the caching html or results, does it make a difference if the view is expected to multiple pages? Presumable the html cache is just last page viewed. So does it make more sense in this case just to cache the result, if the result is all pages. Or are they both a page worth's of data?
Also, I'll try to define some rules (basically the ones I'm following).
1. If the site is mainly anonymous users, or you don't care about logged in user waiting. For example logged in users only login to edit or there are very few user. Then turn on drupal's page cache and forget about views cache.
2. If you want to speed up logged in users when they access views then use views cache.
3. If you want to have dynamic views for anonymous users then use cache exclude http://drupal.org/project/cacheexclude to exclude the views page and then use views cache to control how dynamic the view is.
#4
Paging should be handled appropriately with caching (though search the issue queue, there's an issue about that right now that may be relevant).
Those three rules seem pretty good. You should also consider caching after looking at the timing information in the preview. Views that run quickly may not see any real value in being cached. Views that take more time to run the query or render the results are better candidates.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.