Views currently uses the general-purpose cache table: $data = cache_get("views_with_inline_args:$locale", 'cache');
. It would be much better for performance if it had its own cache table. It would mean making a new cache table in views.install:
db_query("CREATE TABLE {cache_views} (
cid varchar(255) NOT NULL default '',
data longblob,
expire int NOT NULL default '0',
created int NOT NULL default '0',
headers text,
PRIMARY KEY (cid),
INDEX expire (expire)
) /*!40100 DEFAULT CHARACTER SET UTF8 */ ");
and updating all cache_* functions: $data = cache_get("views_with_inline_args:$locale", 'cache');
.
The reason it would perform better is because of the table locking that goes on when the cache is written to. Basically, any time you use cache_set, the table gets locked. This means that anonymous users can't get their page cache hits served in that time, under the current scheme.
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedI totally agree. Do you have time to generate a patch to do this?
Comment #2
robertDouglass CreditAttribution: robertDouglass commentedPossibly. We can have a race =)
Comment #3
yched CreditAttribution: yched commentedI'm working on a patch to move cached queries out of {view_view} and into a cache table (see http://drupal.org/node/111975)
Should I integrate both patches and do that in cache_views straight ahead, or do you prefer keeping this separate ?
Comment #4
merlinofchaos CreditAttribution: merlinofchaos commented+1 on integrating them.
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedWell, wait.
Moving the cache would be valuable in both Drupal 5 and 4.7; but the dedicated cache table works only in 5...hm.
Now I'm not so sure.
Comment #6
yched CreditAttribution: yched commentedThat's right.
Well, moving cache to cache_views should be rather straightforward, so perhaps we'd better move separately on this, actually.
Comment #7
merlinofchaos CreditAttribution: merlinofchaos commentedDone.
Comment #8
(not verified) CreditAttribution: commented