Caching can help reduce server load and improve the performance of your website or application. This is done by storing a static copy of requested content so that it is quickly accessed for future requests.
Our caching is set up to to be safe and conservative by default. We will only cache content explicitly defined by your application's HTTP cache-control headers. This means that if your application does not provide these headers, then no content will be cached.
In order for content to be cached you will need to set a cache-control header as explained below. If there is content that you would like to avoid being cached, for example where users are required to log in or pages that contain live updates such as a shopping cart, you can send a no-cache header as well as adding those pages using the Ignored Paths feature.
Specifies the size of the cache.
Keep in mind that this will use part of the disk space that comes with your Cloud Container Server. Setting this value higher will allow more content to be cached which is useful for larger applications.
This specifies how long content can remain cached before a new copy must be requested from the origin server.
This specifies how long an item can remain in the cache without being accessed or requested.
This value cannot be lower than lifespan. When an item has reached its lifespan and the inactive value is set higher, the next request will be provided a stale copy, but the container will also be sent a request for a new copy to be cached for following requests. This is useful as this helps reduce the number of cold starts when loading the page.
Anything specified here will be not be cached.
If you are uncertain your application is handling cache-control headers
properly, or just want the added protection, you can specify certain paths to ignore like /admin or /wp-admin.
You can also ignore specific files like /test.php.
The following is a list of invalid characters to use in your ignored paths:
\n)\r)') and Double quotes("){})$) - This is to maintain compatability with docker labels, where $ is used for variable substitution.,) - We store the paths as a comma seperated string, so adding commas to a path will result in 2 seperate paths.The first step we recommend is to ensure your application is set up to work correctly with caching. There are potential security risks with enabling caching, so making sure that we don't cache certain content is important.
The cache-control headers specify which content will be cached, so setting the following for pages where caching is not desired: cache-control: no-cache, max-age=0 will ensure a copy is not stored.
For static content, such as the home page, we recommend passing cache control headers that are similar to the following: cache-control: max-age=86400. You can read more about cache
control headers in this article from MDN Web Docs.
If you have configured your application to handle caching and are still getting a
MISSfor theX-Cache-Status, check that your application's sessions setting is not causing the proxy to not cache any responses.
WordPress, out of the box, is configured for secure caching management. WordPress uses cache-control headers to disallow caching when you are logged in.
We recommend reading the following SilverStripe documentation
that covers how to set the cache control headers using their HTTPCacheControlMiddleware class.
By default, SilverStripe sets cache control headers that discourages caching. This results in responses not being cached
when caching is enabled through the SiteHost Control Panel. To enable caching globally, edit the
PageController.php file and add use SilverStripe\Control\Middleware\HTTPCacheControlMiddleware; below the <?php tag.
Once you have included the additional line, you may add the following lines to the init function.
public function init()
{
HTTPCacheControlMiddleware::singleton()
->enableCache()
->setMaxAge(86400); // 1 day
parent::init();
}We recommend having a look at the following Craft Documentation which covers how to handle cache control headers.
To control cache headers, you need to modify any template for a page you want cached to include a line similar to:
{% header "Cache-Control: max-age=86400" %}When logged in as an admin user, navigate to Configuration > Performance. Set the lifespan to the desired value or, if you have set it already, the same value entered through
the SiteHost Control Panel. After you have set the lifespan, press the Clear all caches button to clear any files that have been cached by Drupal's internal cache.
There are two ways of implementing the cache control headers in Grav. One allows you to define a global setting through Grav's admin control panel, the other allows a granular approach where you define how long to a cache a page inside the markdown for that page. If you go with the second approach we recommend having a look through the Grav docs on HTTP Headers.
To control the cache-control on a per page basis you will want to add this line to the title section of any page you are
wanting to cache: cache_control: max-age=86400.
We recommend setting up your application to handle caching and making sure the cache settings are correct before enabling caching
Status label click the On button.Lifespan and InactiveStatus label click the Off button.Save Settings to update the cache config for this container.Purge Cache label click the Purge Cache button.You can easily check the headers set for any given page by opening your browsers devtools (often pressing F12 will open them). Click on the Network tab and select the resource you wish to see the headers for.
You may need to reload the page for your browser to record the network activity.
Under the Headers tab, scroll down to Response Headers and look for the X-Cache-Status header where you will see if the request is one of the following:
HIT The content you received was from a cached copy.MISS The content you received was a fresh copy.EXPIRED The content you received was a fresh copy as the current copy in the cache was outdated.UPDATING The copy you received was stale, but is being updated in the background.If you are unable to see the X-Cache-Status header, check that your application has been configured correctly to handle caching.
Try clearing the cache in the SiteHost Control panel, if your application has purge functionality you should also purge that.
X-Cache-Status is always set to MISSMake sure your cache-control headers are set properly, if they contain values like no-cache or max-age=0 then the
proxy will not cache the response.
Another possible culprit would be your application creating a session or setting cookies which will result in the proxy not caching the response.