Performance : authenticated users needs caching mechanism for non-dynamic parts of the page
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | duplicate |
| Issue tags: | Performance |
Jump to:
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.
#1
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.
#2
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)
#3
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.
#4
Related issue that I didn't see until now http://drupal.org/node/152901
#5
Subscribing.
#6
#7
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.
#8
I might add that the user-specific parts could benefit from their own cache as well
#9
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.
#11
Moshe started working on this at http://drupal.org/node/495968 , marking as duplicate.