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