Playing with More Server Architecture Optimization

Screen Shot 2015 03 18 at 9.55.28 AMThe Rapid Access Cloud offers test cloud infrastructure to anyone in Alberta with a spark of an idea, but without the resources to test it out digitally. Cybera began offering the  Rapid Access Cloud in 2013 to provide Alberta-based academics, researchers, non-profits and small to medium sized organizations with uninhibited access to cloud resources for up to one year.

We offer Object Storage on the Rapid Access Cloud, and were interested to find out how much of a difference it makes in terms of performance for a file sharing style web application.

To find this out, we simulated a large amount of traffic downloading a collection of variable-sized files. The results of these tests can then be used as a guideline for production traffic scenarios.

Test Details

The tests were run using a HTTP benchmark application called siege. Cybera ran this application with a list of URLs that linked to 2GB of different-sized data (which was sourced from a public NASA data set hosted locally on the Rapid Access Cloud). In order to emulate production traffic, we used siege's delay feature to add random delays between requests. This way the connections per second can be compared to active users using the site at that time. No optimizations took place on either the web server (Apache) or the object storage service – they both used "out of the box" configurations.

Resources monitored during the tests included: successful hits, completed transactions per second, and throughput. The status of the latter two resources were particularly important as the random delays were ramped up to 30 seconds, to make the traffic more realistic (the successful hits were less important, as it'€™s not unexpected to see tests where more connections buck the trend of a lower amount of hits).

We scaled up the number of active connections being made to help compare the differences as loads increased in the varying scenarios.

Results

Please see the Rapid Access Cloud Web Hosting (PDF) for the numbers and graphs for these tests.

Tests

Object Storage (Direct)

This test was done to determine the number of requests one could see using the Rapid Access Cloud's object storage without any optimization.

for i in 10 20 30 40 50 60 70 80 100; do
   echo "${i} connections"; siege -i -t5m -b -f objectURLs.txt -d 30 -c ${i}
done

Redirect to Object Storage

This test was done to determine the number of requests one could see by sending requests to a web server that would then redirect to backend object storage.

for i in 10 20 30 40 50 60 70 80 100; do
   echo "${i} connections"; siege -i -t5m -b -f blockURLs.txt -d 30 -c ${i}
done

One caveat with this test is that the reported numbers are doubled, as they represent both the redirect and the file transfer. The hits and transaction numbers recorded have been halved to focus on just the file transfers.

Standard Web Host

This test was done to determine the number of requests one could see by running Apache on virtual machines configured two ways:

  1. Apache: 4 CPUs and 8GB RAM

  2. Apache 16: 16 CPUs and 16GB RAM

Both types of virtual machines had the file stored locally on the local hard drive.

for i in 10 20 30 40 50 60 70 80 100; do
   echo "${i} connections"; siege -i -t5m -b -f blockURLs.txt -d 30 -c ${i}
done

Conclusions

After conducting these tests, we reached two main conclusions:

  1. Both of the tests that utilized object storage showed consistent results across the board. This highlights the advantages of Object Storage without needing to optimize; the system scales incredibly well.

  2. The results of the Apache and Apache 16 tests followed a similar path to each other. While the Apache 16 tests were able to produce higher results, they were only slightly above the Apache tests. This is particularly interesting as the Apache 16 tests contained 12 more CPUs than the regular Apache tests (which only used 4 CPUs). We can therefore conclude that simply increasing the number of CPUs in a single server does not scale linearly.