A Basic Cloud Storage vs Local / Disparate Storage Experiment @ NetworksAreMadeOfString

cloud_storage I mentioned a while back that I am working on / experimenting with Cloud Storage and whilst studying the bandwidth graphs / YSlow / FireBug output on one of my websites I wondered if utilising Mosso’s CDN would improve response times / reduce the time Apache spent serving content that never changes.

After some initial experimentation with their frontend app and the API I had moved all the content for one of my project sites to the ‘Cloud’ and (I hope) through to the CDN.

The Setup:

The configuration for the experiment is as follows:
2x LAMP Server [ Core2 1.86GHz / 4Gb RAM / RAID 1 SATA]
1x Static Content Server [Quad / 4Gb RAM / RAID 1 SATA / Server 2008]
1x Mosso CloudFiles account

The first LAMP server is configured with mod_deflate & mod_expires and does the PHP processing / general page stuff, the second is configured the same and used solely to pull email addresses from the database and displays them as a JPEG via PHPGD.

The static content server serves all the PNG’s, Javascript and CSS and is configured with ETAGs and Expires settings.

The Mosso account is set to whatever defaults are configured.

The Test:

Utilising a machine in a remote Datacenter I used ApacheBench with the following settings to hammer the server:
ab -n 10000 -c 100 http://the.testurl.com

The website (including all the dynamically generated images) weighs in at 830Kb of which 332Kb is static content and another 336Kb is text generated by the LAMP server.

The Results:

Unfortunately it seems that the Mosso CDN not only increased the total document size (granted only by 11Kb) but it also suffered from 836Kb/s less throughput.

Round 2

Just to make sure it wasn’t the DB stuff causing an issue (the MySQL process didn’t appear to be a bottleneck but it can’t hurt to check) I wrote a quick page that dumped some of the static images out to a page with a bit of formating. The new page weighs in at 160kb, 4Kb of PHP outputted text and 156Kb of static images.
cdn_transfer_rate_2
cdn_timing_2
cdn_doc_length_2

This time around the CDN beat the throughput of the other tests by 26Kb/s which isn’t exactly ground breaking, the timings are pretty much the same and once again the document size was slightly bigger when using the CDN.

Conclusions?

Mosso has the advantage of being a ‘cloud’ and should therefore never break whereas having a (single?) seperate server for handling static content could result in a very ugly looking website if it failed.

Cost wise Mosso would win as Dedicated servers (such as the Static Content Server) are quite expensive compared to the cost of Mosso at 22¢ a Gb for transfer and 15¢ a Gb of storage on a Pay as you Use basis. Don’t forget that even with Dedicated servers if you go over your transfer allowance then you’ll be paying per Gb too and it probably won’t be 22¢ a throw!

Would I utilise cloud storage? Maybe, but as it stands at the moment using the same Apache instance that processes the PHP configured correctly with mod_deflate and mod_expires seems to do the job just as well.

Criticisms / Notes

Mosso provides you with a URL that cannot be pointed to with a CNAME as it contains a folder (some form of hash) as part of the path. This results in the Mosso URL ( http://cdn.cloudfiles.mosso.com/hash/file.ext ) showing up not only in the status bar but also throughout your source code.

If you happen to change your ‘Container’ from Public to Private and then back again you’ll have a new hash meaning your source code and clients browser caches are out of date.

The mod-rewrite script used for redirecting to Mosso:
<IfModule mod_rewrite.c> RewriteEngine On RewriteRule ^(.*)(file|exts)$ http://cdn.cloudfiles.mosso.com/hash/$0 [NC,L] </IfModule>