Tagged with Review

Rails Host Review – (the good) SliceHost

As I explained in my earlier post berating HostingRails, I built a project for the City of Edmonton’s Apps4Edmonton contest in Ruby on Rails called Alertzy.  In order to make our project live, we needed to find a host for it.  Our initial host fell incredibly flat, so in our second iteration we made sure to perform more research into our available options.  We were initially looking for what I would call a “Rails Host”, as in a hosting provider who gives you an out of the box solution ready for rails hosting.  Under this criteria we found a few potential options, but then we stumbled upon SliceHost.

SliceHost Review

I’ll summarize my impressions of slicehost here:

Pros: Very fast setup, very good performance, very professional

Cons: Start from a blank image on a VPS

Our intention was not to use a VPS provider who didn’t provide an out of the box rails compatible solution.  The reviews for SliceHost, however, were just too good to ignore.  All the reviews which we were able to find for this hosting provider were positive, so we decided we had to give them a shot.

It is important to understand that SliceHost is not so much a Rails hosting provider, as a generic VPS hosting provider.  They simply provide you with a “slice” which has certain performance metrics and a blank OS install on it, and then it is up to you to configure the server to do what you would like it to do.  This has the advantage of complete freedom (SliceHost would prove as effective a PHP host as they are a Rails host), but comes at the cost of configuration.

With our decision to give SliceHost a try, we proceeded to go through SliceHost’s registration and payment process.  Their cheapest slice starts at $20, but we opted to go for their $25 plan which got us 384 MB of RAM, 15GB of storage, and 225GB of bandwidth.  For some reason we flagged something in their system and had to go through an additional verification step.  This process was completed promptly by SliceHost, and our account was online and operational within 45 minutes of the start of the process.  

With our account in place we now had access to their control panel, where you are able to configure your DNS as well as choose an operating system for your Slice and launch it.  The speed with which a new slice comes online impressed me greatly.  From the time of choosing the operating system and launching it, it takes only ~20 seconds before you are ready to start connect to and start configuring your slice.

Unfortunately the next step of this process involving configuring our Slice to run Rails proved to be very difficult.  This was in no way SliceHost’s fault as this process is exactly the same as configuring Rails to run on any system, but the convenience of having a ready made image to use would be an advantage of using another Rails specific host.  The tutorials that I was able to find for configuring Rails to run on a SliceHost VPS were out of date and didn’t work with the more recent versions of Ruby and Rails.  (I will try and put a tutorial outlining my own experiences online in the near future).  I opted to use Capistrano and Deprec to deploy Rails on the new server, and due to the same shifts in versions this proved to be quite a headache to deploy on the Ubuntu 10.04 server we had opted to run.  It took me approximately 10 hours to resolve all the bugs in the deprec scripts to where the deployment could fully run.

Once I had Capistrano and Deprec functioning I was able to deploy our site to SliceHost.  Finally being able to access our site on a good host with great performance was more than sufficient reward for the past day of struggle deploying Rails!  The difference between HostingRails and SliceHost was truly night and day, and we’ve received very good feedback on the responsiveness of our site. 

In conclusion, I had a hard time deploying Rails, but in no way was this the fault of SliceHost.  In everything that is their responsibility, SliceHost has so far delivered either up to, or more often exceeding my expectations.  I intend to use them as my default host for similar projects going forward.  If you would like to check the responsiveness of our site, go check out www.alertzy.com which is running off our slice.

Tagged , , , , , , , , , , , , ,

Rails Host Review – (the bad) HostingRails

I am currently working on a project for the City of Edmonton’s Apps4Edmonton contest.  When we initially started looking for hosts we made the decision that we would use a cheap host for our initial deployment, and then migrate over to something faster when it was justified.  Our site Alertzy is mostly a web portal for people to configure settings for text messages, so we didn’t expect the load to be high.

After looking through the available options, we initially decided to go with www.hostingrails.com.

HostingRails Review

At the risk that some might not read this entire review, I’ll summarize our experience here:

Pros: Friendly, fast support.  Very Cheap.

Cons: Painfully poor server performance.  False advertising on website.  Bad upgrading support.  Outdated support articles.  Blacklisted IP’s for e-mail.

We initially went with Hosting Rails’ Shared hosting option.  For $8 we got 10 GB of space, 100 GB, and migraines.  The initial sign-up process was unexceptional, but things went downhill from there.  We naturally went to Google and searched for articles on deploying a Rails application onto hostingrails.com, and quickly found an article on hosting rails wiki “How to deploy a Rails application on HostingRails.com”.  Unfortunately this article which was the first hit on google is archaically out of date, and we wasted hours trying to get its procedure to work.  We created a support ticket for help with a step of this procedure, and this was our first experience with the knowledgable, fast, and friendly support.  We were quickly straightened out, and started working through the much easier and up to date process in the more hidden article on their wiki “How to deploy a Rails app with Passenger”.  

With this updated procedure in hand and the occasional promptly answered support ticket we soon had our application online (I should point out that this great support response was happening at 4 in the morning on a Saturday night!).  Unfortunately this accomplishment only led us to experience more issues.  It was quickly apparent that the performance of the server just wasn’t going to cut it.  At times the site was snappy, but at other times a page load could take upwards of 20 seconds.  As this is shared hosting some performance variance is to be expected, but this was well beyond acceptable.  

Continuing our deployment (with our fingers crossed that performance would improve once passenger got up to speed), we then worked on deploying e-mail.  I configured SPF and domain keys to try and ensure our outgoing e-mails wouldn’t end up in junk bins, but unfortunately despite both of these passing, our e-mail was still getting junked on gmail.  Having a bad feeling about this I performed a blacklist search on our IP address, and sure enough it was blacklisted.  We created a support ticket, but unfortunately received a very apathetic response:

We can request a removal from the blacklist, but due to compromised accounts and other customers sending spam, the blacklist is almost always reinstated shortly after having it removed.

Being the resourceful chaps we are, we moved our e-mail over to Google Apps, and kept on moving along.  Finally we had our application fully deployed, but had to come to the conclusion that the performance on the shared server wasn’t going to cut it, and that we’d need to move to a VPS to avoid being embarrassed at our site’s speed.  At this point we could have looked at other hosting options, but we had been very impressed with the support thus far and were convinced that VPS would solve our performance problems and we could move on.  

We were very optimistic about the migration to VPS, as hostingrails.com states on their site they are “experts in scaling Rails applications from shared to VPS and multi-server dedicated environments”.  They also state they provide a “Ruby on Rails Image Ready to Roll”, which had all the software we would need pre-installed.  Unfortunately both of these statements turned out to be false.  

After a painful account upgrade process with broken e-mail confirmation links and confusing billing we finally got a server online, only to find that it was a completely blank CentOS install with none of the functionality we had been told would be present.  At this point our shared hosting was already down, so we were understandably anxious to get our site back online.  We sent in another support ticket (about our 5th of the migration process) asking where the stated functionality was.  We patiently waited about an hour with no response, and found that our support request had been escalated to a level 2 request.  Deciding that no response would likely be forthcoming until morning we decided to call it a night.

In the morning we did in fact get a response, but it was not what we were hoping for.  

I apologize for the inconvenience, but the VPS Rails image that was used previously has become very out of date and is no longer offered the image that is currently on your VPS is the standard image all VPS accounts receive

At this point we had had enough.  We picked up our bags and decided to move elsewhere.  This time we did better research before choosing a host, and ended up at Slicehost.  I will do a follow-up post with a review of our experiences on Slicehost once we have been there longer, but so far the experience has been a dream relative to our nightmare with HostingRails.


[update] HostingRails.com has since removed the Ready to Roll image from their list of features; likely do to our experience.

Tagged , , , , , , , , , , ,