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 :-)

thanks,

--
Posted via http://www.ruby-forum.com/.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Search Discussions

  • Robert Walker at Feb 20, 2012 at 10:53 pm

    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 :-)
    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.

    --
    Posted via http://www.ruby-forum.com/.

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Raimon Fs at Feb 21, 2012 at 7:14 am

    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 :-)

    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 :-)
    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!

    --
    Posted via http://www.ruby-forum.com/.

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Robert Walker at Feb 21, 2012 at 8:00 am

    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 :-)
    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.

    --
    Posted via http://www.ruby-forum.com/.

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Peter De Berdt at Feb 21, 2012 at 8:11 am

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

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

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Raimon Fs at Feb 21, 2012 at 11:38 am
    Thanks for your comments, I'll keep you informed with the news (good or
    bad) :-)

    --
    Posted via http://www.ruby-forum.com/.

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Mongeta 99 at Apr 23, 2012 at 1:00 pm
    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' :-)

    thanks for your inputs again,

    regards

    --
    Posted via http://www.ruby-forum.com/.

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Walter Lee Davis at Apr 23, 2012 at 1:31 pm
    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
    On Apr 23, 2012, at 8:00 AM, mongeta 99 wrote:

    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' :-)

    thanks for your inputs again,

    regards

    --
    Posted via http://www.ruby-forum.com/.

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Mongeta 99 at Apr 23, 2012 at 1:55 pm
    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 :-)

    I'll ask here if there's some problem I can't solve ...

    thanks again!

    regards

    --
    Posted via http://www.ruby-forum.com/.

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedFeb 20, '12 at 5:33p
activeApr 23, '12 at 1:55p
posts9
users3
websiterubyonrails.org
irc#RubyOnRails

People

Translate

site design / logo © 2022 Grokbase