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

merlinofchaos’s picture

I totally agree. Do you have time to generate a patch to do this?

robertDouglass’s picture

Possibly. We can have a race =)

yched’s picture

I'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 ?

merlinofchaos’s picture

+1 on integrating them.

merlinofchaos’s picture

Well, 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.

yched’s picture

That's right.
Well, moving cache to cache_views should be rather straightforward, so perhaps we'd better move separately on this, actually.

merlinofchaos’s picture

Status: Active » Fixed

Done.

Anonymous’s picture

Status: Fixed » Closed (fixed)