Purge integration

Created on 30 August 2023, 10 months ago
Updated 11 January 2024, 6 months ago

Problem/Motivation

I was using this module in an environment that had Varnish caching in front of it. At first I thought it wasn't working for anonymous users, but I later realized that I needed to flush the Varnish cache after setting or removing a policy that would impact access for anonymous users.

Proposed resolution

Integrate with the Purge module so that pages impacted by an implemented policy can proactively invalidate the upstream cache.

✨ Feature request
Status

Closed: outdated

Version

1.0

Component

Code

Created by

πŸ‡¨πŸ‡¦Canada mandclu

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @mandclu
  • πŸ‡ΊπŸ‡ΈUnited States partdigital

    Hi @madclu, thanks for reporting this!

    Could you provide some more details? In theory the varnish cache should be clearing based on Tag invalidation.

    I set up varnish on my ddev instance (based on ddev and drupal β†’ documentation) and it seems to be working mostly as expected.

    These are the steps that I followed:

    Environment:
    Install varnish:
    ddev get ddev/ddev-varnish

    Added this to .ddev/varnish/default.vcl

      if(req.method == "BAN") {
          if (req.http.Purge-Cache-Tags) {
              ban("obj.http.Purge-Cache-Tags ~ " + req.http.Purge-Cache-Tags);
          }
      }
    

    Modules:
    Install the purge and purge_purger_http modules.

    Drupal Settings:
    Set caching to 1 year

    Set my purge settings as follows:

    • Type: Tag
    • hostname: varnish
    • port: 80
    • Headers: Purge-Cache-Tags = [invalidation:expression]

    While interacting with a node as an anonymous user I see headers like this:

    1. 403 with policy: X-Varnish: 4751707 (miss)
    2. Refresh: X-Varnish: 2064725 (miss)
    3. 200 without policy: X-Varnish: 2064725 (miss)
    4. Refresh: X-Varnish: 5898824 3572108 (hit)
    5. 200 with policy: X-Varnish: 950757 (miss)
    6. Refresh : X-Varnish: 3801793 721458 (hit)

    So the 200 responses seem to be hitting varnish while the 403 responses are missing varnish (warrants further investigation). In every case however it's showing the correct content.

    Of course every environment is different so if you could share any addition details it would be much appreciated!

  • πŸ‡¨πŸ‡¦Canada mandclu

    Thanks for the very detailed response. I was doing my testing in an Acquia Cloud environment, and the site had the Purge and Acquia Purge modules installed. That said, it was using the alpha8 release of this module, so I will test with the beta1 release and report back.

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

    @mandclu, are you still experiencing any issues with Varnish?

  • Status changed to Closed: outdated 10 months ago
  • πŸ‡¨πŸ‡¦Canada mandclu

    It seems as though the Varnish cache is properly invalidated since I've moving to a beta version. Thanks again for this great module!

  • πŸ‡«πŸ‡·France DYdave

    Hi Joshua (@partdigital),

    Just wanted to thank you very much for your great help with the configuration of the purge module at #2.
    It works great !
    What I could't figure out was the port number... since Varnish in our setup ('dev', 'stage', 'preprod', 'prod') is behind a HAProxy service so it's listening on the default port which is usually 6081, but I "suppose" that since it's in direct access on the local ddev stack, it's listening on port 80.
    Here's a doc I found on Varnish port 80:
    https://varnish-cache.org/docs/trunk/tutorial/putting_varnish_on_port_80...

    When I have some time, I'll try to add a documentation page in the Purge module for the Varnish setup on ddev, which will most likely re-use most of your comment above #2.

    Once again, thanks a lot for your help and contribution !

Production build 0.69.0 2024