2

I don't understand how Craft CMS processes cache with Redis especially when saving to database/s?

My environment:

  • Craft Pro 3.4.8
  • PostgreSQL 12.2
  • PHP-FPM 7.4.3
  • Redis 5.0.7

I followed examples from the Application Configuration documentation and It seems that Craft CMS works well Redis. From inspecting both databases, sessions and queue work as expected.

  • queue table is created in SQL DB but empty because all queue related storage is moved to Redis where I can see all the keys queue.message_id, queue.messages and queue.waiting. queue table will probably always stay in SQL DB from installation process.
  • when a session begins token value is created in sessions table in SQL DB with some session related attributes and I also could locate the same token key-value in Redis DB with additional info about current session. When session ended token was removed from both databases.

Cache

I created some matrix field content and I cached it. I found out that a row with cacheKey and other attributes (along with body column) are created in templatecaches table in SQL DB. Since using Redis I expected that all/most of cache related storage will be stored in Redis. Inspecting Redis and I couldn't find anything to cache related stuff.

Community
  • 1
Dominik Krulak
  • 1,562
  • 14
  • 27

1 Answers1

4

Craft only stores a small number of things in the Cache. As per this article (disclosure: written by myself) the things Craft will add to a Redis backed data cache are:

  • Available updates
  • Plugin store data
  • GraphQL query results
  • Some bits of data from the Craft Net API including license information
  • Project Config modification timestamps
  • Any data which is explicitly cached by plugins you have installed

Craft doesn't store any data which is cached using twig {% cache %} tags in the Redis backed data cache. The reason for this is discussed here but it boils down to the fact that Craft maintains a relationship between element queries inside the cache block and the cache results. This allows edits to specific elements to be traced back to all of the cache blocks that they might impact and should therefore be cleared.

Brandon puts it a little more succinctly:

[it] provides the most efficient cache-busting logic

Update 8th Sept 2020

Craft 3.5 now stores its {% cache %} tag data in the default data cache configured for Craft. If you are using Redis as Craft's data cache your template caches will now be placed there.

It also moves the cache busting logic out of the database and instead uses Yii's tag based cache invalidation. These changes should be significantly more performant and prevent previous issues with background tasks trying to clean up too many cache entries held in the database.

Matt Gray
  • 56
  • 1
  • 3
  • Very nice answer and the article. Clears all out. Currently I cache for a longer period of time to keep data longer available than default 24H. Now that I know that Redis will not help me with saving some space on SQL DB I must reconfigure it. From the performance point of view if in front of front end content is some CDN it would be sensible to set cacheDuration to a time that CDN will cache new content. Then cache data from SQL DB will expire sooner therefore storage is freed. Anyway, good answer. – Dominik Krulak Feb 26 '20 at 18:59
  • 1
    Here's some more info on the {% cache %} tag @DominikKrulak -> The Craft {% cache %} Tag In-Depth – andrew.welch Feb 26 '20 at 19:30
  • I came across this blog post and I must read it again because I've missed that cache data automatically regenerate when expire. I though it only happens when content is updated and then cache data requested. – Dominik Krulak Feb 26 '20 at 19:54