Satya's blog - PHP and Ruby on Rails compared

Nov 19 2008 08:02 PHP and Ruby on Rails compared

I received an email asking about differences between PHP and Rails. This is my reply. It has been cleaned up a little. It is not comprehensive.

Both PHP and Rails address the same domain: making dynamic web sites, in different ways. PHP, at heart,is a language that embeds itself in your HTML document. Now, it's OOP-ness and other things (such as template libraries) make it much more than that to the point that people forget what it is, but still. In Rails, the HTML page generation happens at the end of the request-response cycle....

Both are pretty newb friendly. I believe it's easier to write bad programs in PHP than in Ruby, though.

At this point I'd like to point out that Ruby is a programming language (notice I didn't say "web") and Rails is a web programming framework (notice I *did* say "web"). I point this out because people at work are always confused. And in the above paragraph, I compare PHP with *Ruby*, not Rails. When you build a RoR web site, a lot of the programming you do is in Ruby, hence the comparison.

As for function and speed: Rails, being Web-oriented in a Web 2.0 world (that means AJAX and dynamic HTML tricks are the norm rather than an exception -- and they're not to be used gratuitously, but only where needed -- and since many browsers are in Web 1.5 (I make that up) or earlier, AJAX should not be a necessity, which means it should be added on, not be the primary way to do things. As a general guideline, which I freely violate in controlled conditions. Professional programmer, closed subnet. Do not attempt.)

Ahem. So Rails has full and easy AJAX support, which means AJAX-y things are easy to do. You might be able to find code libraries in PHP, I don't know. Rails makes it really easy, though. It uses the MVC (Model View Controller) paradigm, and the View part is usually HTML, but it could be Javascript or XML, too. That's where you get half the AJAX functionalitiy.

(Not in the original email:) Rails includes the prototype and scriptaculous javascript libraries, which make AJAX and DHTML tricks very easy.

You may not need to do much AJAX anyway. I see your question stems from trying to speed up a potentially slow Rails app. Where did you hear that Rails is slower than PHP? It could be, but let's examine the bottleneck areas and comparison points:

PHP usually runs as a module of your web server (Apache). That makes the PHP interpreter pretty fast. Rails usually runs off mongrel or something else, which Apache has to proxy to. Apache is a decent web server, having it in front of your Rails server is a good idea. You can remove this bottleneck by running multiple mongrel processes for your Rails app, and have Apache do a load-balancing proxy. This is quite easy to do. Apache config:

    <Proxy balancer://yourapp_cluster>
        BalancerMember http://127.0.0.1:8290
        BalancerMember http://127.0.0.1:8291
        BalancerMember http://127.0.0.1:8292
        Order Deny,Allow
        Allow from all
    </Proxy>
    <Location /yourapp>
        RewriteEngine On
        RewriteRule ^/(.*)$ balancer://yourapp_cluster%{REQUEST_URI} [P,QSA]
    </Location>

(Mongrel listens on the ports in the BalancerMember lines.)

Now, mongrel does take memory, being a separate process. It's not so bad, though. You don't need huge resources, but I wouldn't run a Rails app, or much more than 1 or 2, off a virtual machine.

Speed of actual code: I can't compare. Of course, if you write an O(N^2) sort algorithm, you're screwed either way. (Hint: both PHP and Ruby provide sort functions, but this is only one example).

Database connection: This is likely to be the worst issue. Rails presents your database (DB) in an object-oriented manner, called Object-Relation Mapping (ORM). An ORM is usually pretty chatty with the DB, always asking for table descriptions and so forth. A lot of that can be optimized away, if you're reasonably careful about indexes, eager loading, and how you do your algorithms. Judicious use of periodic database maintenance scripts can help, too, by generating cache tables.

You're trying to optimize prematurely, as you've guessed. I believe Rails can support a pretty busy PBBG, depending on how busy each page is going to be.

Rails is used best on a server where you have shell access. You can set up a development environment on your Windows box, but you'll need a database. MySQL is recommended. For actual use, i.e. production, I recommend a Linux server, Debian preferred, where you have root access. Linode and csoft can give you virtual machines. Despite my earlier injunction against one, initially you can use a VM. If it gets busy, you can switch to dedicated hosting -- if you can make money off it.

Rails development happens with it's built-in web server, Webrick. Once you start it, (./script/server) you connect to http://localhost:3000/ . That's localhost port 3000. Do NOT use that for production.

Oh, if you want to try Linux for a home/development machine, grab an Ubuntu LiveCD: https://help.ubuntu.com/community/LiveCD

Last updated: Nov 20 2008 20:36

Tag: geeky rails