The importance of how your website is performing can not be stressed enough. If your site is slow and the pages build poorly it will have a direct affect on how successful your business is. If your site returns error codes because it is suffering from requests that time out it is catastrophic. Your clients will become angry, frustrated and will give up on you and go to your competitors. The correlation between website efficiency and success is clear. Today I want to show you, in graphic detail, what happens as you succeed in gaining increased traffic but aren’t prepared for it. This is why it is critical for you to monitor and test the amount of traffic your website can handle and handle well.
In the following case study we are looking at John’s website. He is in business as a photographer and his website is chock full of examples of his work for future clients to see. His main strategy is to attract customers from his visual display. He is preparing to launch a series of newspaper advertisements focusing on couples planning their weddings and is expecting a significant rise in the number of potential customers coming to his site. He knows his current traffic level is light and his site is building pages quickly (2 seconds per page) and he wants to make sure he can handle the expected upcoming traffic increase. He is expecting a surge in traffic from his current maximum simultaneous visits of 5 to at least 20 and possibly as high as 50.
In the first test he sets the parameters for 20 simultaneous virtual users and he is immediately worried when he sees the results. In the report below you can see that his normally quick website is already very negatively impacted by increased traffic levels.
You can clearly see how with just 20 simultaneous service requests the page build times are taking quite long. Remembering that the optimal page build for ecommerce sites should be 2 seconds you can see that already, only a small minority of the pages are building at that rate. It is scary to see that even with this low traffic level surge most of his clients will experience slow response times from his website, see the table below, with an average page build of 6.323 second (3X the optimum).
The only good news from the report is that all of his clients are eventually seeing his site. As you can see from the report page below the bandwidth consumption and throughput are steady.
As we run the test a second time we stress the website with 50 simultaneous virtual users. Given the result of the first test we clearly do not expect to see anything better but we will see how bad the level of service will become. Comparing this to the previous test results you will see that the page build times have deteriorated to the point where only 2 of the attempts performed at optimal level and the vast majority of clients would now be seeing very poor service.
As we drill down further into the detail, you will see from the report below, that the average page build time has now gone from the 6.323 seconds of the first test to an extremely bad average page build time of 14.547 seconds with some poor clients actually seeing much worse with a maximum page build time of 37.407 seconds. His customers surely would abandon his website and go searching on his competitors site for their purchases.
In the final report below you can see that his bandwidth utilization and his throughput have now started to show very degraded performance.
Our example here, John’s Photography website, is a very clear demonstration of why you need to test and stress and monitor your website. Even in a relatively small and non technical business, if you don’t pay attention to these details you are bound to not only have annoyed customers, you will have markedly fewer customers (and thus less business and revenue). Now that John has run the tests and sees that his website will not perform well under a heavier load he needs to decide what are his next steps. As his site is hosted elsewhere he can make a pretty strong assumption that the issue is not a bandwidth problem but in all probability he will need to upgrade his package with the hosting company to gain faster processing power. As John is not a “technical” user this is the logical step for him to follow and then to rerun the tests a final time to make sure he gets the results and performance he needs. If we change the case study just a bit and assume that John is hosting his own site then he will need to install some additional monitors so that he can drill down to where the specific issue is within his server.
The good news for John though is that he discovered a problem before it truly became a problem. By doing this he is in a good position and can take steps to prevent his users from ever experiencing slow page builds and poor website responsiveness. By running a quick, simple and inexpensive test John has protected his business and can now get back to taking pictures.