Minify the cache tags sent in the header

Created on 12 March 2018, over 6 years ago
Updated 21 June 2024, 7 days ago

Problem/Motivation

Most webservers have a maximum size for headers.

Proposed resolution

We could implement an (optional) hashing strategy that would significantly reduce the size of the headers that are sent out.

Acquia purge already includes a similar solution → .

✨ Feature request
Status

Needs work

Version

3.0

Component

Code

Created by

🇧🇪Belgium mpp

Live updates comments and jobs are added and updated live.
  • 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.

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.

  • 🇫🇮Finland masipila

    I'm testing (and reading) the patch #57.

    +/**
    + * Implements hook_purge_cache_tags_simplify_dictionary().
    + */
    +function purge_purge_cache_tags_simplify_dictionary() {
    +  // Most common list cache tags.
    +  return [
    +    'config:block_list' => '/^config\:block\./',
    +    'menu_link_content_list' => '/^menu_link_content\:/',
    +    'media_list' => '/^media\:/',
    +    'node_list' => '/^node\:/',
    +    'file_list' => '/^file\:/',
    +    'taxonomy_term_list' => '/^taxonomy_term\:/',
    +    'user_list' => '/^user\:/',
    +  ];
    +}
    

    Could somebody please elaborate once more what's the conceptual logic behind this?

    Isn't it so that:

    • An individual node page, will only have node:42 cache tag
    • But a View that renders nodes will have also node_list (and node_list:) so that whenever new nodes have been created, the Views that render these nodes will be invalidated.

    So are we throwing away the node:xxx tags if and only if also the node_list tag is also present? In other words, the individual node pages would still have the node:xxx cache tags?

    If my thinking-out-loud is correct here, can we please elaborate the documentation block of purge_purge_cache_tags_simplify_dictionary()?

    Cheers,
    Markus

  • 🇺🇸United States afinnarn

    I'm not sure how helpful this comment is, but I tried the patch in #54 and got the following error.

    The website encountered an unexpected error. Please try again later.
    ArgumentCountError: Too few arguments to function Drupal\purge\Plugin\Purge\TagsHeader\TagsHeaderBase::__construct(), 3 passed in /var/www/html/docroot/modules/contrib/acquia_purge/src/Plugin/Purge/TagsHeader/AcquiaCloudSiteHeader.php on line 41 and exactly 4 expected in Drupal\purge\Plugin\Purge\TagsHeader\TagsHeaderBase->__construct() (line 32 of modules/contrib/purge/src/Plugin/Purge/TagsHeader/TagsHeaderBase.php). 
    

    I had to switch to other work and didn't have time to look into the error, but I will update the thread if I do. Posting since someone else might encounter the error or know how to fix in a patch.

  • 🇺🇸United States afinnarn

    Okay, the relevant patch in the Acquia Purge module is here and it says to re-roll into this patch: https://www.drupal.org/project/acquia_purge/issues/3157178 →

    I will look into this now in my local dev environment.

  • 🇨🇦Canada NickDJM

    Rerolled #57 for latest version.

  • 🇧🇪Belgium bceyssens Genk 🇧🇪

    I'm not a fan of the hashing solution as you have no idea what the content is. The dictionary looks like a lot of work to maintain.
    As an alternative method I added compression strategy, keeping only the first letter of each word. It is fully automated and you could still retrieve the original cache tag.

    As you should still have the option to disable minification logic completely, I changed the configuration form to a select.
    Example minitication ratios (number of characters in the cache tags header):

    • None: 4030
    • Dictionary: 2337
    • Compress: 1300
    • Hash: 734
  • 🇧🇪Belgium bceyssens Genk 🇧🇪

    Replacing incorrect patch

  • 🇦🇺Australia swatigarg06

    I tested patch #63 and it seems to be failing for 8.x-3.4.

Production build 0.69.0 2024