# A self-contained Rails application/benchmark? **URL:** \ **Category:** Rails\ **Created:** [September 19, 2007, 6:40am UTC](https://www.ruby-forum.com/t/a-self-contained-rails-application-benchmark/114951 "2007-09-19T06:40:36Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![znmeb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/b38774/32.png) [@znmeb](https://www.ruby-forum.com/u/znmeb)\ **Post date:** [September 19, 2007, 6:40am UTC](https://www.ruby-forum.com/t/a-self-contained-rails-application-benchmark/114951/1 "2007-09-19T06:40:36Z")
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. ---
**Author:** ![znmeb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/b38774/32.png) [@znmeb](https://www.ruby-forum.com/u/znmeb)\ **Post date:** [September 19, 2007, 7:42am UTC](https://www.ruby-forum.com/t/a-self-contained-rails-application-benchmark/114951/2 "2007-09-19T07:42:40Z")
On 9/18/07, znmeb [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](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](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 V. CruiseControl.rb [[http://cruisecontrolrb.thoughtworks.com](http://cruisecontrolrb.thoughtworks.com)] RubyWorks [[http://rubyworks.thoughtworks.com](http://rubyworks.thoughtworks.com)] ---
**Author:** ![znmeb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/b38774/32.png) [@znmeb](https://www.ruby-forum.com/u/znmeb)\ **Post date:** [September 19, 2007, 3:26pm UTC](https://www.ruby-forum.com/t/a-self-contained-rails-application-benchmark/114951/3 "2007-09-19T15:26:10Z")
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. 🙂 ---
**Author:** ![znmeb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/b38774/32.png) [@znmeb](https://www.ruby-forum.com/u/znmeb)\ **Post date:** [September 20, 2007, 4:13am UTC](https://www.ruby-forum.com/t/a-self-contained-rails-application-benchmark/114951/4 "2007-09-20T04:13:58Z")
On 9/19/07, znmeb [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 V. CruiseControl.rb [[http://cruisecontrolrb.thoughtworks.com](http://cruisecontrolrb.thoughtworks.com)] RubyWorks [[http://rubyworks.thoughtworks.com](http://rubyworks.thoughtworks.com)] ---
**Author:** ![znmeb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/b38774/32.png) [@znmeb](https://www.ruby-forum.com/u/znmeb)\ **Post date:** [September 21, 2007, 4:34am UTC](https://www.ruby-forum.com/t/a-self-contained-rails-application-benchmark/114951/5 "2007-09-21T04:34:28Z")
On Sep 19, 7:13 pm, “Alexey V.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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. 🙂