I''m looking for a self-contained Rails application that I can use as a benchmark for Ruby, Rails, and presumably the hardware and RDBMS as well. It must be open source. It''s not particularly important to me what the application domain is, but it should be something simple. In looking for decent-sized Rails applications that are open source and seem to be well maintained, the only thing I''ve come up with so far is Typo. If nothing else turns up in a week or so, that''s what I''m planning to use. But I''m open to any others. --~--~---------~--~----~------------~-------~--~----~ 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 9/18/07, znmeb <zznmeb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> In looking for decent-sized Rails applications that are open source > and seem to be well maintained, the only thing I''ve come up with so > far is Typo.The problem with Typo (as well as Mephisto, Beast, RForum, Instiki and other blog / content management sort of apps) is that they do a lot of page caching, so their execution profile has almost nothing to say about performance of, e.g., transaction processing apps. Facing the same problem at ThoughtWorks (making publishable, reproducible statements about comparative Rails performance), we recently created a couple of Petstore projects (woo-hoo, not just one, but two!). Reproduction of Sun''s classic: http://tw-commons.rubyforge.org/svn/petstore/trunk Something a bi t more Web 2.0-ish: http://tw-commons.rubyforge.org/svn/petstore2/trunk By the way, in some quick and dirty test I ran just yesterday, Rails (running the first of the two Petstores above) seems about three times slower than lean-and-mean Java (Clinton Begin''s JPetStore 5.0). -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.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 -~----------~----~----~----~------~----~------~--~---
Thanks!! I''m not familiar with the "classic" Pet Store application. As far as caching or other ways to make web apps scale are concerned, the goal of this exercise is to drive *Ruby* into saturation doing things that it does repetitively in real code. So caching, hyperfast web servers, lots of RAM, a fast RDBMS and other nice things we do to make web apps scale aren''t necessarily bad. The fewer *other* bottlenecks there are, the happier I''m going to be. :) --~--~---------~--~----~------------~-------~--~----~ 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 9/19/07, znmeb <zznmeb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> So caching, hyperfast web > servers, lots of RAM, a fast RDBMS and other nice things we do to make > web apps scale aren''t necessarily bad. The fewer *other* bottlenecks > there are, the happier I''m going to be. :)Thing is, with *page* caching turned on you will be measuring how fast Mongrel can serve static content. And that''s not a terribly interesting thing to measure, because basically nobody serves static content through Mongrel in production. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.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 -~----------~----~----~----~------~----~------~--~---
On Sep 19, 7:13 pm, "Alexey Verkhovsky" <alexey.verkhov...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 9/19/07, znmeb <zzn...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > So caching, hyperfast web > > servers, lots of RAM, a fast RDBMS and other nice things we do to make > > web apps scale aren''t necessarily bad. The fewer *other* bottlenecks > > there are, the happier I''m going to be. :) > > Thing is, with *page* caching turned on you will be measuring how fast > Mongrel can serve static content. And that''s not a terribly > interesting thing to measure, because basically nobody serves static > content through Mongrel in production.And basically nobody runs code twice or ten times or a thousand times if they can get away with running it once and saving its output! Mongrel is mostly Ruby, so I''ll be measuring what Mongrel does with a realistic test case. I should also note that the profiling tools I''m using go down to the chip and OS level. This is a fun thing anyhow -- I''m not actually trying to win any horseraces here. If *that* was my goal, I''d do what everybody does -- throw hardware at it because it''s cheaper than thinking about bottlenecks. :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---