The problems that caused the recent issue with the UK Government voter registration website started at 10.15pm shortly before the original midnight deadline on 7th June for registering to vote. Instead of getting a form to complete, users reported a "504 Gateway time-out" error. On the face of it, the issue seems to have been a problem with the physical infrastructure not being able to cope with a sudden surge in users. Every connected user requests information from the server (or actually from one of many servers) and the tipping point would be a combination of the physical memory on the machines, the information being asked for and the number of simultaneous requests. Of course, it's not always easy to predict what peak levels of traffic will be nor it is cheap to have servers on standby just in case they are needed, however there are some things you can consider:
There are a number of questions that you can ask of your developers to ensure that your website is operating as efficiently as possible. If it is efficient, you will be able to handle more users. At a basic level, when a user comes onto your website they request information from your server which is delivered over the Internet to their browser. In its simplest form, this could be an HTML page that is sent together with information about how it should be displayed. The next level up is to request dynamic information from a database or files such as logos or images.
You should check things like the page loading speed and the efficiency of how the code on your site runs. This can be done by asking questions about whether queries are optimised and whether database tables are indexed.
You should also ensure that all the content that is downloaded is not too large. For example, images only need to be the maximum resolution that will be displayed. Having a higher resolution image will simply slow your website down. In some case you can also store information that is regularly requested for a certain time on the server - this is known as caching and will reduce the number of calls on the server. One other issue to bear in mind is calling third party pages in your site. For example if you have social media updates on your site, it's normally better to store a cached version on your local server than connecting to the social media site every time a user visits your page.
The way your infrastructure is set up can have an impact on the number of users your site can serve. Some of these are high level issues such as the choice of datacentre and the speed of connections into it. These days most datacentres offer good service levels but some cheaper ones may not. You should always ask questions of your infrastructure providers about the traffic levels they can handle and how they cope with network outages. You can also look at using multiple datacentres for high volume sites.
Your technical architecture can also affect the number of users. You can improve performance by using a load balancer in front of your servers. This will direct traffic to different servers with the same information on so that you can effectively serve more users. You have a number of options for types of server - shared or dedicated physical servers, cloud based servers or a hybrid model. In most cases, public cloud based servers are still shared with other users. If you are on any shared server you need to consider so called "noisy neighbours." Your site could be slowed down due to another website hosted on your server. You can also consider splitting servers into file servers and dedicated database servers - this is useful for more complex sites with a lot of database calls. This solution can also provide more resilience and work better with a cloud or hybrid setup.
Each server - like a desktop PC - has a certain amount of memory to run functions - RAM. As you probably know from loading programs, some take longer than others and these generally use more RAM. If you open a lot of programs at once, your computer will slow down. It's similar for web servers. The more requests for information, the longer the response and eventually you may get a timeout error or the computer could hang or crash. You can use higher performance machines for busy sites in conjunction with a load balancer.
Know your traffic
Most website adminstrators will have an idea of normal traffic levels and can expect to know when spikes will occur. Dealing with planned spikes is much easier. The most obvious example is concert ticket sites - these normally have a queuing system so that they can cope with demand for popular artists when tickets first go on sale. However the user experience isn't normally that good - a user simply wants to buy tickets and not queue. In order to meet the demand, ticket sites would need more computing power but that could be expensive and there are other limitations such as the pressure on datacentres.
Most websites will not see spikes unless they are trending on social media, appearing on TV or have a special promotion (such as Black Friday) or even an email campaign going out. If you know what your average and peak traffic levels are, you can do load tests on your servers to see if they can cope with extra demand - it's always useful to know what the maximum number of requests or users that can be handled by your site so you can plan for growth.
If you are concerned about large unpredictable spikes, a cloud based solution can be set up to automatically bring new servers online as they are needed. It may sound complicated but once it is set up you know you have the reassurance of being able to cope.
Another major issue is if you are the victim of a Denial of Service attack - these normally swamp a site with fictitious traffic. The main problem here is that you probably won't know which requests for information are genuine and which are not. One solution for this scenario is to use a Content Delivery Network which will distribute content over multiple servers but also monitor where requests are coming from and can block requests from certain IP addresses if they are seen to be involved in DoS attacks.
Cost vs benefit
As with all things, you should consider the impact of your website going down in your particular circumstances. If you have a brochure site then a little downtime will probably just be inconvenient. However if you have a busy ecommerce site the cost of even a few minutes of downtime could be massive.
There is a longer, more technical version of this article on our specialist development website - fabricsoftware.co.uk