Careful What You Wish For
So your Minion-themed, Keurig cups filled with Sumatran weasel poop coffee got a product placement on Suits last Wednesday and your website is off da hook and blowing up for realz. No, literally, it’s off the hook and not responding. It might be blowing up, too, but the data center is in Sheboygan, WI (best place to raise a family according to Reader’s Digest in 1997) and it’s a lights-out operation with nary a human in sight. Can a virtual server overheat? Will it start smoking? Dunno, but regardless, the opportunity is already lost and the damage to your brand is real.
Whether your site is getting crushed because of a viral campaign gone good or news gone bad, you’ve got to be prepared. When your problem is caused by too much traffic, it's already too late. Any sort of fixes you put in place when the problem is happening usually require things to be reconfigured, restarted or redistributed. These actions often make the problems worse before they can make the problem any better. So, like with most things, it’s important to get out in front of it.
Plan If You Can
So if you do have the gift of advance notice of an event that may spike your traffic, use it to your advantage and start planning for the influx asap. Many ISPs have lead times for ordering new servers and load-balancers, so make sure you order your new equipment early. You’ll also need time and resources to make adjustments to your site.
How much to order becomes the $64k question. If the spike is a regular occurrence, you’ll be able to build empirical data to help you make these decisions with more authority as you gain experience. We have a client who regularly engages with a TV show that features a product showcase. The client offers a product for a great price and a national audience responds with heavy sales volume. We keep statistics and records regarding the traffic and orders, and tie them to the increased server capacity. We also make some assessments, with our client, on the popularity of the product. All of these data points factor into the properly-sized server setup that we bring to bear on each promotion. And over the past few years, we’ve gotten pretty good at it.
The actual hardware that you bring to bear to support an event or promotion can vary wildly. But there are some general themes that are commonly employed. Here are the different parts.
A load balancer does just what its name suggests, it balances the incoming load and distributes it evenly among two or more web servers. The nuts and bolts of load balancing is a science in and of itself, but most ISPs will supply you with an appliance (often virtual), that sucks in traffic and sprays it out the backend to a variety of web servers. You’ll have some parameters that can be adjusted but for the most part, they’re already configured for speed.
You’ll need to pay attention to DNS setup and SSL certs, these items will often have specific setup issues necessary to accommodate the load balancer. Remember, your hostname will point to the load balancer, not the webserver.
After the load balancers, are the web servers. These web servers are generally the same type of server that supports your site from day to day, but are bigger and more numerous. We do most of our work on Linux servers. So with Linux, you’re generally running Apache or NGINX. As a general rule, if you want the best performance, you need to run NGINX. It’s not a drop-in replacement for Apache but it’s very similar and, in most cases, it’ll run rings around Apache.
You do need to be mindful of a few things when you migrate your website from one web server to many. First, session handling can become problematic, depending on how your site works. With most load balancers, you shouldn’t plan on a particular user getting routed to the same web server for their entire session. There’s a good chance that even within one page request, a user could be getting data from multiple web servers. If your sessions are handling at the web server level, this could be an issue.
Likewise, make sure there’s nothing in your website that depends on a particular server IP address because, again, there’s no guarantee that you’ll get the same server for an entire session. Cookie handling should be transparent, and the same cookies should be accessible by any of the web servers but again, make sure that any session information is not stored at the web server level. If you run PHP, using the built-in session object is a no-no, it won’t work properly in a multi-server environment. You can use a special server, called a memcache, but your website needs to be designed from the ground-up to take advantage of it. It’s not really something you’re going to drop in at the last minute.
Last is the database server. Running multiple database servers really requires some advance planning, and a website that’s built to handle it. Whenever possible, we try to run everything on a single server and crank it up to “11”. Many ISPs offer virtual machines with lots of processors and RAM. Most database server software, including mySQL, is built to take advantage of all that RAM and processors.
Caching and CMS
Your website may be based on a CMS. And this may present a problem, depending on how your CMS renders pages. Some CMSs have caching built-in, make sure you take full advantage of it.
Sometimes, however, your CMS may not be up to the task. With sufficient advance notice, we move the pertinent pages outside of the CMS, into static HTML pages. We add e-commerce to the static pages via AJAX and tiny, high-performance handlers. These pages can also be aggregated into micro-sites, specifically built to handle the event load. Where possible, this is a technique we like to employ. It keeps us from having to muck about with the main site, and let’s us focus in on each element of the microsite to make sure it’s as fast and efficient as possible.
Content Delivery Networks
If your site has a lot of heavy static assets, like large images, video files and big script libraries, you may want to put a CDN or Content Delivery Network to the task. A CDN allows you to offload these assets and have them delivered to your client via a wholly separate network. Your website doesn’t have to deal with the traffic and many CDNs use a sophisticated array of edge servers that deliver content from the closest server to your users.
Your site needs to be setup to use a CDN but it’s usually just a matter of updating the URLs of your largest assets. Most large ISPs have CDNs and sometimes it’s included in your setup or at a nominal additional charge.
This has just been a brief overview of some of the things we deal with when planning for a traffic spike. Preparedness is the key and it’s best not to be penny-wise and pound-foolish. Plan for overkill on your first few events and then fine tune your setup as you gain experience and confidence. It’ll be money and time well spent. Give a call or drop us a line, we’d be happy to help you get through your traffic event unscathed.