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?
HTTP Status Codes
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:
- 502 Bad Gateway – The backend webserver returned a response that the cache was unable to handle or was invalid. This usually indicates a problem on the web servers rather than something wrong with the Webcelerator. If you see this message, you should attempt to repeat your request to the backend server itself and see if it’s returning a valid response (you can do this with a hosts file change if you’ve already pointed your DNS through the Webcelerator).
- 503 Service Unavailable – All backend webservers are offline. If you see this message, the Webcelerator is unable to communicate with any of your webservers, thus it returns this message. By default, the Webcelerator will attempt to make a backend connection five times before returning this status code. Seeing this message usually indicates that a Bad Thing™ is occurring on your webservers that needs investigating.
- 504 Gateway Timeout – The backend webserver did not respond fast enough. If you have a page that performs a lot of processing before returning a result, you might see this error. It can also indicate a performance problem on the webservers. We can increase timeouts on the Webcelerator in order to prevent this message from occurring.
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.
Client IP Addresses
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.
Ready to go live?
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.