High Performance Ruby MVC: Merb

by Sebastien Auvray on Aug 26, 2007 |

There have been long debates on Rails performance. Rails can really slow down when your application deals with a lot of File exchange or concurrent connections. That is what Merb has been designed for. Ezra Zygmuntowicz, from Engine Yard, started working on Merb (Mongrel+Erb) 10 months ago and gave a presentation this month about it at Ruby Hoedown. Ezra originally tried to optimize Rails to make it more threadsafe, but at the end it was easier to make a new framework than trying to change ActionPack, (the View and Controller parts of Rails).

Merb is similar to Rails in many ways. What differentiates Merb from Rails is:

It has no cgi.rb
It has a clean room implementation of ActionPack
It is threadsafe with configurable Mutex Locks (Routing is also threadsafe)
It has been designed favoring simplicity and clarity over magic
A light core framework easy to extend through hacks

The key differences are:

No auto-render. The return value of your controller actions is what gets returned to client. You have to explicitly call a render method if you want it.
Merb's render method just returns a string, allowing for multiple renders and additional flexibility over similar functionality in Rails
PartControllers allow for encapsulated apps without big performance cost

A sample Merb application by Zack Chandler is available. Merb v0.4 Core is quite complete and Ezra promised it would stay light, with additional features provided by plugins.

What's in the pipeline for next releases ?

Docs, specs, tutorials
Rubinius compatibility
More profiling and optimizations
More tools and creature comforts

Concerning performance, Phil Misiowiec released an exhaustive comparison of Rails, Merb performance (using Swiftiply and Nginx). Phil's goal was to test real world clustering configurations. He looked at how concurrency affected the application running Rails vs Merb with various session management options (Disabled, Database stored, Memcached), and logging. In all tests, Merb performs better than Rails, and depending on the App Server and HTTP Server, it outperformed Rails by 5%-20%.

Phil draws the conclusion:

Using Evented Mongrels with Merb gives you the best bang for the buck overall when high concurrency is expected [...] be sure you understand your application's usage patterns and not over-engineer your solution. In most cases, running Rails with a standard Mongrel cluster may be just fine for you.

Related Editorial

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

eBook: The New Kingmakers - How Developers Conquered the World

Making the Shift from Relational to NoSQL

ICEmobile in a Minute - The Easiest Way to Mobilize Your Enterprise Apps

Infographic: Just How Big is the Nerd Economy

Related Sponsor

Get code level visibility into your web apps. All for free.

Try New Relic Today.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Speed? by Daniel Berger Posted

Bad link? by Kevin Williams Posted

Re: Bad link? by Sebastien Auvray Posted

Re: Speed? by Kirk Haines Posted

Not just speed...efficiency by Geoffrey Grosenbach Posted

Re: Not just speed...efficiency by Daniel Berger Posted

Speed? by Daniel Berger

I don't think a 5-20% speed increase is compelling, personally. Mind you, if Rails continues to get slower with each new release, it could become compelling. And, hey, competition is always good, so I'm glad I have a choice at least. :)

Bad link? by Kevin Williams

The Merb v0.4 link (merbivore.com/) gives me a 404 error.

Re: Bad link? by Sebastien Auvray

Hi Kevin,
Indeed it seems to be down at the moment.
You can still find a mirror at merb.rubyforge.org/files/README.html
Regards,
Sébastien.

Not just speed...efficiency by Geoffrey Grosenbach

It's about more than just speed. It's also about handling more traffic with fewer Mongrels and less memory. Merb lets Mongrel do more of the work and can spin off threads when needed to handle additional requests.

Re: Speed? by Kirk Haines

Just kind of throwing this out, but...

The same benchmark, running through Swiftiply to 2 backend processes, on an AMD dual core Athlon 4200+ (so, a little bit faster than the test machine for Phil Misiowiec's benchmarks), with IOWA:

Concurrency of 10: 1076/second
Concurrency of 100: 995/second

Re: Not just speed...efficiency by Daniel Berger

Geoffrey, that's a good point. Are there any memory profiling statistics out there? I'd like to see that.