At Redpoint Technologies, we’ve been evaluating many of the services offered by leading cloud vendors in order to better understand where various cloud offerings are most appropriate. Like any technology, it is important to understand each offering’s strengths and weaknesses.

Today I executed some crude performance tests against the Rack Space Mosso Cloud Files offering. This is very similar to the Amazon S3 storage offering. It allows files to be uploaded to the Mosso cloud server where they can be later retrieved. The service offers no minimum or maximum in overall storage, but does limit individual files to 5GBs or smaller, and utilizes utility-style pricing.

Cloud Files optionally allows you to store your content on a content delivery network (CDN). A CDN is an infrastructure of servers located in different geographic locations that work together to rapidly deliver web content to users based on their geographic location. As a result, a CDN can dramatically increase the speed with which content is delivered/retrieved.

Major Considerations

Depending on your needs for uptime, Mosso offers what I’d consider the minimum availability with a 99.9% uptime guarantee for Cloud Files. This means the service may be down about 10 minutes per week or roughly 40.5 minutes per month. For many applications, that is acceptable, but for mission critical situations, this may not be enough.

The following table summarizes many of the considerations and the description for how these considerations are addressed by Mosso.

Performance

For an upcoming distributed, grid-based project, I’m interested in the speed with which I can upload gigabytes of data to a temporary storage location.

The performance of Mosso was decent when using their API, but dreadful when uploading via their web-based interface (but to be fair, the web interface is more for account management and less about use in a production system). The overhead of SSL was surprisingly minimal (as compared to raw FTP - see below as this was not an exact comparison).

I used a 24.9 MB bitmap file as my test file to measure performance for uploading files to Mosso (additional tests around downloading would be worth while testing as well). I tested uploading the test file via the Mosso web interface, using the Mosso API from a .NET application (see the c# console application code below) and to this blog site via FTP to have a non SSL benchmark.

I ran each test several times and throughout the day from my cable modem (which scores between 712 to 2550 Kbps in a browser-based connection speed tests). The results from each run were pretty consistent. On average, it took about 6.25 minutes to upload the 24.9 MB test file to Mosso via the Mosso web interface (control panel), about 3.5 minutes to upload the 24.9 MB test file to Mosso via the Mosso API using the below application and about 3.25 minutes uploading to this (shared .NET hosting) blog site using Filezilla.

The results were satisfying in that my raw FTP upload (to a non-Mosso server) were just a bit faster than the Mosso upload that uses SSL. In my brief testing the service was reliable and I like that the Mosso session could be cached indefinitely in a custom application (unlike the web interface that timed out my session after about 20 to 30 minutes of inactivity).

.NET Test Application

You can use the code below to create a C# console application that will upload a file to Mosso’s Cloud Files service. (Please note that you will need to purchase an account at Mosso prior to being able to run this code.) Prior to building/running the application, you need to add a reference to the com.mosso.cloudfiles .NET assembly that is included in the lib directory of the free download that includes the Mosso .NET sample code. And don’t forget to provide meaningful values for the string values in lines 16, 18, 20 and 22.

Although it would be easy to add an upload timer to the code below, I used a physical stopwatch to capture the time for my upload tests.

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.Text;

   5:  using com.mosso.cloudfiles.services;

   6:  using com.mosso.cloudfiles.domain;

   7:  

   8:  namespace MossoPerfTest

   9:  {

  10:      class Program

  11:      {

  12:          static void Main(string[] args)

  13:          {

  14:              Connection connection;

  15:              // get your user name from mosso at sign-up

  16:              string username = "your-user-name-here";

  17:              // get this from mosso console once you have an account

  18:              string api_access_key = "your-key-here";

  19:              // containers are top-level "folders" for your data files

  20:              string container = "your-container-name-here";

  21:              // fully-qualified filename you want to upload 

  22:              string fileName = @"C:\your-filename-here.txt";

  23:              try

  24:              {

  25:                  connection = new Connection(

  26:                          new UserCredentials(username, api_access_key));

  27:                  connection.PutStorageItem(container, fileName);

  28:              }

  29:              catch

  30:              {

  31:                  Console.WriteLine(

  32:                          "Authentication failed or file upload failed");

  33:              }

  34:          }

  35:      }

  36:  }

Conclusion

In conclusion, you need to be strategic in thinking where you’d use a service like Cloud Files from RackSpace’s Mosso. We would use a service like Cloud Files for storing large files if we could queue them up and upload them asynchronously from our system. Or, perform a synchronous upload if the file was small enough.

From the Mosso’s marketing material, they state that Cloud Files is good for:

• Backups/archives of your data
• Serving images/videos (streaming data to the user’s browser)
• Secondary/tertiary, web-accessible storage for your data
• Well suited when amount of storage is difficult to predict
• Simple point-and-click interface via Mosso Control Panel

But that it is not so good for:

• Native support within your Operating System. It is not yet possible to “mount” or “map” the Cloud Files storage system as a virtual hard-disk on your computer.
• Disk mirroring or backup solutions that require byte/block level differences. There are no concepts of “append” or “file locking” operations within Cloud Files.
• Data can be organized into storage compartments called “Containers”, but they cannot be nested. Since there is only one top-level of Containers, you will not be able to upload a nested directory/folder structures into Cloud Files unless a transformation is performed to flatten the structure.