[development] cache flexibility improvement

Ivan Sergio Borgonovo mail at webthatworks.it
Tue Jan 12 15:09:09 UTC 2010


I saw a chance to improve the flexibility of D7 cache, with
something that looks as a very small change.

I'm sorry if I'm missing something, but I'd really appreciate if
someone will point out what's wrong with my proposal.

Substantially D7 doesn't serve cached pages if $_SESSION isn't empty
as stated in drupal_page_get_cache docs (I couldn't find anymore
where $_SESSION is tested...).

This limit the use of cache substantially.
Nearly all users will have a not empty $_SESSION that will force
regeneration of ALL the pages.

Currently core put in SESSION:
1) openid
2) user_overview_filter
3) dblog_overview_filter
4) node_overview_filter
5) clean_url
6) authorize_filetransfer_backends
7) authorize_operation
8) ignore_slave_server
9) update_manager_update_projects
10) authorize_results
11) update_results
12) messages
13) locale_translation_filter
14) maintenance_mode
15) update_success
16) updates_remaining
17) maintenance_mode
18) batch_form_state
19) my_batch_results
20) batches

Most of them shouldn't actually forbid the use of ALL cached pages.
One way to retro-fit a more fine grained control over cache would be
to add a field to all the SESSION items in the array

$_SESSION['session_var'] = $stuff;
$_SESSION['session_var']['cacheable'] = true;

And in spite of invalidating all cached pages we could check if
there is any ['cacheable'] that is null/unset preserving current
behaviour and giving a chance to exploit more the cache.

Then we could add the ['cacheable'] flag where it is safe a bit at a

in function _drupal_bootstrap_page_cache()
could be anticipated we could even give a chance to modules that
would like to control if the cache has to be used to fire.
eg. don't serve cached pages for user coming from this IP, don't
serve cached pages during these hours, always serve cached pages to
these IP etc...

Ivan Sergio Borgonovo

More information about the development mailing list