Comments on: Performance comparison: Rails 1.2.6 vs 2.0.2

By: Hongli

Hongli — Mon, 24 Mar 2008 22:23:52 +0000

My response was a joke. But point taken.

By: tangfucius

tangfucius — Mon, 24 Mar 2008 22:08:52 +0000

Hongli, that was definitely one of the more interesting responses I’ve read in a while… Your formula only works if part A and part B are separate, non-correlated entities… The “mathematically proven” formula used is based on assumptions that vary in validity when the application specific code changes…

You should know that rails and the applications run on it are rather sophisticated, a A + B formula is really an insufficient way to claim any plausible performance benchmark results. It’s like saying mysql is faster than oracle just because it does select statements faster on myisam tables than regular oracle selects…

I didn’t mean to take any validity out of your benchmark results, but was simply suggesting more ways to improve the benchmark tests, thus hoping for a more thorough, accurate benchmark.

Good luck.

By: RX-7乗りの適当な日々

RX-7乗りの適当な日々 — Mon, 24 Mar 2008 13:54:17 +0000

[IT] Rails 1.2.6 と 2.0.2 のパフォーマンス比較…

先日のエントリ「RedmineでのRailsパフォーマンス比較(1.2.6 vs 2.0.2)」(d:id:rx7:20080221:p1)に続いて、Ruby on Railsのパフォーマンスに関する話題を1つ。他のサイトでも、Rails2.0系と1.2系のパフォー…

By: Hongli

Hongli — Thu, 20 Mar 2008 22:08:27 +0000

tangfucius: You can. The dummy application essentially benchmarks the foundation. Every Rails application consists of two parts, A (the Rails platform) and B (the application-specific code). Let the t(x) be the time that part x spends one request. Then the total time that the application spends on one request is t(A) + t(B). Suppose A1 is Rails 1.2.6 and A2 is Rails 2.0.2. If t(A2) < t(A1), then t(A2) + t(B) < t(A1) + t(B). Now, we observe that the dummy application has very little app-specific code. So t(B) ≈ 0. Then we can say: t(A) + t(B) ≈ t(A). I have mathematically proven that benchmarking the dummy application is a useful benchmark for the Rails framework. QED.

By: tangfucius

tangfucius — Thu, 20 Mar 2008 22:02:08 +0000

you really can’t benchmark a software framework based on a dummy application… what about doing benchmarks for a real app that uses the many features of rails?

By: links for 2008-03-20 « Brent Sordyl’s Blog

links for 2008-03-20 « Brent Sordyl’s Blog — Thu, 20 Mar 2008 15:23:59 +0000

[…] Performance comparison: Rails 1.2.6 vs 2.0.2 Even with sessions off, Rails 2.0 is still 30% faster! So the cookie session store isn’t the only thing responsible for the performance improvement! (tags: performance rubyonrails) […]

By: Crónica de una vida - Rendimiento de Rails 2.0 y el futuro Rails 2.1

Crónica de una vida - Rendimiento de Rails 2.0 y el futuro Rails 2.1 — Thu, 20 Mar 2008 08:33:57 +0000

[…] Riding Rails nos informan que alguien ha hecho una comparativa demostrando que Rails 2.0 es entre un 30 y 50% más rápido que Rails 1.2.X. Además otro estudio […]

By: links for 2008-03-20 « Bloggitation

links for 2008-03-20 « Bloggitation — Thu, 20 Mar 2008 00:20:37 +0000

[…] Performance comparison: Rails 1.2.6 vs 2.0.2 (tags: rails ruby sysadmin tuning) […]

By: David Mabelle

David Mabelle — Wed, 19 Mar 2008 21:57:11 +0000

Large fixtures (20 megs) can completely tie up all the memory or crash the process.

By: David Mabelle

David Mabelle — Wed, 19 Mar 2008 21:39:07 +0000

The major bottleneck still exist with using fixtures to import an existing database. It takes 30 seconds to restore a database in Postgresql. It takes a day to bring in the same data with rails.