A self-contained Rails application/benchmark?

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

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