Home » Headline, Random

20smoney Server Tests

27 February 2019 No Comment

To test 20smoney.com’s performance, I conducted the following tests:

  1. Monitoring the website’s average load time by doing automated website load time speed checks once per hour for over 10 days.
  2. A server stress test designed to see how your server handles traffic spikes

Here’s what I learned:

20smoney.com average load times

I used GTMetrix.com to monitor the load times of 20smoney.com:

  1. A speed test was done automatically once per hour from a server in Dallas, TX
  2. This was done for 11 days, totaling more than 250 speed tests.
  3. The data from this test was compiled into a chart

The results:

The average load time across all tests was around 3.4 seconds, with only a few recorded spikes to more than 4 seconds.

There’s an interesting Pingdom report that I would like to reference. Here’s a summary of their results:

Note that the above only applies to simple pages (posts, blogs, etc).

What the table above tells us is that if a page takes one second to load, 7% of visitors will choose not to wait and will either close the page or press “back” in their browser to return to whatever page they were previously on.

For a page that takes five seconds to load, the bounce rate is 38%. And so on.

How does this impact 20smoney?

The website currently loads in 3.5 seconds on average. Following the Pingdom report, this is likely causing a 15% bounce rate to the front page.

If the load time could be reduced to 2 seconds or less- which should be very easy to do for a simple blog like 20smoney -then we expect the bounce rate to drop to around 6-7%.

This means that just by improving load times, the website could gain around 8% more traffic, signups, and sales. 

It should be easy to bring down the load time to an average of 2 seconds – a capable developer should be able to do it in a few hours.

The following would be things to try to achieve this goal:

  • Adding Expires headers: right now, the website does not leverage Expires headers, which means the visitor’s browser will attempt to download the same images, stylesheets, and scripts each time they refresh the page or navigate to a new page. This is inefficient and increases load times.
  • Use a Content Delivery Network (CDN): CloudFlare is an excellent choice. It’s free to set up and use for any blog and will produce instant speed improvements. All one must do is create a CloudFlare account, then point their domain at CloudFlare’s DNS.
  • Combining Javascript and Stylesheets:  20smoney’s front page currently accesses 17 external Javascript files and four external CSS stylesheets. Each one of these generates a separate HTTP request, which requires more time to process and increases website load time. By combining many of these files into one, the number of server requests required to load them will be reduced and the website load time will improve significantly. There are free WordPress plugins that do this automatically, such as the Minify + Merge + Refresh plugin.
  • Better image compression: the size of the front page could be reduced by around 5% by applying lossless compression to all the images. A WordPress plugin such as Smush can do this for free.

Traffic spike test results

I configured a script to run a test with 200 Virtual Users (VUs).

What the test did:

  • It sent virtual users to your website over 30 seconds.
  • The users browsed the site (made HTTP requests) for a few minutes
  • The users left the site over 30 seconds.

Test #1 – 200 users:

The blue line indicates the response time of 20smoney’s server.

Response times were at 50-150 milliseconds at first, but when the Virtual Users started visiting the website, it spiked to over 400 milliseconds and then hovered around 350-450 ms for the duration of the test.

The response rate dropped back to below 100 ms after the virtual users left the website.

What this means is that at 200 concurrent users, the website experiences some loading time reduction, but nothing particularly significant.

Additionally, the users experienced some HTTP errors as well. Here’s a snippet:

In total, I counted around 2,000 failed requests (less than 2% of all connections made), the majority of which where server time outs. This means that a few of 20smoney’s website visitors would have been unable to load the website, or it would load with missing images and other important page elements.

Overall, a very solid performance considering the large 200 user load. As seen in my web hosting tests, many of the popular shared hosting providers can barely handle 100 users, and some can’t even handle five.

I then did another test, this time with 150 users instead of 200.

Test #2 – 150 users:

The results were similar, with a spike in server response times from ~100 ms to ~400 ms while the users were active on the site. Response times returned to normal after the users left the website.

The total number of website errors and server time outs was also similar as in the previous test – around 2% of all connections.

In short, I did not notice a significant difference in 20smoney’s performance between 200 and 150 simultaneous users.

What about 75 users?

Test #3 – 75 users:

Server response times increased in a similar way, unfortunately. However, the number of HTTP errors dropped drastically:

This time, I only counted 22 errors instead of the ~2,000 when 150 and 200 visitors were involved!

From this, we can deduce that if approximately 75 people visited 20smoney and began to browse the website, they would experience a 200-300ms load speed reduction, but they would have almost no problems loading any of the content. With very few exceptions, all the pages would load quickly and completely.

I then did another test at 40 users and the response times spiked as well.

It wasn’t until I was down to 20 users that server response times finally became stable.

Results for 20 users:

Here, the server response time did not increase at all when the visitors joined the website – it remained at a flat ~100 MS.

So how does 20smoney handle traffic spikes?

Not bad at all. Even at 200 concurrent users, the server response times remained within reasonable limits, only increasing by 300 ms. The number of server error rates was still low so that the vast majority of users would have been able to load the website correctly.

Comments are closed.