RoRLearn.com Home News Articles Tutorials Resources Books Forums
 

Home>Articles>

PHP vs Ruby on Rails, Part 3

 

In part 1 of our series we explained how PHP is just a language, not a framework; in part 2 we talked about RubyĄŻs object-oriented foundations and its cool iterators. Today we are going to finish our series with some thoughts on deployment. More specifically, we will discuss why deploying a Rails app is a little harder than PHP.

If there is one thing that has me down on Rails itĄŻs deployment. When I say deployment I donĄŻt actually mean the act of uploading a new release. ThatĄŻs actually very easy to do with a tool called Switchtower. No, IĄŻm talking about using a shared-hosting provider. Dedicated hosts are easy to get going with Rails, but when you are using a shared box there is a little more to take under consideration. Let me explain.

The first reason why shared-hosting environments are tough is simply because Rails is still so new. PHP was the same way when it first started getting popular. These days however, IĄŻd be shocked if any shared-hosting environment didnĄŻt offer some level of PHP support. The second reason is because running a Rails application properly requires more resources and power given to the users on that shared box. Because of this most system admins of shared-hosting setups are rightfully cautious.

I canĄŻt say I know exactly why Rails needs so much more Ą°oomph.Ą± The big thing to keep in mind is how most CGI environments work. The web server will normally build up the environment for the CGI, execute the code, return the HTML that was built to the client and then destroy the environment. It does this every time a request comes in. Now, it could be that Ruby is a little slower than PHP, but I suspect the main bottle neck is something else. If I recall, Rails inspects the database to help build the models it will use. Doing so every time could easily add a lot of overhead and thus cause a slow down. Anyway, without getting too specific(for I know not what I speak, err type), Rails is really slow when run under CGI. To speed things up we need FastCGI!

In a production environment, most Rails applications are being run under a thing called FastCGI. The main benefit of running Rails under FastCGI is speed. FastCGI will load and hold your app in memory so that it doesnĄŻt have to build the entire environment per request. The negatives of FastCGI include extra CPU and RAM usage. On a box that might be shared between a hundred or so accounts itĄŻs not hard to imagine how this might cause some problems.

Thus Rails on shared-boxes sounds bleak, but there are companies out there advertising such services. Now, most hosts on that page mention monthly fees so low itĄŻs scary to think about how bad the service might be. For those not interested in playing web host roulette, letĄŻs talk a little about the most popular of the shared-hosting + Rails setups, TextDrive.

I have no personal experience with TextDrive, but my biggest concern with them is reliability. They sell themselves as a company with bleeding edge technologies, and from what I read on their forums and third party blog posts, they tend to bleed regularly. I suspect lots of people are/were signing up for their $12/month plan, using it as a development server and constantly breaking things. I also suspect that the company continues to have growing pains. Perhaps, as they get more comfortable, and Rails more stable, things will get better. Another thing that might help is the fact that TextDrive is introducing Business Hosting Plans which promise Ą°an average of only 20 customers per high-end storage-attached server.Ą± The less crowded servers will more than likely have much better reliability ĄȘ weĄŻll see.

IĄŻd would just be thrilled if Pair started to support Rails. IĄŻve been using Pair for a few years now and love their service. I also loved the chocolates they sent me for Christmas.

When it comes to the Clickable Bliss site, IĄŻm currently using Pair for DNS+Email and pushing all web traffic to Zelda, my little Mac mini server. ItĄŻs working quite well so far, but with only myself and a dozen or so friends hitting the server on a regular basis there really isnĄŻt all that much to do. In time I may move to TextDrive or a similar service. I have a feeling over the next 18 months weĄŻll see a huge increase in the number and quality of hosting providers offering Rails-application hosting.

ThatĄŻs the skinny on deployment for small (shared-hosting sized) Rails applications. ItĄŻs a little tough right now, but I have a feeling it will get better soon. For those interested in launching bigger apps on dedicated hardware, donĄŻt blink when it comes to Rails. It is as easy (or easier) than what you have previously used.






 
Site Copyright © 2006-2007 RoRLearn.com All rights reserved. Privacy Policy | About Us | Contact Us | Site Map