Why RoR over PHP Framework ?

rubyonrails-talk
1

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,

2

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.

3

Robert Walker 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!

4

Raimon Fs wrote in post #1047948:

Robert Walker 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.

5

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

6

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

7

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

8

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

9

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