Skip to main content

Ruby on Rails Hosting: From HostingRails to RailsMachine in a shake of a tail

Rails hosting is a hot subject, and with everyone asking everyone else about their experience, I thought its only fair to share my own experience, even though it is relatively limited.

Introduction

I started with a shared "professional" hosting plan from HostingRails. It was around $30/month, and included non-root SSH access to a shared server, and additional 150Mb of RAM for total of 200Mb (although that's actually quite misleading, see below). I stayed on this plan for about 3-4 months, and then decided to switch to a virtual hosting plan from RailsMachine - their single server plan, for about $100/month (that includes dedicated 384Mb of RAM and a root access to my virtual server). This post describes the reasons behind switching, and compares pros and cons of each hosting plan. Our needs included the following setup:

  • One application running in two instances (one production, and one test)
  • Two-mongrel instances per application (so total of 4 mongrels)
  • Capistrano based deployment / upgrades / restarts of the servers
  • Apache 2+
  • PostgreSQL 8.2
  • Trac (+ MySQL) served over https
  • Subversion repository served over https
  • Subversion post-commit hook linked to a build environment, for continuous integration
  • Automated remote daily backup of the entire environment

To be fair, the plans described here compare sort of like apples and oranges, so the review has to be taken with a grain of salt. Main differences are, of course, in the fact that one is a shared plan and the other one virtual hosting. People on smaller budget and without tight performance requirements will probably prefer the shared plan, while those with a bit more room in the budget and some UNIX know-how will most likely be much happier with virtual hosting. My hope is that perhaps this review will help someone make the right call for their environment based on their needs, budget and experience.

Detailed Comparison

1. HostingRails

  • Pros
    • Cheap, only $30/mo for 4 mongrel instances (200Mb)
    • Easy Trac/SVN install
    • Rudimentary backup can be run from web UI
    • Friendly support staff
    • Timely support, usually within an hour or two
    • Lots of info on forums
  • Cons
    • [Update: please see comments section for HostingRails response]. Slow, slow, and slow. We were sharing a server with 4Gb of RAM with another 50+ mongrel instances run by as many users. The server used over 1Gb of swap space and often showed load averages over 30. We were promised numerous upgrades, which did not materialize while we were using the service. Our sites and Trac at times took over 30 seconds to load the first page, probably while the corresponding process was getting un-swapped.
    • Have to email support for any changes to top-level apache configuration, such as adding domain aliases. This applies to setting up Trac, svn and mongrel apps.
    • Provided backup facility does not backup PostgreSQL/mysql DB, had to write our own script (but forums had a good starting point)
    • Our mongrels clearly were not allocated any amount of "reserved" RAM. Looks like buying extra 150Mb in reality means you can run three more mongrel instances, but has nothing to do with how much RAM you actually get, as was witnessed by swap usage stats.
    • As we decided to move because of performance issues, HostingRails refused to refund us the unused portion of the yearly fee we paid ahead as we were past first 30 days.
    • Locked in their choice of Ruby version, gems, PostgreSQL, MySQL, Trac - can not upgrade these individually, as each is shared among many clients.
Overall, I think that HostingRails has to fix performance issues and not pack as many clients on a single server if they want to be a viable solution for any business. Until they fix performance issues I would NOT recommend this service to anyone. If the performance is fixed, I would recommend this plan to less experienced engineers, who may not know how to use root on a UNIX system, or setup Apache, but have some basic understanding of Rails deployment. I would also recommend this plan on those with a really tight budget.

RailsMachine

RailsMachine provides virtual hosting, meaning you get your own dedicated server with root access. The server, OS and pre-installed software details can be found on RailsMachine website. Because you are sort of expected to use root access, some basic UNIX system administration skills are necessary to take advantage of this plan. However, the flexibility and power that come with this solution by far outweigh the additional $60/month we are paying for our own box. Note that we could pay only $75/month for 256Mb of RAM, but considering the list of applications we wanted to run, I chose to upgrade our plan to at least 384Mb.

  • Pros
    • Much, much, much, faster. When using command line, sometimes you see server "hanging" momentarily while presumably other virtual machines are being processed, but the overall performance improvements are quite dramatic. Pages (trac/mongrel) load within 1-2 seconds consistently.
    • Fantastic provided Apache configuration, comes with plenty of dynamically compiled modules, template config files and modular structure. Our single apache server is providing umbrella access to both mongrel apps, SVN over https and Trac over https (using mod_wsgi, not CGI).
    • RailsMachine gem allows seamless initial capistrano deployment and subsequent installations
    • Apparently each virtual server is backed up automatically (but we do our remote backups anyway)
    • CentOS Linux provides convenient yum utility for installing pre-built packages. Sometimes it takes a few minutes to find the right package using "yum search" but once found, installation is a breeze.
    • Root access allows installing what you need for your environment, eg - latest PostgreSQL, latest Trac, etc. Was able to install mod_wsgi module to enable much faster Trac access than using traditional CGI access.
    • Our entire setup described above takes up 180Mb of RAM, with another 180Mb left for file system caching. Pre-installed MySQL and Apache are built with multi-threading enabled, so the processes manage their shared RAM very effectively. This means we have room to add another 2-3 mongrel instances to the setup without affecting pricing of our plan.
    • Responsive, knowledgeable support, although just the nature of the setup means you have to ask a lot LESS questions if you know what you are doing, since you can get most of the things installed yourself without bugging them.
  • Cons
    • [Update: this has been fixed, see comments section] The server came installed with broken permissions on /etc/resolv.conf and /etc/hosts file. This broke host/domain name resolution from the host itself, until the permissions were set to allow read access to the above files.
    • Slightly more expensive.
    • Occasionally (but mostly rarely), shell access has a latency that appears to be CPU bound by the physical server and not the network.
Overall, I would absolutely recommend RailsMachine to a technically savvy engineers, who want freedom of their own box at a very affordable price. Ability to grow the size of the virtual box dynamically is also great - it's very nice to know that when you need extra 1Gb of RAM, it's there waiting for you (and your wallet).

Install Notes

A quick note about SVN/Apache configuration with authorization turned on. This has been mentioned on many SVN forums, but if you are setting it up, please be aware that mod_dav_svn contains memory leak that makes apache seg-fault during checkouts of a large repository tree (we are using authorization as well as authentication). I had to add the following clause to apache config for SVN directory to resolve to issue: SVNPathAuthz off This is what our SVN configuraiton looks like in case someone is looking for a complete config:

<VirtualHost *:443>
 ServerName svn.YOURDOMAIN.com

 SSLEngine On
 SSLCertificateFile /etc/httpd/sslcert/server.crt
 SSLCertificateKeyFile /etc/httpd/sslcert/server.key

 <Location />
       DAV svn
       SVNPath /var/lib/subversion
       AuthzSVNAccessFile /var/lib/subversion/conf/authz
       SVNPathAuthz off

       AuthType Basic
       AuthName "Authorization Realm"
       AuthUserFile /var/lib/subversion/conf/passwd
       Require valid-user
 </Location>
</VirtualHost>

References

  1. Memory Leak in mod_dav_svn

Closing Notes

Here are the responses I got from HostingRails and RailsMachine - thanks guys...

Hi Konstantin, The issue with broken permissions on hosts/resolv/others has been fixed. It was due to a small (and short-lived) bug in our provisioning system. Thanks for mentioning us! -Rob at Rails Machine
Hi Konstantin, there’s a couple things I’d like to point out that I hope you’d be willing to correct in your review. I understand that you had a bad experience with us and respect your right to voice it.
  1. Running a cluster of 4 Mongrels will only cost $22/mo on our professional plan, and $26, $32/mo on our business and platinum plans, respectively.
  2. On our site we outline that we’re selling (physical + virtual) memory in blocks of 50MB on shared servers — when Mongrels or Static FastCGI instances are fired up they consume (’reserve’) these resources persistently.
Overall, and I suppose you’d have to take my word for it, your server ran into an unfortunate resource situation with a number of users who are now either suspended due to malicious behavior or upgraded to dedicated environments due to extraordinary growth of their apps. Most of our clients are having good hosting experiences with us and we’re working hard to maintain fast and reliable shared servers for Rails deployment at the lowest possible price. All the best, ~William at HostingRails

-- William, thank you for your corrections and I appreciate that it must not be easy to maintain quality service at such a competitive price. I’ve updated the pricing I mention and added a reference to your comment. I am willing to believe that our server may have been exception rather than a rule, and I hope that in the future you have a way to move clients off loaded machines quickly.

Comments

Anonymous said…
I just got a HostingRails account, and I agree with your assessment of their performance. The support staff are knowledgeable, but I thought they were quick to direct me to an online tutorial when they could have given more direct assistance. Even after I paid an extra $100 for them to deploy my app, aspects of the site aren't working, and they still direct me back to the online docs. I wouldn't recommend them.
Anonymous said…
I would recommend Hostingrails. I have now three rails apps on a single hosting for just about 4 dollars a month. They are running fine, especially for the price you pay. When traffic grows, it seems really easy to upgrade a plan. Also, the support is quick and helpful, and the crew responds to messages posted in the forum quickly too. I think those guys do a great job!
Anonymous said…
Can't recommend hostingrails either. I've got 4 accounts there.
To many downtimes (upto 2 hours) - at least once a week. use it as a playground, and move to something else when going productive
Unknown said…
If you're looking to jump ship and reliability is critical to you, then check out RailsCluster. The platform is fully redundant, twice as fast as other Ruby on Rails hosts and has an availability of 99,8%. Rack applications such as Merb are supported as well. There's a free 30 day trial available too. Check it out at http://en.railscluster.nl.
Anonymous said…
Dear William and other HostingRails Folks:

I had started with your free plan, and couldn't complain about the responsiveness because of the price. When I upgraded to a paid mongrel-capable shared account almost a year ago, you moved me to another server with much less load, and initially the responsiveness improved substantially.

However, as time went on, I began to see the same intermittent but frequent slowdowns and a few downright outages as I had on the free plan. Even my Mongrel-based Rails app would respond slowly at times.

The site monitoring service at siteuptime.com started testing my Mongrelized Rails app on HR by sending HTTP requests every half hour since mid-October. The reports I received indicate that there were multiple "failures" (generally at least 10 in each 24-hour period) intermixed with successful connections ON ALMOST ALL IF NOT ALL DAYS since October. When I personally attempt to connect, I generally get through, with some delay, so I suspect that these "failures" are mostly due to slow response and not actual downtime, However, this service has been monitoring a GoDaddy account (admittedly serving a static page) also since October, without a single failure report. And siteuptime.com reports 100% uptime regarding the same app under FastCGI on RailsPlayground since it was started on January 16. (The responsiveness of the app on Railsplayground is also significantly better than on HostingRails when I personally access it.)

Against this, I have had occasion to contact HR support a few times, and the response has usually been fast and helpful. Unfortunately, this can in no way compensate for an inferior service. So with regret ...

Sayonara,

Edwin

Edwin $AT$ Pictolink $DOT-COM$
Anonymous said…
Two years later, I have to agree with the comments about the performance on HostingRails. They're nice guys but the shared plans just royally suck.

Right now, at 9pm PT at night (hardly a peak usage) the server load is 13. It looks like we're clearly IO bound (CPU 91% idle).

They move you around periodically but they always allow the performance to degrade. They should just do away with the shared service option. It might work for static content, but RoR is far from static.

Even it it was free, what good is a service that takes a minute to load? No one but your mother will use it.
Anonymous said…
Rails Playground:

VM with root ssh
All network ports available
Several different Linux distros to pick from
20GB storage
512 MB RAM
200 GB bandwidth
SVN/Git/trac
40 Domains/Unlimited Subdomains
unlimited clients-yes you can set up a mini-hosting service
lxadmin

You have 4 2 Ghz quad-core and they don't seem to load too many VM's as performance is almost always good. Although it seems to slow down at midnight for some reason.

Outstanding service, they always get back to you quickly and have the issue fixed, even if it was your fault.

All this and more for $30.

No I do not work for them, but have been a customer for a few years now. I am ready to move on with my own server, but I can't recommend these guys more.

No other rails solution is as solid, except for EngineYard which is considerably more expensive.

Popular posts from this blog

Car or Auto Make-Model-Year Database : For Breakfast

Make Model What? If you like me were tasked with loading a database of recent car makes/models/years, you would start by looking on the web and seeing if someone else just has it out there, readily available, hopefully for free, but perhaps for a tiny nominal fee.? If only it was that simple... I looked and looked, and couldn't find anything that would fit the above requirements. So I thought, who would know about US car models better than Kelly Blue Book? So I went on their site, and sure enough they have a javascript file that lists all known to them makes and models of used cars. Since the file is public, I figured it's not really "evil" if I scrape and parse it for my own benefit. Disagree? Have a better source? Then leave a comment. Anyway, to cut the long story short, I'm hoping to save a day or so to someone else who may, like me, be looking for this information. The ruby module shown below retrieves and parses the javascript from KBB site into

On Ruby on Rails with PostgreSQL, and Acts as Paranoid

Back a few years ago I was researching differences between PostgreSQL and MySQL databases, and chose PostgreSQL because at the time it supported foreign key constraints and many other fantastic SQL extensions that make developer's life a lot easier. Today I am sure MySQL is just as functional as PostgreSQL, and it does appear to be a more popular choice as the Rails DB than MySQL. I still prefer PostgreSQL, it just feels more natural to me coming out of Oracle background, so I am probably biased (who isn't?) Anyway, in the last year and a half or so, I've been writing Rails apps that use PG-based databases and found a few random tricks I'd love to share here. Opinions differ here, but just like accountants like the ancient double entry accounting system, I personally prefer a double validation system - where Rails validates my objects before/after updates, but the database double checks this using proper constraints. Rail's validation system is very robust and exte

Getting RMagic and friends to work on OS-X Mountain Lion

Upgraded my ruby environment today to Mountain Lion. Here is a quick checklist that I went through to get everything working.  The largest change was having to reinstall XCode and command line tools, and also download XQuarts in order to reinstall ImageMagick successfully. Without it, I was getting errors building RMagick of the following shape: ld: file not found: /usr/lib/libltdl.7.dylib for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [RMagick2.bundle] Error 1 Quick checklist: Install Mountain Lion Install XCode 4.4 Install command line tools from XCode 4.4 Preferences dialog Install XQuartz In terminal run brew update brew uninstall imagemagick brew install --fresh imagemagick wipe out your ~/.rvm folder reinstall RVM and install the latest ruby 1.9.3-p-194 run "bundle" in the project folder run "rake" and rejoice References: https://github.com/mroth/lolcommits/issu