It’s Nearly Christmas!
Christmas is traditionally a peak time of year for online retail (if Christmas isn’t your peak, the following advice still applies for your own peaks), but the question is: are you ready?
You should be. It’s not far away now and it’s important that you’re prepared. The rest of this article is going to be a little technical, but I hope you follow the theme and can direct the appropriate questions to your techie people.
First port of call should be to explain why this is important (it should be obvious). Consumers have high expectations these days. They expect your site to work and respond quickly. If it doesn’t, chances are Google (and thus a competitor) are just a click away. Worse still, if your site doesn’t respond at all that’d be even worse for your image.
Capacity
Peak periods mean more traffic. If you’ve been doing everything right over the last few months and following some of the excellent advice found on this site, you’ll no doubt be in a position to expect a flood of traffic. Your own individual sectors will have varying level of spikes, but to give you an idea of what to expect; the company I work for usually sees a four fold increase.
Of course when it comes to proper planning, if you “expect” a four fold increase based on your analysis of your market and history and you scope capacity to manage that increase you may end up falling short if you underestimated. Make sure you’ve got enough run off to handle anything unexpected.
It’s important to remember that the servers that run your site will try to serve every visitor. Every request it’ll try to handle. This means if the server struggles it’ll be slow for everyone.
Whatever your expectations are, your hosting provider should be an ideal place to start in terms of bracing your site for the impending traffic. I’m sure I’ve mentioned this before, but this is where working with a good hosting company reaps dividends.
Testing
Armed with a good idea of what kind of load you’re expecting, you can begin testing your environment. It’s a good idea to get some kind of server monitoring solution in place before running a test as it’ll allow you to get a picture of where the bottlenecks are. Munin is an excellent option for those of you running on Linux based servers.
With monitoring in place you now need to simulate load on your server and observe behaviour. Personally, I use Apache Bench (referred to as “ab”) but equally useful is Autobench. Once you’re able to simulate high load on your server and can see the effects it has you’ll be ready to target and fix any problems areas.
Server Efficiency
I mentioned in a previous article about securing your ecom site about services running on your server(s). If there’s anything running on there that you don’t need, it’s eating resources. Stopping those services frees up resources your server can better use serving your customers.
Speaking of resources, hands up if you’re using Apache to serve your customers. Despite it’s massive popularity it may not be your best choice. Nginx is an excellent web server that’s lighter on resources than Apache. I’m not suggesting you drop everything and switch web server! The Apache/Nginx example is purely to serve a point: have you checked all your options? There is of course a technical cost to switching to a different tech (be it database, web server, or even something in the software level like your chosen blog CMS or framework) so please don’t shoot me for that. In contrast there’s also a cost to throwing more server resources at your traffic problem – finding the right solution is of course down to your own circumstances.
By ensuring your site is running on servers that have the maximum amount of resources available combined with services built for capacity/speed you’ll be getting the most bang from your buck. Just remember from the “capacity” section above, efficiency should not compromise capacity or all your efforts will be for naught.
Servers (Number of)
If you find your current server isn’t capable of handling your expected load you’re looking at two options: scale up or scale out (or even both). Scaling up is essentially “get a bigger server”. Scaling out is “get another server” and then share the load across the two. Scaling up is almost always the easiest option and potentially cheaper too (to an extent), but it doesn’t solve your problem long term. Remember, when you buy a bigger server to scale up, it’s not so easy to scale it down later. Scaling out can have additional upfront costs (load balancing, technical changes to your site) but, in theory, is the best option for long term growth. It’s also flexible; busy = more servers, quiet = less servers. Of course if you’re not running open source software be aware that more servers can mean more licenses and the costs that come with that. Again, a good hosting company can help you explore your options here.
Application changes
Assuming you’re still with me you’ll want to move up to the application level: your website. Ingmar wrote a great article covering page speed here. To a large extent a quick site should also be efficient. Following the advice in this article will help get the most out of your hardware. One thing to be conscious of here is the section on compression: compressing does require additional CPU from the server. It’s a trade off that normally favours compression, but be aware and check for yourself.
One element mentioned in the article I’d like to expand slightly is the use of a content delivery network. It’s true that by using a CDN you’ll speed up page load as less requests on your server means less content is being “blocked” by other content downloading first, but there’s another advantage: your server(s) aren’t dealing with those requests. All those static files being handled by your chosen CDN are files your servers aren’t having to handle requests for thus reducing load.
Conclusion
It’s not always possible to predict how much traffic you’re expecting, but by preparing your site as best as you can you’re reducing the chances that your customers will have difficulty ordering. You’re also ensuring marketing spend/effort isn’t being wasted by a site that takes forever to load or even load at all.
Christmas bonus!
An extra little bonus point to make. If you’re a developer or anyone else inclined to be making last minute changes to your site before a peak period stop right now. It goes without saying that if your “minor tweak” manages to accidentally break something important (we’ve all done it once) then your customers will be less than pleased, so too will your boss. If you absolutely have to make a change, then obviously do – but make sure you’ve got a rollback just in case!
