Hi! I think, nodes caching can dramatically improve Drupal perfomance. We can add new table, for example, "cache_node" where complete nodes markup (theme('node') results) would be stored. And node_load_multiple() should try to load data from this table first. So, cached nodes in the $page object should be stored in the #markup element:

[nodes] => Array
    (
        [1] => Array
            (
                 [#markup] => 'Rendered node...'
            )
    )

Maybe, ['nid'] and ['#weight'] elements should be added, if it's necessary.

Node cache sholud never expire. We can create cache after first node access (rendering). After editing & deleting node we should truncate cache entries for this node.

So, what do you think about this idea?

Comments

Frando’s picture

yched’s picture

Status: Active » Closed (duplicate)
Damien Tournoud’s picture

More precisely this one is won't fix: we can cache the full page for anonymous users, if we do it properly we can cache the full $node object (that's what #111127: Cache node_load is all about), but we really can't easily cache the output of theme('node'). It can be variable per user.

shp’s picture

Status: Closed (duplicate) » Needs review

Thanks for #111127: Cache node_load!

but we really can't easily cache the output of theme('node'). It can be variable per user.

Yes, it can be variable. Besides, it depends on the current page ($is_front, $teaser/$page ... variables).

But we can implement only retrieving cache. Maybe also deleting expired cache entry, if current entry has "expired" attribute.

And creation/updation/deleting cache will be performed by modules, if they know, that some nodes can be cached. If some nodes are independent of user, modules can put string (rendered node) to cache, instead of object, and nodes will not themed during drupal_render().

So, we can provide only mechanism of retrieving data from cache in node_load_multiple() without global changes in node.module & core. I think, I can provide a patch for that.

catch’s picture

Status: Needs review » Postponed

Modules can't know if a node is themed per user - this happens in themes on a per-site basis.

So the only way to do it would be something like #152901: Caching (per user) for authenticated users. Since we'd need that system in place before applying it to nodes (although probably it could be applied to the entire content region), I'm going to mark this postponed on that patch.

You might be interested in #369011: Performance: do check_markup() in text_field_load() - which caches one extra thing during object loading (not just nodes).

shp’s picture

Modules can't know if a node is themed per user - this happens in themes on a per-site basis.

Yes, I understand. At first, the $page object is constructing, then it's theming recursively (drupal_render()).

I meant the following. Developer knows, that some nodes look the same for different users/pages. And he can put such nodes to cache when the node is creating or updating. The node.module/core only should: 1) to check if there is cache for nodes in node_load_multiple() and 2) delete cache entry for node when node is deleting and before it is updating.

We can also provide new setting in node creation/edition form (user can enable node caching for this node, if he needs it).

sun.core’s picture

Version: 7.x-dev » 8.x-dev
jhedstrom’s picture

Issue summary: View changes
Status: Postponed » Closed (works as designed)

We have render caching now.