In the second of our series delving into Webcelerator web acceleration technology, we take a look at the first steps to take to make your site even faster. You’ve bought a Webcelerator, now what?
Let’s assume that your domain – example.com – is currently pointing to a webserver at 198.51.100.10. As part of your expansion plans, you’ve purchased a redundant Webcelerator configuration to allow you to expand without adjusting the rest of your solution too much. This is fairly simplified, but I want us to concentrate on the Webcelerator rather than worrying too much about load balancing and the problems that brings – that’s one for another post!
Once your Webcelerator is installed, you should have received some instructions from UKFast support. The most important thing you’ll need from them is your VIP (or VIPs – also known as a floating IP). If you have more than one Webcelerator, these VIPs will move between them as failover events occur, rerouting traffic through the working Webcel. In the above example, your VIP is 198.51.100.200. Web traffic hitting this VIP will pass through the cache before being sent onto the backend webserver if necessary.
You can have multiple VIPs that each point to a different set of backend webservers (e.g. VIP1 -> Web1 & Web2; VIP2 -> Web2 & Web3, etc). We’ll keep things simple for this example, but remember that the Webcelerator can be as flexible as you need it to be.
What you should do at this point is change your hosts file to point to the VIP for the domains you’re interested in testing through the Webcelerator. This will allow you to type “example.com” in your web browser and be directed through the Webcelerator rather than going to where the actual DNS name points, so you can test your Webcelerator configuration without affecting the live site.
Here are some links to help you change your hosts file appropriately:
So for our example we would add the following to our hosts file (same for every operating system):
198.51.100.200 example.com www.example.com
It’s important that you put any required subdomains on the same line as well, especially the www subdomain (even if you normally redirect to remove it). On Windows, you may need to flush your DNS cache – see the link above.
Now, when you type “example.com” into your browser, you’ll be taken to 198.51.100.200 instead of 198.51.100.10, so you’ll see your site through the Webcelerator. Doesn’t look any different, does it?
While a Webcelerator can improve response times for static content for individual users, generally you’re not going to see a massive, instant improvement in response times immediately. However, get a few hundred users browsing your site at the same time and your web server will be thankful for it!
At first your cache will be empty, so you’re not going to see much performance benefit as you begin to move around your site. Browse around for a bit using Firebug or Chrome Developer Tools and watch your response times for static content like images and CSS. Generally you’ll see response times dropping as these items are served from the cache rather than your webservers.
Out of the box, the Webcel has a fairly generic, conservative configuration for most things. It is fairly aggressive about caching static content though. The following file types will be forcibly cached for 2 hours by default:
jpeg, jpg, gif, png, css, js, xml, txt, ico, xpm, swf, flv, pdf
By ‘forcibly cached’, I mean the Webcel will strip [Set-]Cookie, Expires, Pragma and Cache-Control headers, set its own Cache-Control headers (
max-age=7200 public) and then add it to the cache. In most cases this should be okay, especially as you can PURGE content if you need to update it before the cache refreshes it from the backend (more on this shortly). Of course, we can tweak this to your needs as necessary or make it obey Cache-Control headers correctly if you would like more control over what is cached.
For now, though, we must test. In the next post we will look at the importance of testing, testing and testing again. No, that’s not enough, more testing!