servd

Redis

Every project hosted on Servd uses Redis by default. You don't have to add any special config or enable anything in the dashboard, simply deploy your project and you're away.

Why does Servd use Redis? #

By default, Craft CMS stores various files on the filesystem of your PHP server, such as caches and sessions. On Servd however, we store these things in a Redis database that lives independently on a separate server. We do this for a few reasons:

Scalability - When a site runs on a single server, storing runtime data on the filesystem is fine. However, it becomes a problem when we want to scale horizontally and add more PHP servers. Files stored on one server's filesystem are inaccessible to others, which can lead to a lot of unusual behaviour, e.g. database deadlock, baskets being lost, users randomly being signed out of their accounts, etc. However, by configuring Craft to read and write runtime data to an independent Redis database, PHP servers can be added and removed without issue, offering us a lot more scalabilty.

Security - Servd treats its PHP filesystems as ephemeral. Every time a server is replaced by another one (e.g. when you deploy a change), the filesystem is reset, along with any caches and sessions stored on it. This is great from a security perspective, but less great if you're storing your runtime data on the filesystem. They'll just get repeatedly get wiped every time a server is replaced. By using Redis as an independent and external place to store data, server tear-downs leave the data intact and avoid the issue entirely.

Speed - Redis is an "in-memory database" which means it's fast; much faster than reading data from disk. By storing performance-specific data in it, such as caches, you get further performance benefits.

How does Servd set up Redis? #

We inject our own custom Craft config files into your project during deploys, overriding certain items in the config pulled from your git repository. This includes all the necessary plumbing to get your project talking to one of our Redis servers. You shouldn't have to do a thing. 🥳

High Redis Memory Usage #

If your project is using Servd's Static Caching, you might notice that the Redis memory usage is high or maxing out at 100% in the Metrics page. While it's best to have Redis memory usage below 100%, it worth noting that it's not a critical issue and won't prevent your project from responding to requests. When Redis hits 100% memory usage, it employs a least-recently-used (LRU) policy, where the cache items that have not been accessed for the longest time get evicted from the cache to free up memory. Consequently, this means that the static content for pages that don't get visited very often will expiry earlier than configured, but frequently visited pages, like the home page, will remain cached.

If you wish to the reduce the Redis memory usage, here are a few points to consider:

1. Avoid using the "Include all query parameters" in the "Include query params in cache keys" static caching setting. Opting for a more selective option can help avoid caching duplicate content. E.g. with the "Include all query parameters" option selected, the cached content for https://example.com and https://example.com?fbclid=123... would be stored in two cache items, even though the the tracking "fbclid" query parameter isn't really relevant to the content that is returned.
2. The "Automated Tag Based Purge" option for Servd plugin's "Cache Clear Strategy" setting this has been observed to occasionally use a lot of Redis memory, particularly for projects that load a lot of entries across multiple pages, e.g. for the purposes of generating the headers and footer templates. You might want to experiment with turning off that setting and track the memory usage to see if it is responsible.

If none of those options fully resolves the high memory usage, and you believe it's having a notable impact on your project, then get in touch via support@servd.host and we can get your project on a custom plan to increase the available Redis memory.