Performance : authenticated users needs caching mechanism for non-dynamic parts of the page [#300935]

Just an idea - don't know if it's feasible or not at this stage. We all know that Drupal performance for anonymous users is stellar, but is way worse for logged in users (depending on the complexity of the page) due to caching being unavailable. Now in Drupal 6.x we have the option to cache blocks per user or per page, which is great, but still not ideal.

Would it be possible to do the reverse, to tell Drupal : generate these blocks for logged in users, and insert them in this cached page at these location. The logic is that most of the time, only a few blocks (and other regions such as one generated by fivestar.module for example) will be user specific on any given page. By getting the page from cache and inserting on the fly the few blocks of data that are user specific, we could probably get even better performance.

Another thing that could be beneficial if the above is not feasible is to have an option to cache blocks sitewide, instead of per page. This way they would be generated once for all page views (until cache is cleared) for logged-in users.

At this stage it's just an idea - I don't have the technical ability to work on this, but IMHO Drupal logged-in user performance is the part of that great CMS we all love that need most love right now.

Comments

Comment #1

kbahey CreditAttribution: kbahey commented 28 August 2008 at 06:02

There was an effort by Robert Douglass for this. It started with the advanced cache module, but it did not move beyond Drupal 5.x. Perhaps that can be a starting point.

Comment #2

FiReaNGeL CreditAttribution: FiReaNGeL commented 28 August 2008 at 16:03

Also some work done by Markus_petrux (http://groups.drupal.org/node/12951) and the discussion I opened in the High performance group (http://groups.drupal.org/node/14330)

Comment #3

catch

he/him

English

CreditAttribution: catch commented 6 September 2008 at 23:13

block_cache module in 5.x had a lot of options - whole site, per role, different expiry times (so you could cache "who's online" for 120 seconds and have it refresh if someone logs in or out). Would also be good to enable opt-in block caching when node access modules are enabled - at the moment it's shutdown by some hard coded logic somewhere.

Comment #4

FiReaNGeL CreditAttribution: FiReaNGeL commented 25 September 2008 at 00:03

Related issue that I didn't see until now http://drupal.org/node/152901

Comment #5

BioALIEN CreditAttribution: BioALIEN commented 27 September 2008 at 11:35

Subscribing.

Comment #6

FiReaNGeL CreditAttribution: FiReaNGeL commented 6 January 2009 at 21:43

Issue tags:

+Performance

Comment #7

FiReaNGeL CreditAttribution: FiReaNGeL commented 11 January 2009 at 19:18

As an example of what I mean - take d.o. front page and a standard node page for example. When logged-in, the whole page is recalculated and many db requests are issued.

How many items on the frontpage actually needs to be recalculated? Only the 'number of comments and number of new comments' parts for each node teaser, and maybe an optional block or two.

What about a standard node page? Only the 'new' tag for new comments (and maybe the same optional block or two mentioned above, but block cache take care of that).

If Drupal knew what parts it need to recalculate and rerender, we would save > 95% of db queries, and probably of page generation time, for logged-in users. Coupled with a high performance cache system such as memcache, Drupal could be blazingly fast for anonymous users (as it is now) AND for logged-in users.

Comment #8

FiReaNGeL CreditAttribution: FiReaNGeL commented 13 January 2009 at 19:54

I might add that the user-specific parts could benefit from their own cache as well

Comment #9

FiReaNGeL CreditAttribution: FiReaNGeL commented 27 May 2009 at 16:48

Title:	Better caching for logged in users	» Performance : authenticated users needs caching mechanism for non-dynamic parts of the page
Category:	feature	» bug
Priority:	Normal	» Critical

Someone at Everyblock.com implemented the mechanism I suggest in Django and report that it was crucial for their site performance. See it at http://www.holovaty.com/writing/django-two-phased-rendering/ . I'm pretty sure the same is possible in PHP and would allow Drupal to get beyond sites for anon users.