Speed Optimization – Intro

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. Speed Engine – Serve With – select one of the load balanced web services to handle the request, this reflects your currently set up services
2. Speed Engine – Cache With – select a caching capable web service to proxy the request through
3. Speed Engine – Clear Cache– define and protect a clear cache URL that can be used for refreshing a cache
4. Speed Engine – SEO Redirect – ability to do HTTP/HTTPS changes, www to non-www and vice versa redirects
5. Speed Action – Rate Limit – an antispam solution which allows you to set a number of requests in a certain time period from an IP
6. Speed Action – Require Authentication – secure a webpage or certain links with a username and password in order to add an extra layer of security.
7. Speed Action – URL Redirect –webserver’s functionality to send a user from one URL to another one
8. Speed Engine – Proxy – reverse-proxy to any IP and Port, locally or on an external server
9. Caching on WordPress using nginx – more speed, a better experience for your visitors, for SEO, or any personal reason
10. Caching on WordPress using Varnish– more speed, a better experience for your visitors, for SEO, or any personal reason
11. Block – allows rejecting a request to protected resources defined by conditions (eg. Admin area)
12. End with HTTP code – like Block but can end the execution with various status codes