Active context: blog_bios

Caching Drupal for Authenticated Users

by William O'Connor // August 25, 2009 // 5 comments

Drupal Caching 

This past week, I was chatting with my friend - and ex-boss - Chris Fuller (cfuller12) from Optaros about caching pages for authenticated users.  He'd been implementing authcache to cache pages for his latest deployment but was going to need to do some tweaking to get dynamic aspects of the page working for logged in users.  I've been busy writing proposals and keeping the Achieve-machine moving forward so the development challenge was a great reason to do something else for a little while.

Chris and I chatted for a little bit, I reviewed authcache's implementation for callbacks, and I spent a little time thinking about how Drupal handles caching natively.  We've done a fair bit of work on large sites here at Achieve - and Steve Rude (slantview) and I have worked together a fair bit - so I've been privileged to work, at least peripherally, on a significant amount of performance-related issues.  As a result, I wanted to see if I could develop a solution that leveraged a little bit more of Drupal's built-in caching and required a little less extra development work to get things working.  Thus was born ajaxify_regions.

Wow, I think I heard a groan.  Yes, fine, it's not a great name - as I've already been told by the aforementioned Steve Rude, so if you have a better name, let me know - but it'll do for today.  There are plenty of things that could be done to continue to improve performance on this lightweight caching system, but the beauty of ajaxify_regions is that it leverages things everyone already does to make utilizing a page-level caching system seamless.

Brian Kennedy (brianpkennedy) from Optaros made some modifications, put on some finishing touches, and we swept a 1.0 release out the door.

So far, I've only tested the system with authcache, but simply enabling the module should turn any block that has been defined as unable to be cached, is cached per user, or is cached per role to be retrieved via a single ajax callback.  So, if you have 3 blocks that shouldn't be cached for authenticated users, the blocks are replaced by js, the page is cached with the js, and, at runtime, the blocks are retrieved via an ajax callback this is simple and seamless.  Now the pages can be cached without issue, and we simply retrieve the blocks that are unique for that user.  

I'm sure the solution can be trimmed down, and I'm sure it's not the end-all be-all, but for a few hours work, we've got a solution I'm pretty happy with. If you get a chance, download the module, test it out and send me feedback.  I'd love the project to evolve and make authenticated page-caching something that we do on every project large or small, and I hope this is a step in that direction.

-- Bill (csevb10)

 

Comments

Gave you a bunch of issues

mikeytown
127 weeks ago
Grabbed some of the relevant issues that where on boost, and gave them to you, since your asking for input. It's a good way to document what this module can and can't do right now. Send them back if you can't implement it.

Thanks

Onopoc
127 weeks ago
Thanks for contributing this great module. There's plenty of room to improve caching for authenticated users. I'll try some time then post feedback.

Interesting approach

Robert Douglass
127 weeks ago
I wonder if it will really add to the overall performance very much. I hope so. You still incur the full bootstrap on the ajax request. I suppose, depending on how you've coded it, you avoid building several blocks and most of the theme rendering layer. How do you deal with dynamic $content content?

Is this really an improvement?

Barry Jaspan
127 weeks ago

It seems to me that this replaces one Drupal bootstrap (the original non-cached page) with potentially multiple Drupal bootstraps (one for each non-cached block). That only makes sense if the cost of generating the original page post-bootstrap WITHOUT the non-cached blocks is higher than multiple bootstraps. If the page a View or something similar with complex, expensive queries, that might be true, but it is also the case that often the complex and expensive queries are used to generate the blocks... so caching everything but the blocks means you are caching the "easy parts."

I suppose this strategy also makes sense if the site prefers a user experience in which the primary page content comes up as fast as possible, not caring if the blocks get filled in somewhat later (e.g. like images). That seems like it could be a valid choice. You will have to choose between using CSS to pre-size the block areas, resulting in fixed block sizes, or having the page flicker as the blocks fill in (a bigger problem if the blocks are in the header than in the sidebars or footer).

As another point, this process probably increases the overall load on the web stack, since in general bootstrap is in fact a substantial cost.

Actually...

William O'Connor
105 weeks ago
This replaces the original bootstrap (+ all of the associated queries) with another single bootstrap. ALL blocks are loaded in 1 request vs 1 request per block. This means the overall process should always be - at worst - equivalent to the original load, but, in most situations should be much faster. The primary idea is that you can statically cache the bulk of the page content and then only bootstrap & retrieve content for the blocks that cannot be cached.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options