Opened 3 months ago

Last modified 3 weeks ago

#14270 assigned Bug/Something is broken

Problem with cache?

Reported by: https://id.mayfirst.org/workersliberty Owned by: https://id.mayfirst.org/jaimev
Priority: Medium Component: Tech
Keywords: Cc:
Sensitive: no

Description

Hi, when using the search function or loading a page with multiple articles and there is more than one page of listings, users cannot proceed to the next pages (i.e. page 2, page 3 and so on). The search function is also intermittently usuable, sometimes it brings up results for the wrong key word. These faults do not replicate when users are signed into the website. Our website developers think the fault(s) are related to the cache used by the server. They asked us to ask you what cache do you use, and can it be disabled. They think disabling the cache will fix the fault. Many thanks!

Change History (7)

comment:1 Changed 3 months ago by https://id.mayfirst.org/jaimev

  • Owner set to https://id.mayfirst.org/jaimev
  • Status changed from new to assigned

We have placed an nginx reverse proxy chache in front of your site. The cache has been tremendously helpful in speeding up your site and reducing load on the server. I would much prefer to find a way to ensure that the cache excludes search results and queries rtaher than turn it off completely. Is that something your website developers would be willing to work with us on?

comment:2 Changed 3 months ago by https://id.mayfirst.org/workersliberty

Hi, Thanks for that prompt clarification/reminder. We are in the process of drawing up a list of all the work we need to do on the site, so we'll come back to you on this sometime next week. All the best, Cathy

comment:3 Changed 3 months ago by https://id.mayfirst.org/workersliberty

Hi Jaime (this is ekes logged into the wl account! I'm having a look at what needs cleaning up on their site)

As this is D8 and could do tag based cache invalidation it seems a good impetus for me to look at the purge that if I remember was in a 'enterprise' feature, but still available in an additional debian package. Search API for example has it's own cache tags for search results which could make all this much more efficient.

comment:4 Changed 3 months ago by https://id.mayfirst.org/jaimev

Yes, I remember we began investigating this in ticket #12592 We are cuurently running nginx-extras with the nginx-cache-purge module enabled.

https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/#purge_secure

Do you have any examples of how we can use this to do tag based cache invalidation?

comment:5 Changed 3 months ago by https://id.mayfirst.org/ekes

Do you have any examples of how we can use this to do tag based cache invalidation?

Urgh! I've dived down the rabbit hole that is nginx cache invalidation strategies other than URL and it's extra plugin hell (like https://github.com/wandenberg/nginx-selective-cache-purge-module for example).

Otherwise seems it's manually configuring slices, and making sure they are efficient etc. etc.

Well we can configure some invalidation using the https://www.drupal.org/project/purge_purger_http and see how far we get. It'll be after other stuff is cleaned up though.

comment:6 Changed 4 weeks ago by https://id.mayfirst.org/ekes

Current status update:-

The rebuilt Workers' Liberty site still has lots of private files which are causing Drupal 8 to mark cacheable pages as non-cacheable. When this is fixed the Cache-Control header from Drupal 8 can be trusted. It a line commented out in the configuration at the moment.

Doing this will fix the search issue (cause of this ticket).

Further use of Drupal 8's cache (and its invalidation) isn't really possible with nginx - or rather it seems it would be crazy time consuming to set up, and is really not something supported by either Drupal or nginx.

comment:7 Changed 3 weeks ago by https://id.mayfirst.org/ekes

I have changed the nginx configuration it is now trusting the headers from Drupal 8 about caching generated pages.

The site is setting a 10 minute cache. Checking the headers via nginx it is respecting this. I suggest figure can be upped in the website if need be for performance. Not sure I can see the load on that box.

I also unset the proxy_cache_key $host$uri; which was also breaking the pagination (ie GET ?page=1 queries being dropped and only host and uri being used as key).

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.