Speed Engine – Cache With

Caching is a great improvement for your web site speed. In most cases, it achieves instantly visible speed gains and great advantages in SEO rankings. ClusterCS offers two caching engines: Varnish and NGINX. Depending on your decision or received recommendations you can use either of them with great trust. Same automation features have been implemented for both systems, so you can obtain quick advantages with a few clicks for many scenarios.

You can have multiple “Cache With” rules for a domain and you can customize the settings for each zone individually.

Let’s take an example of WordPress caching rule and discuss the available options.

First, we select the caching engine Varnish or NGINX.

• “use backend” defines the backend web service where the selected caching engine will proxy requests to.
• “load balanced” refers to cluster environments when multiple servers are associated with the backend service. In a load balanced scenario, the caching engine will forward requests in a rotation (round robin) to all the available backend service servers. When “load balanced” is disabled and the caching engine is found on the same server with the backend service, it will forward the request locally to that server. When such a proximity is not available, it would revert to act as if “load balanced” is set to on. In single server cases, this setting is ignored.
• “stickiness cookie” is available to clustered backend web service as well. Sometimes it is required that once a user hits a backend, he will always be sent to that backend (for example to keep a logged in session to the same server). In single server cases, this setting is ignored.
• “Clear cache zone path” provides a mechanism for clearing the cache for the requests cached by this rule. This setting is only enabled when a main “Clear Cache” rule is defined and both definitions must contain a valid path. The URL to trigger a clear cache for this zone is built based on the main “Clear Cache” URL to which this path is added. Since ClusterCS handles both single servers and clusters, a clear cache action may require the cache to be cleared on more than one server. ClusterCS facilitates this by generating links which automatically cycles through the caching engines (servers) involved in the rule. This link can be triggered in a browser for an easy clear cache mechanism. This is especially useful when doing development and frequent clear cache actions are required. For environments when a programmatic trigger of clear cache is required, ClusterCS generates a link which provides a json that helps build the required individual URLs to trigger the clear cache action on all the involved servers. These links (both website and json) can be retrieved by clicking the “Get Links” button. Please remember that zone clear cache will not be available unless main “Clear Cache” rule is present. The “Clear Cache” rule is there to provide a mechanism for protecting your clear cache mechanisms from outside world. For more information on “Clear Cache” rule please read this article <Clear Cache link>. For your own security, always customize the clear cache paths and don’t use the default paths provided and use IP protection conditions in the “Clear Cache” rule or any other conditions that can prevent outside triggers to the clear cache links.
• “Cache expiration per response code” allows you to set specific timers for expiration based on response codes. You can add, remove and customize response codes as necessary.
• “Cache URL includes schema” allows creating of separate cache files for http and https links.
• “Cache URL includes query string” defines the behavior when creating a unique cache key per request. If disabled, anything in the request URL past the ‘?’ sign is ignored, and a single cache file is created and served for any parameters that may show up after ‘?’. When enabled, the cache key will observer the query string parameters as well based on exclusions or inclusions lists.
• “Cache URL params list” defines whether to use the excluded or included list logic on the server.
• “Cache URL exclude params list” allows the definition of query string parameters (what follows ‘?’ in the URL) that can be ignored when creating a unique cache file. Any other parameters not included in this list will be part of the unique cache key of the file. The default parameters handle the cases of Goggle Analytics campaigns which in general have no meaning for your backend script and would highly disrupt your caching mechanism effectiveness. For this list to be active on the server settings, “Cache URL exclude params list” must be set to “excluded list”.
• “Cache URL included params list” allows you to define the only query string parameters that matter to your script (anything that would mean a different content should be generated by the backend service). For this list to be active on the server settings, “Cache URL exclude params list” must be set to “included list”

Only one of the “excluded list” or “included list” can be active at one time as they are logically mutually exclusive. If you are required to have absolutely all query string parameters accounted for, you can select “excluded list” for “Cache URL params list” and clear the corresponding “Cache url exclude params list” box for any parameters (leave it empty).

NGINX used as a caching engine or as a backend web service can be further customized by using the associated “Customize” link when selected that exposes the generated config file.