Why RoR over PHP Framework?

Hi,

I’m playing with RoR since Ruby 1.0, now I’m playing with 3.2.

I have to merge/rewrite one ERP from standalone app client/server to web
approach.

Some of this part is made with PHP, but this part is not the most
important, and there is an option that we can rewrite it to other tools
like RoR as some parts have to change.

The main question is why I should choose RoR over other framework PHP
like Kohana or Yii.

I don’t want to start a fight here, I want to ask very specific
questions:

  • Is it true that a slow queriy on RoR lock all other concurrent
    connections? This was true on old RoR versions.

I usualy have my RoR served by Ngix with Thin.

Apahe can serve PHP directly.

This extra layer (Thin, mongrel,…) has some penalty on RoR ?

I know I can have many Thins servers listening and Ngix uses them by
demand, or use Passenger, Unicorn, … but those options are slowering
the web in comparation with Apache and PHP?

I prefer to use RoR but I have to convince the other programmer and my
Boss, both of them prefer Php because sound better, there are more
developers, bla bla bla

Of course the best is what I’m doing, creating a RoR and Kohana web tot
test this very specific questions, but it’s aways good to ask and read
from profressionals like you :slight_smile:

thanks,

Raimon Fs wrote in post #1047848:

  • Is it true that a slow queriy on RoR lock all other concurrent
    connections? This was true on old RoR versions.

This could be true in many cases, but is this really different from PHP?
Does PHP handle requests concurrently? I’m not really sure about that.
All the “intelligence” in wrapped up inside that Apache module and
there’s generally only one of those.

In any case, chances are highly likely that you’ll never have to worry
about this. Slow queries are almost always the result of bad design.
Rails and the techniques used by Rails developers provide a multitude of
solutions to this problem, without resorting to concurrent request
processing. In many cases not having concurrent processing simplifies
the app, resulting in increased stability and few hard to find bugs.
Threading is damn hard, as anyone who has had to deal with it will
confirm.

I usualy have my RoR served by Ngix with Thin.

Apahe can serve PHP directly.

Apache does NOT serve PHP directly. It forwards all requests to the PHP
module for processing.

This extra layer (Thin, mongrel,…) has some penalty on RoR ?

This is not an extra layer. It’s just in a different place.

I know I can have many Thins servers listening and Ngix uses them by
demand, or use Passenger, Unicorn, … but those options are slowering
the web in comparation with Apache and PHP?

I prefer to use RoR but I have to convince the other programmer and my
Boss, both of them prefer Php because sound better, there are more
developers, bla bla bla

Convincing your coworkers and boss is not something we can help you
with. That’s all on you.

Of course the best is what I’m doing, creating a RoR and Kohana web tot
test this very specific questions, but it’s aways good to ask and read
from profressionals like you :slight_smile:

Good approach. You can’t know if you have a scaling problem unless you
have metrics to back it up. Pre-optimization is a highly inefficient use
of your time.

Robert W. wrote in post #1047899:

Raimon Fs wrote in post #1047848:

  • Is it true that a slow queriy on RoR lock all other concurrent
    connections? This was true on old RoR versions.

This could be true in many cases, but is this really different from PHP?
Does PHP handle requests concurrently? I’m not really sure about that.
All the “intelligence” in wrapped up inside that Apache module and
there’s generally only one of those.

Sure I’m missing something, but in Apache you say how many workers want
for PHP and that’s all, with Thin/Mongrel/… you have to create them
before, and tell ngix how many you have. Maybe the Unicorn/Passenger is
the solution. I think I’m worried for things that maybe never are going
to happen, as this site is for an ERP where will be used by 100/200
persons.

In any case, chances are highly likely that you’ll never have to worry
about this. Slow queries are almost always the result of bad design.

yes, I know.

Rails and the techniques used by Rails developers provide a multitude of
solutions to this problem, without resorting to concurrent request
processing. In many cases not having concurrent processing simplifies
the app, resulting in increased stability and few hard to find bugs.
Threading is damn hard, as anyone who has had to deal with it will
confirm.

I have three sites with RoR, never have had any problem, but are sites
with very low traffic.

I usualy have my RoR served by Ngix with Thin.

Apahe can serve PHP directly.

Apache does NOT serve PHP directly. It forwards all requests to the PHP
module for processing.

This extra layer (Thin, mongrel,…) has some penalty on RoR ?

This is not an extra layer. It’s just in a different place.

I don’t know why I thout ngix process the page, pass it to Thin and Thin
pass to Ruby, but maybe is Thin who parses and executes the Ruby page
directly?

I know I can have many Thins servers listening and Ngix uses them by
demand, or use Passenger, Unicorn, … but those options are slowering
the web in comparation with Apache and PHP?

I prefer to use RoR but I have to convince the other programmer and my
Boss, both of them prefer Php because sound better, there are more
developers, bla bla bla

Convincing your coworkers and boss is not something we can help you
with. That’s all on you.

Well, you can help convince them with evidences :slight_smile:

Of course the best is what I’m doing, creating a RoR and Kohana web tot
test this very specific questions, but it’s aways good to ask and read
from profressionals like you :slight_smile:

Good approach. You can’t know if you have a scaling problem unless you
have metrics to back it up. Pre-optimization is a highly inefficient use
of your time.

I’m just testing and playing with it, I have one week for take a
decision, a full payed week just to play with both frameworks/languages.

thanks!

On 21 Feb 2012, at 08:14, Raimon Fs wrote:

Sure I’m missing something, but in Apache you say how many workers
want
for PHP and that’s all, with Thin/Mongrel/… you have to create them
before, and tell ngix how many you have. Maybe the Unicorn/Passenger
is
the solution. I think I’m worried for things that maybe never are
going
to happen, as this site is for an ERP where will be used by 100/200
persons.

FYI, we have a very large CRM/ERP application running on Rails that
serves well over the number of people you are mentioning.

If you want Rack apps such as Rails to run as an Apache module or
nginx module, then use Passenger. It follows the same mindset as the
PHP module.

Best regards

Peter De Berdt

Raimon Fs wrote in post #1047948:

Robert W. wrote in post #1047899:

Raimon Fs wrote in post #1047848:

  • Is it true that a slow queriy on RoR lock all other concurrent
    connections? This was true on old RoR versions.

This could be true in many cases, but is this really different from PHP?
Does PHP handle requests concurrently? I’m not really sure about that.
All the “intelligence” in wrapped up inside that Apache module and
there’s generally only one of those.

Sure I’m missing something, but in Apache you say how many workers want
for PHP and that’s all, with Thin/Mongrel/… you have to create them
before, and tell ngix how many you have. Maybe the Unicorn/Passenger is
the solution. I think I’m worried for things that maybe never are going
to happen, as this site is for an ERP where will be used by 100/200
persons.

The point I was trying to make here is that I have worked with languages
and frameworks that are absolutely proven to be highly performant and
scalable. However, I’ve found from experience that this hardly ever
matters. One poorly written SQL query, or one missed database index can
have at least a ten-fold effect over a particular choice of programming
language.

The chances of you actually building an app that performance of the
language and framework actually cause you significant problems is next
to nil. And, if you’re one of the lucky ones where it does matter, then
that’s a really good problem to have. If you did you marketing homework
right, then by that time you’ll have the funds to concentrate your
efforts on scaling your app.

I don’t know why I thout ngix process the page, pass it to Thin and Thin
pass to Ruby, but maybe is Thin who parses and executes the Ruby page
directly?

In any case the same basic work is happing, whether that be in a single
module or broken into several. I see it as an advantage having choice in
the middleware. Having the choice provides more flexibility for various
deployment scenarios.

Convincing your coworkers and boss is not something we can help you
with. That’s all on you.

Well, you can help convince them with evidences :slight_smile:

I suppose my cynicism here is related to my own situation. I have also
tried to convince my team that there are better ways to do things, but
some people are so set in their ways that it’s practically impossible to
change their minds, no matter what evidence you provide to them.

I wish you luck in your endeavors.

Thanks for your comments, I’ll keep you informed with the news (good or
bad) :slight_smile:

Hi all again,

I think I have good news, finally was my decision only and this time RoR
won over Php, now the bad news, I’m the only responsable if something
goes wrong because my choice was not ‘the popular choice’ :slight_smile:

thanks for your inputs again,

regards

You’re not the only one. More like you and the Ruby Nation. Get stuck?
Just ask, and be sure to copy and paste the error message in your mail.

Walter

Thanks Walter!

I’m not new to RoR, I have two RoR (2.x) that are working and perfectly
for two years without any issue, but are sites with low traffic.

Now it’s time (finally) to build one with more than 100 concurrent
users, now time,speed, good tweaks, … are important.

Now I’m fighting with assets compiled in 3.2.1 and starting using
Passenger with Nginx, previously I was using Nginx + Thin.

We can start another discussion on my job why Nginx and not Apache :slight_smile:

I’ll ask here if there’s some problem I can’t solve …

thanks again!

regards