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.
Community comments
Speed?
by Daniel Berger,
Bad link?
by Kevin Williams,
Re: Bad link?
by Sebastien Auvray,
Re: Speed?
by Kirk Haines,
Not just speed...efficiency
by Geoffrey Grosenbach,
Re: Not just speed...efficiency
by Daniel Berger,
Speed?
by Daniel Berger,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
The Merb v0.4 link (merbivore.com/) gives me a 404 error.
Re: Bad link?
by Sebastien Auvray,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
Geoffrey, that's a good point. Are there any memory profiling statistics out there? I'd like to see that.