We all know that web services sometimes virtually disappear from the internet. They don't need to fail, routing problems or congested transmission lines suffice. Here's what we did and what you can do to mitigate such outages.

Scrivito has a very sophisticated caching layer that vastly reduces the number of requests your application needs to make to Scrivito. For the majority of website visitors, assuming a warm cache, only one request to Scrivito is required. The purpose of this request is to check whether the published content has changed.

The published content only changes after publishing (sounds logical, doesn't it?). If the amount of published changes is small, Scrivito adds the changes to the existing cached data. This has the effect that your app only needs to perform requests for the changed content instead of having to rebuild the whole cache from scratch. With very extensive publishing actions (more than 100 changes to CMS objects), or if more than one other working copy was published in the meantime, it is more expensive to update the current cache, so it is completely invalidated instead. Therefore, it is recommendable to publish smaller amounts of changes to improve the performance and stability of your site. This also leads to more comprehensive working copies.

Scrivito uses the standard Rails caching FileStore for storing the cached content, however, it uses a folder separate from the application cache. You can adapt the path of the cache using the cache_path configuration, like so:

Please ensure that the ownership of and the permissions for the cache directory have been properly set. Also, for best caching behaviour, we recommend to not place your Scrivito cache onto a file system for which noatime has been set.

It is essential to remove the garbage from the cache regularly to prevent the file system from running out of inodes. Scrivito provides a garbage collector for this, scrivito:cache:gc. For scheduling, we recommend to use whenever:

This installs a crontab entry that runs the garbage collector rake task once a day.

Scrivito lets you configure a second level-cache which is used if the file store cache does not contain the data Scrivito is looking for. Caching data in the local file system suffers from the disadvantage that the cache is not shared across multiple machines. This can be fixed by means of a second-level cache which acts as a machine-independent cache layer. This second-level cache is only queried if the data is not available locally, which would otherwise result in a request to Scrivito. As with data fetched by means of such a request, the data fetched from a second-level cache is stored in the local cache, speeding up subsequent access to this data.

If you have a warm cache, your application renders the website using the cached content. Remember, given a warm cache, your app only checks with Scrivito if something has changed. In case Scrivito is not reachable, it is assumed that nothing has changed, causing the cached content to be delivered. So, even if your machines are cut off from Scrivito, there is a good chance your site will continue to work.

This behavior can be further improved by using a second-level cache. As it aggregates the cached content of all your machines, the second-level cache, compared to the local cache, is far less likely to miss a specific piece of content. Also, the second-level cache is automatically utilized by new machines that do not have locally cached content yet.

So, keeping the amount of changes you publish small and using a second-level cache can significantly improve the stability and performance of your site, making the most of Scrivito's built-in caching layer.