<p>Craft only stores a small number of things in the Cache. As per <a href="https://servd.host/blog/adding-redis-to-craft-cms" rel="nofollow noreferrer">this article</a> (disclosure: written by myself) the things Craft will add to a Redis backed data cache are:</p>
<blockquote>
<ul>
<li>Available updates</li>
<li>Plugin store data</li>
<li>GraphQL query results</li>
<li>Some bits of data from the Craft Net API including license information</li>
<li>Project Config modification timestamps</li>
<li>Any data which is explicitly cached by plugins you have installed</li>
</ul>
</blockquote>
<p>Craft doesn't store any data which is cached using twig <code>{% cache %}</code> tags in the Redis backed data cache. The reason for this is discussed <a href="https://craftcms.stackexchange.com/questions/105/what-are-the-best-practices-for-using-the-cache-tag/107#107">here</a> 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.</p>
<p>Brandon puts it a little more succinctly:</p>
<blockquote>
<p>[it] provides the most efficient cache-busting logic</p>
</blockquote>
<p><strong>Update 8th Sept 2020</strong></p>
<p>Craft 3.5 now stores its <code>{% cache %}</code> 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.</p>
<p>It also moves the cache busting logic out of the database and instead uses <a href="https://www.yiiframework.com/doc/api/2.0/yii-caching-tagdependency" rel="nofollow noreferrer">Yii's tag based cache invalidation</a>. 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.</p>

CC BY-SA 4.0
2020-02-26T18:59:03.300Z
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
CC BY-SA 4.0
2020-02-26T19:30:51.610Z
Here's some more info on the `{% cache %}` tag @DominikKrulak -> [The Craft {% cache %} Tag In-Depth](https://nystudio107.com/blog/the-craft-cache-tag-in-depth)
andrew.welch
CC BY-SA 4.0
2020-02-26T19:54:32.070Z
I came across this [blog post](https://nystudio107.com/blog/the-craft-cache-tag-in-depth) 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
CC BY-SA 4.0
2020-02-26T16:55:42.400Z
2020-09-08T21:00:30.103Z
2020-09-08T21:00:30.103Z
Matt Gray
<p>I don't understand how Craft CMS processes cache with Redis especially when saving to database/s?</p>
<h3>My environment:</h3>
<ul>
<li>Craft Pro 3.4.8</li>
<li>PostgreSQL 12.2</li>
<li>PHP-FPM 7.4.3</li>
<li>Redis 5.0.7</li>
</ul>
<p>I followed <a href="https://docs.craftcms.com/v3/config/app.html" rel="nofollow noreferrer">examples from the Application Configuration documentation</a> and It seems that Craft CMS works well Redis. From inspecting both databases, sessions and queue work as expected.</p>
<ul>
<li><code>queue</code> table is created in SQL DB but empty because all queue related storage is moved to Redis where I can see all the keys <code>queue.message_id</code>, <code>queue.messages</code> and <code>queue.waiting</code>. <code>queue</code> table will probably always stay in SQL DB from installation process.</li>
<li>when a session begins <code>token</code> value is created in <code>sessions</code> table in SQL DB with some session related attributes and I also could locate the same <code>token</code> key-value in Redis DB with additional info about current session. When session ended token was removed from both databases.</li>
</ul>
<h1>Cache</h1>
<p>I created some matrix field content and I cached it.
I found out that a row with <code>cacheKey</code> and other attributes (along with <code>body</code> column) are created in <em>templatecaches</em> 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.</p>

<craft3>
How does Craft CMS cache with Redis?
# How does Craft CMS cache with Redis?

(Asked by: username_0 on 2020-02-26)

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](https://docs.craftcms.com/v3/config/app.html) 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.

**Tags:** craft3

---

## 1 answers

### Answer by username_1 on 2020-02-26. Score: 4 | Accepted answer

Craft only stores a small number of things in the Cache. As per [this article](https://servd.host/blog/adding-redis-to-craft-cms) (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](https://craftcms.stackexchange.com/questions/105/what-are-the-best-practices-for-using-the-cache-tag/107#107) 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](https://www.yiiframework.com/doc/api/2.0/yii-caching-tagdependency). 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.

> **Comments:**
> **username_0**: 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.  
> **username_2**: Here's some more info on the `{% cache %}` tag @DominikKrulak -> [The Craft {% cache %} Tag In-Depth](https://nystudio107.com/blog/the-craft-cache-tag-in-depth)  
> **username_0**: I came across this [blog post](https://nystudio107.com/blog/the-craft-cache-tag-in-depth) 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.  

---

