Rails: Love/Hate

I just realised that I’m split right down the middle when it comes to my opinions on Rails (on Webrick or Mongrel). It’s Ruby affiliation and it’s convention based generator framework is simple elegant and excellent – to the extent that it’s eased me back into the hacking saddle after a 7 year trip around the management wilderness – bereft of the simple ‘truth’ that code brings to one’s life. That aside – my love of rails is perpetually fire-bombed by knowledge that however you want to cut it, it’s single-threaded ! Yes that’s right folks…only one of your controller actions will ever be in operation at any one time ! There are, however,  tentative claims that if you hold your breath, unset a few cryptic, undocumented booleans, then if you don’t whilstle on a Tuesday, it might just let you add some concurrency….so that’s a no then!

I want to love rails more…..but it just won’t let me. You see the fact that it is a single threaded process, taking one request at a time from the underlying Ruby socket stack, sort of makes me start wondering about how such a thing could have come into existence? The concurrency bit is where I’d generally start when developing stuff which is destined to serve clients. Not knocking rails overall, but until this thorn is removed from my side, I’m never gonna find true rails-love!

Currently, server concurrency is achieved by sitting a load-balancer across a group of explicitly created rails processes (mongrel_cluser for example)…..but whilst that is an entirely serviceable concept, it just errodes my perception of this slick framework.  I’m just in disbelief that up to rails version 2.0.1 and mongrel version 1.1.1 it’s still single threaded as a result of not being thread-safe ?!

Advertisements

7 Responses to Rails: Love/Hate

  1. Peter Berkenbosch says:

    Take a look at JRuby, this will give real threads instead of green threads.

  2. Stew says:

    Thanks I’ll take a closer look. Reason I haven’t gone there before now is an assumption that even through JRuby may offer a cleaner threading model beteen the interpreter and the OS, that the application code (i.e. rails/mongrel) is not thread-safe..and therefore coded to avoid concurrency? So moving would hosting on JRuby not simply transfer my rails problem onto a cleaner underlying runtime?

  3. Peter Berkenbosch says:

    true, but when you really need custom multi-threading routines you could write that part in Java.

  4. Stew says:

    Sure thing that’s put more faith in my ideas on ruby applications, but sadly my relationship with rails or ‘the rail’ as it shall now be known, is in need of some counselling.

  5. Peter Berkenbosch says:

    btw, there are a lot of big websites that run on mongrel (cluster) and performing very well.

  6. Peter Berkenbosch says:

    🙂 true, just dive in and you will see that it is self healing 🙂

  7. Stew says:

    I don’t doubt it – the load-balanced mongrel cluster configuraiton is entirely do-able, but the effectiveness just comes down to transactional latency verusus front-end concurrency. If my mongrels are dealing with more than just reads/writes to/from a DB or another atomic resource, then that’s where I start worring. However – horses for courses – I’m still a HUGE fan of this framework but possibly moving outside it’s current comfort zone. Thanks for the input!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: