ClusterCS Speed Engine

At ClusterCS, we have always focused on automation, flexibility and ease of use. The Speed engine is a traffic router for the web services that can deliver your website content. The Speed section interface offers an intuitive rule builder for sending and resolving web requests with the desired web service based on various conditions. The same logic applies to single servers and complex server clusters managed by ClusterCS. For more information on the ClusterCS Speed engine concepts please read the < ClusterCS Speed Engine – Concepts > section.

 

The Speed engine functionality is available for setups that utilize the HAproxy service as the web domain entry point. Services that can be utilized for traffic routing include Apache, NGINX, Lighttpd and Varnish, given that their settings have enabled HAproxy as the upper layer 7 load balancer. The default “Smart LAMP” setup provides this entire functionality out of the box. For custom setups, please make sure you follow the guidelines above.

 

A speed rule is composed of conditions and associated action. If the conditions are met for a request, the selected action is performed. It is very important to remember that the order of the rules matters. If a certain rule meets the criteria, its action will be executed, and remaining rules will no longer be evaluated.

If none of the rules match the received request, it will be forwarded to the web service assigned as default in Speed.

 

The rule conditions contain the following test types

  1. Path – the component of the URL following the domain name and before ‘?query’ Eg: for http://example.org/example_path/?qs , the path component will be “/example_path/”

    url_sub and not_url_sub (negation) tests will perform searches across the entire URL (including what is after ‘?’)

  2. Scheme – the URL scheme type (http or https)

  3. Cookie – cookie tests will be performed on the entire cookie header string

  4. IP – the source IP of the entity making the web request (client IP)

  5. Method – http request method (GET, POST, etc.)

  6. Host – matches on the domain name.

    Important: since the rule is created logically under a domain name, tests for the domain names and aliases are always performed so this rule is evaluated under the correct context. However certain tests require specific matches on the domain name such as tests for www. components or alias only tests - these can be easily performed with the Host tests

  7. Referrer – web request http referrer

  8. User Agent – web request user agent (eg: browser detection)

 

The actions contain the following options:

  1. Serve With – select one of the load balanced web services to handle the request, this reflects your currently set up services

  2. Cache With – select a caching capable web service to proxy the request through

  3. Clear Cache – define and protect a clear cache URL that can be used for refreshing a cache

  4. Block – allows rejecting a request to protected resources defined by conditions (eg. Admin area)

  5. End with HTTP code – like Block but can end the execution with various status codes

  6. SEO Redirect – ability to do http/https changes, www to non-www and vice versa redirects

 

Some of these actions can have a complex usage, that is why we are providing dedicated articles below to understand how to implement and benefit from them.

ClusterCS Speed Engine – Concepts
ClusterCS Speed Engine Actions – Serve With
ClusterCS Speed Engine Actions – Cache With
ClusterCS Speed Engine Actions – Clear Cache
ClusterCS Speed Engine – SEO Redirect

Average rating: 5 (1 Vote)