In our final post in the web acceleration series, we take a look into the final preparations before setting your Webcelerator live. You’ve covered the basics, tested, tested and tested again – now what?
Having a Webcelerator in front of your solution can present you with new error codes to deal with and understand, next to the usual 404s and 500s you normally see. These are as follows:
The Webcelerators have the ability to monitor your backend servers to ensure they’re responding correctly before sending traffic to them. Primarily this is only useful if you have more than one server behind the Webcelerator. By default, it will monitor the page returned when you visit the IP address of your server (e.g. http://198.51.100.10/). We can configure this to monitor an arbitrary script, including one that isn’t on the default site (by sending a Host header with the monitoring request).
The Webcelerator considers a backend to be online if the page it’s monitoring returns a 200 OK HTTP status code. It can also accept 3xx status codes as ‘good’, but I would advise against returning anything other than 200 OK as a ‘good’ status. 4xx and 5xx status codes will mark that backend as offline and remove it from the load balancing rotation.
Having a monitoring script you can control allows you to take a backend out of the load balancer rotation for maintenance or upgrades without affecting the live site, as traffic will automatically be directed to your other servers.
Your monitoring script could also connect to your database and run a very quick query (
‘SELECT NOW()’ for example) and return an appropriate status code based on whether that connection and request succeeded or not. If you do this, the query you use should return quickly and not put excessive load on the database, as the script will be called every few seconds.
Since all requests to your web servers will now be coming directly from the Webcelerator, you may notice that the log files on your server show that every request comes from the same IP address. If you’re using something like Google Analytics, this shouldn’t matter. If you’re using local statistics processing tools like Awstats or Webalizer, you won’t be able to extract meaningful data from your logs anymore.
The Webcelerator will place the client’s IP address into an X-Forwarded-For HTTP header. We can make your web server log this as the client’s IP instead by applying a platform-dependent fix. If you need your local logging to work correctly please speak with us and we can apply the appropriate fixes to your solution. (If you’re interested, these are mod_rpaf for Apache, an ISAPI filter for IIS, and the HTTPRealIPModule for nginx).
If your web application relies on knowing the client IP for various functions, you should begin inspecting the X-Forwarded-For header instead of the IP where the request came from.
When you’ve completed your rigorous rounds of testing and feel confident using the Webcelerator, you should change the DNS for the domains to point to the Webcel VIP(s). Going back to our example at the start of this post, we would change the DNS ‘A’ records for example.com and www.example.com from 198.51.100.10 to 198.51.100.200. Once DNS has finished propagating, you would find your site is now active through the Webcel. Remember to remove your local hosts file entry so you can see what the rest of the world sees!
With regards to DNS itself, most DNS changes can take up to 24 hours to propagate globally (and sometimes longer). You can reduce this time by changing your domain’s TTL value to 30 minutes at least 24-48 hours before you plan on changing your DNS ‘A’ records. This should reduce the amount of time it takes to propagate the DNS changes (although there will still be places it can take longer than the TTL value!). If you host your DNS through UKFast’s SafeDNS, you should speak with your account manager to get SOA controls enabled for your domains.
I’ve stressed testing in this post because of the amount of time it takes to propagate a DNS change. It’s not something you just roll back instantly if you notice a problem with the way your site and the Webcelerator interact.
Hopefully this article has provided you with the information you need to get started with your Webcelerator.
Every Webcelerator migration is going to encounter problems, but don’t be disheartened. Working together we can work out the issues and get your site performing faster than it ever has before.
If you’d like more information on our Webcelerator technology, please see this link.