Cache stampede protection: drupal_render() and page cache

Created on 18 May 2010, over 15 years ago
Updated 2 September 2025, about 1 month ago

Attached simple patch uses lock system to ensure that only one request is rebuilding a given cache item at a time.

Note that the first line of the patch is just cleanup. $cid can't be empy or else we left this function a few lines earlier.

If we agree on this approach, I will submit similar patches for block and page caches (others?).

πŸ“Œ Task
Status

Postponed: needs info

Version

11.0 πŸ”₯

Component

base system

Created by

πŸ‡ΊπŸ‡ΈUnited States moshe weitzman Boston, MA

Live updates comments and jobs are added and updated live.
  • Performance

    It affects performance. It is often combined with the Needs profiling tag.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

  • πŸ‡¬πŸ‡§United Kingdom catch

    Now that we use the render cache for a lot more things, I don't think locking at that level would be a good idea - the lock acquire overhead is non zero, most pages have several render cacheable items on them, and the cardinality of most cached items is quite high.

    There are individual cases like header or footer menus that appear on every page, it might be possible to lock these, but this could be implemented at the level of individual block plugins (e.g. we could implement a lock in system menu block rendering).

    πŸ“Œ Use revolt to prewarm caches during lock waits Active might entail adding locking to more low level caches though - theme registry, library discovery etc. that can be pre-warmed.

Production build 0.71.5 2024