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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 blaConvincing 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.