I heard about Mongrel and Webrick, but they are also interpreted right? isn''t that going to be slow? I mean we know currently that Ruby Interpreter itself is slow as turtle. And our web applications are in Ruby already. So now we have rails, our application and the server being executed at one time. That would be a lot of resource and execution time per request. Is there an alternative like using Apache or other Known web servers? -- 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Go to the mongrel web site and read their documentation on deployment options. You can use mongrel by itself, or with a front end web server like Apache. It also goes into some details on the advantages and disadvantages of each deployment option so you can make an informed decision on what best fits your needs. I would recommend doing your research before posting your own speculations on what you feel are limitations in these technologies. Some very smart people have put these tools together, and they are very clear about what options you have. You just need to take to time to look into them. On May 7, 9:58 am, Mike Holper <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I heard about Mongrel and Webrick, but they are also interpreted right? > isn''t that going to be slow? I mean we know currently that Ruby > Interpreter itself is slow as turtle. And our web applications are in > Ruby already. So now we have rails, our application and the server being > executed at one time. That would be a lot of resource and execution time > per request. > > Is there an alternative like using Apache or other Known web servers? > > -- > Posted viahttp://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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
You don''t use Mongrel by itself. You use a mongrel cluster with a load balancer, like Apache. That takes the load of any static files off of Ruby. Then there''s your app. The execution of an application request dwarfs any work that Mongrel is doing. If 99% of a request is application processing then it doesn''t matter if you switch from Mongrel to an infinitely fast (magic) app server--you''ll still only get 1% improvement. There''s a lot of Rails performance hysteria out there right now, but it''s important to remember that Ruby is only slow relative to other languages, and not terribly slow at that. You don''t see people running out and building web frameworks in C++ just because "Java is slow". On May 7, 7:58 am, Mike Holper <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I heard about Mongrel and Webrick, but they are also interpreted right? > isn''t that going to be slow? I mean we know currently that Ruby > Interpreter itself is slow as turtle. And our web applications are in > Ruby already. So now we have rails, our application and the server being > executed at one time. That would be a lot of resource and execution time > per request. > > Is there an alternative like using Apache or other Known web servers? > > -- > Posted viahttp://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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Exactly, what is slow? My productivity has increased tenfold and the performance is top-notch. Serving static files through Apache and balancing the rest to a mongrel cluster is just a dream come true. On 07 May 2007, at 17:15, dasil003 wrote:> There''s a lot of Rails performance hysteria out there right now, but > it''s important to remember that Ruby is only slow relative to other > languages, and not terribly slow at that. You don''t see people > running out and building web frameworks in C++ just because "Java is > slow".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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 07 May 2007, at 17:15, dasil003 wrote:> There''s a lot of Rails performance hysteria out there right now, but > it''s important to remember that Ruby is only slow relative to other > languages, and not terribly slow at that.The benchmarks I''ve seen put Ruby at the slowest language out there that anyone''s actually using. That said, slow is often relative to what you''re doing, how you code it, and what other facilities you use. Rails has a lot of mechanisms (caching, etc.) to help speed up your *app*. -faisal --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On May 7, 2007, at 12:58 PM, Faisal N Jawdat wrote:> The benchmarks I''ve seen put Ruby at the slowest language out there > that anyone''s actually using. That said, slow is often relative to > what you''re doing, how you code it, and what other facilities you > use. Rails has a lot of mechanisms (caching, etc.) to help speed > up your *app*.*also* The Ruby performance issue is around execution speed. Threads won''t particularly help with that, except insofar as they reduce the memory footprint of the application server. It isn''t clear how much they''ll help there, since a lot of the infrastructure will need to be replicated anyway. -faisal --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Another issue, that hasn''t yet been raised, is that if your Ruby code is spending 90%+ of it''s time waiting on you SQL queries to return, then the performance difference between Ruby and any other language becomes irrelevant. In my experience this is true a very large percentage of the time. Most of your performance tweaking will be database related anyway. On May 7, 1:01 pm, Faisal N Jawdat <fai...-yPPMdBsEuU/QT0dZR+AlfA@public.gmane.org> wrote:> On May 7, 2007, at 12:58 PM, Faisal N Jawdat wrote: > > > The benchmarks I''ve seen put Ruby at the slowest language out there > > that anyone''s actually using. That said, slow is often relative to > > what you''re doing, how you code it, and what other facilities you > > use. Rails has a lot of mechanisms (caching, etc.) to help speed > > up your *app*. > > *also* > > The Ruby performance issue is around execution speed. Threads won''t > particularly help with that, except insofar as they reduce the memory > footprint of the application server. It isn''t clear how much they''ll > help there, since a lot of the infrastructure will need to be > replicated anyway. > > -faisal--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---