A few things to watch out for with Rackspace CloudSites

I was pretty excited when I first heard about Rackspace’s CloudSites product.  The prospect of infinite scaling for just $100/month seemed to good to be true (the cost at the time).  It was.

But that’s not to suggest CloudSites doesn’t have its niche.

Here are a few things to look out for.

It’s horrendously slow

We saw rendering times upward of 1.5 seconds (including database queries) on a very simple application that was rendering in .04 seconds on a relatively underpowered and overworked VPS server.  I can go into greater detail about the VPS configuration if anyone’s interested, but I’ll assume it suffices to say that for hosting any sort of moderately sophisticated database-driven application using a RAD framework, CloudSites should be avoided.  Further to this point, we ran the application from an abysmal shared hosting account (of the $4/month variety) during the same time of day, and that saw rendering times around .2 seconds.

No opcode accelerators

We typically compile PHP with APC support when building servers; no option for that on CloudSites.  No eAccelerator or XCache either.

PHP 5.2.13

This appears to be a recent update to the platform (when we first used the product, they were running 5.2.6).  Still, we much prefer running 5.3 (we currently compile 5.3.5 on our server builds).


For smaller projects, we use bash scripts for deployment via rsync.  This allows us to set file permissions, compress CSS / JS, clear cache, and exclude unwanted files with a single command.  Not with CloudSites though.  Fire up that FTP client and don’t make a mistake!

Delicate Media Server / aggressive caching

CloudSites promotes media files (css, js, jpeg, png, etc) to a CDN.  Plan on renaming files if you make updates.  Or setting up a cache-killing solution.

Also, at a pretty inopportune time, all images mysteriously vanished from our site.  I jumped onto online chat for support — I was told the media server was down and would be restored within the hour.  An hour later, no luck.  We subsequently moved all images to a proper CDN (Amazon’s CloudFront).

Damaged databases

Not sure if we are just lucky here, but we have never had a MySQL database ‘break’… until CloudSites.  Suddenly there was a good portion of data missing from the site.  Anything that had not been cached in flat files was gone.  We promptly logged in to the provided PHPMyAdmin GUI and were told that the database had been damaged.  I crossed my fingers and clicked ‘repair’.  Fortunately it worked.  We run scheduled db extracts quite often throughout the day, so it was likely not a huge issue, but just the fact that it happened, for the first time ever, after just a week of using this platform was pretty alarming.

Lost sessions!

This was a big headache… Users reported losing sessions — they would login, browse the site, then after a moment of time, they would no longer be logged in.  Even more alarming, some users reported that they were logged in as different users!  After about 5 hours of digging, we found out that session data is not stored in your home directory, combining it with all other sessions currently being managed by that server.  Okay, makes sense (being generous), but NOWHERE was this documented!  The fix was simple.  Define the session_save_path somewhere within your application.


This is NOT Rackspace support

Part of the reason we made the premature jump to this platform was because of our experience with Rackspace’s support team in the past.  For almost every issue above, our support technician typically left us with “I don’t know, someone will have to get back to you tomorrow”.  That’s never happened with Rackspace support before.  They will typically ride out any issue with you for as long as it takes.  I tried calling the Cloud Servers support group, but they immediately redirected the call to the CloudSites group.  At one point our technician gave us the proverbial white flag and said simply that it was a new solution, and it was not meant for complex applications.  If running a database makes an application complex…

Keeping connected to the server holding your session

One of our first test cases for CloudSites was a Facebook application.  Big mistake.  Anyone familiar with the platform knows Facebook API requests can take a while to complete, especially methods for uploading photos.  Combine that with the horrendously slow CloudSites platform, and you get 4 image upload requests taking about 30-40 seconds.  Problem is that the cookies that tell your request which server has your session data expire in 6-60 seconds (that’s verbatim what I was told; 6-60 seconds).  In order to keep connected to the server holding your session, you cannot have a request take longer than 6-60 seconds.  This required us to refactor quite a bit, sending data back to the browser at 4 second intervals during this execution, which further slowed down application response time.  Worst of all, sometimes single requests would take more than six seconds (like uploading a 45KB image… um…), and the user would be presented with a “no suitable nodes” found error message.

So what do we use CloudSites for?  It isn’t bad for very simple high traffic applications without any sort of database connectivity.  We can run simple Facebook apps off it and not have to worry about the app suddenly exploding in popularity.  But now that Amazon allows you to define index files on S3, I’m not sure there’s any good reason to keep CloudSites up and running.  Especially at $150/month.

In fairness, we have not run anything substantial on this platform for over a year now (can you blame us?!).  Perhaps they have addressed these issues, or at least communicated them to their users.  But just be very careful about putting anything even remotely important on this solution.


Leave a Reply