Brainspl.at: Hey Rails, nice Rack!

"Hey Rails, nice Rack!" by random8r

Sun, 18 May 2008 00:50:27 +0000

I'll notice making concurrent requests, because in one of my apps, I'm doing concurrent requests. How I've done it in the past has been to run two copies on different ports, and change the parts of code the do concurrent requests to request on the different port. KLUDG-O-RAMA. I love you Ez. -Random8r

"Hey Rails, nice Rack!" by Yuri Leikind

Sat, 03 May 2008 08:50:50 +0000

Been doing Rails development professionally (i.e. getting paid for this :) for some time now. Watched your MountainWest RubyConf presentation, got impressed and finally realized that Merb is not a toy or a bastardized version Rails :) Your work on the crufty guts of Rails is promising, really looking forward to see this included in Rails. Keep it up, you're a coding Jedi.

"Hey Rails, nice Rack!" by Kevin Stewart

Wed, 30 Apr 2008 20:49:55 +0000

@Ezra: Whew! That's good to hear. Now, how about releasing 0.93? Or better yet, 1.0? :-) Sorry, I couldn't resist. I'll get back to working on my Merb app now...

"Hey Rails, nice Rack!" by Ezra Zygmuntowicz

Wed, 30 Apr 2008 17:52:50 +0000

@Kevin- At this point merb is not going anywhere. If the rails core team wanted to get radical and decide to build rails 3.0 on top of merb-core technology then I might consider merging the two projects. But I think that would take a lot of politics and I'm not sure if they would agree to it. So don't fret, merb is here to stay unless the rails-core has a drastic change of heart. And the code base for merb is *way* more simple and scalable for the future since it has no baggage. So expect merb to stick around and innovate for a long time to come. I just figured that there is no reason for everyone using Rails to suffer when I could spend a few weeks and improve a bunch of stuff for folks.

"Hey Rails, nice Rack!" by Kevin Stewart

Wed, 30 Apr 2008 16:17:35 +0000

Great work, Ezra! Of course, this now raises an interesting question. Merb was created to address technical issues with Action Pack. If the approaches pioneered in Merb are now pushed back into Rails, why should one continue to use Merb? Or, more importantly should the Merb efforts be directed towards making Rails better? It's sort of like you forked and are now bringing the forks back together. I'm currently using Merb (quite happily, BTW) but if Merb development stalls to "fix" Rails I would be a little concerned. Not that I have anything against Rails, I just like Merb's philosophy more. Is it the philosophy that will keep Merb and Rails separate, or will they evolve and converge toward esch other?

"Hey Rails, nice Rack!" by DaveS

Wed, 30 Apr 2008 07:38:47 +0000

Whoa... thank you Ezra!!!! PS: Why isn't Ezra part of rails core???? He's amazing!

"Hey Rails, nice Rack!" by Alan Brown

Mon, 28 Apr 2008 09:26:40 +0000

"just using your browser to test the app in dev mode you won;t ever notice since you won;t be making concurrent requests" Can't concurrent requests happen alot, even in test mode, especially if your app uses AJAX? Appreciate the work on this stuff. There's a Moore's Law for Rails and you're making it happen.

"Hey Rails, nice Rack!" by MIke Costa

Mon, 28 Apr 2008 07:49:25 +0000

Thanks for your work Ezra. I was hoping you would port Merb thread-safety to Rails one day. You're a winner!

"Hey Rails, nice Rack!" by Ezra

Sun, 27 Apr 2008 18:04:24 +0000

yeah the idea is for this to be merged into rails proper once it is complete and tested, the core team knows of my work and says it will make it in once it is done. As far as mod_rails goes... I think they made a huge mistake by not using rack as their interface, so I'd hope they will realize this and add rack support. mod_rubinius is all rack based and will be able to run any ruby framework or simple rack handlers you can throw at it.

"Hey Rails, nice Rack!" by Adam

Sun, 27 Apr 2008 17:19:20 +0000

Awesome work man! You are my personal hero! I have the same question that zerohalo has and that's are there talks about this being added to the "official" branch or will this be something that sits on the side? If it is the latter, what's the strategy for continuing support of the new rails code? In addition to that, this is an open question to all: Has anyone tried to see if these changes still work with mod_rails? If no one has, I suppose I can look into seeing if this works later.

"Hey Rails, nice Rack!" by Anil Wadghule

Sun, 27 Apr 2008 12:23:24 +0000

This is really great! :)

"Hey Rails, nice Rack!" by Finanzamt

Sat, 26 Apr 2008 16:40:42 +0000

Helpful post! Thank you!

"Hey Rails, nice Rack!" by zerohalo

Sat, 26 Apr 2008 16:13:58 +0000

Awesome! Thanks, Ez. Will these changes at some point be committed to the main Rails trunk?

"Hey Rails, nice Rack!" by Stefan Saasen

Sat, 26 Apr 2008 09:50:28 +0000

That is great news! Works like a charm.

"Hey Rails, nice Rack!" by Maximilian Schulz

Sat, 26 Apr 2008 09:42:34 +0000

Wow… this sounds amazing! Can't wait to check it out.

"Hey Rails, nice Rack!" by Chad Fowler

Sat, 26 Apr 2008 07:52:45 +0000

Nice job Ezra!

"Hey Rails, nice Rack!" by Pratik

Fri, 25 Apr 2008 23:54:30 +0000

Awesome stuff :-) !

"Hey Rails, nice Rack!" by Tobias Lütke

Fri, 25 Apr 2008 22:46:48 +0000

Awesome ezra. Thank you so much.

"Hey Rails, nice Rack!" by meekish

Fri, 25 Apr 2008 22:45:46 +0000

Mad props

"Hey Rails, nice Rack!" by Drogomir

Fri, 25 Apr 2008 22:15:33 +0000

Great job! :) Keep going. Rails definetely needs some more love.

"Hey Rails, nice Rack!" by Lucas Húngaro

Fri, 25 Apr 2008 20:31:55 +0000

Congratulations! Keep up the awesome work!

"Hey Rails, nice Rack!" by Bruno Michel

Fri, 25 Apr 2008 19:20:21 +0000

It rocks. Thanks for doing it :)

"Hey Rails, nice Rack!" by Phil

Fri, 25 Apr 2008 19:04:31 +0000

Awesome sauce. Hope this makes it into 2.1.

"Hey Rails, nice Rack!" by johan

Fri, 25 Apr 2008 17:06:32 +0000

I'd hit that

"Hey Rails, nice Rack!" by macournoyer

Fri, 25 Apr 2008 14:54:15 +0000

omg, nice work! especially on the removing of the CGI wrapper, I tried that but it was too much work :/ And moving the mutex deeper is equally delicious!

Hey Rails, nice Rack!

ezmobius — Fri, 25 Apr 2008 00:34:00 +0000

So i’ve spent this week hacking on Rails, specifically going spelunking in ActionPack and porting Merb’s rack machinery to rails. I figure that merb is a very nice experimentation ground and decided it was time to give some love back to the framework that inspired merb.

While still not complete, I have made significant headway on racking up rails in my github fork of Rails. I’ve added rack adapters for mongrel, eventedmongrel, thin, ebb and webrick. All of this is controlled via ./script/rackup in a rails app. So to start a cluster of 5 thin servers you would run this command:

./script/rackup -a thin -c 5 -e production

I do have to say that parts of ActionPack haven’t been touched in a long time and had accumulated some cruft, with the rails rack adapter that thin and ebb use there was a dogpile of wrappers going on. A web request was wrapped in many layers like this(the → means ‘wrapped in’)

raw request -> rack env -> Rack::Request -> CGIWrapper -> CgiRequest

That was far too many wrappers, it also turned out that some of these wrapper were making duplicates of all the CGI headers, meaning quit a bit of wasted memory on every request. I’ve slimmed it down to this now:

raw request -> rack env -> ActionController::RackRequest

With no more duplication of CGI headers, win!

I’ve also changed the giant mutex lock to be much smaller, it used to lock around the dispatcher callbacks, route recognition, controller instantiation, filters and action dispatch. Now it only locks around filters and action dispatch, Dispatcher callbacks, route recognition and controller instantiation all happen outside of the lock. This makes for a nice little speed boost with standard mongrel under concurrent load.

Of course this doesn’t work so hot in development mode when you have concurrent requests, it falls apart due to route set reloading and class reloading done in dev mode. But if you are just using your browser to test the app in dev mode you won;t ever notice since you won;t be making concurrent requests. In production mode the route recognition appears to be thread safe, more extensive testing and stressing will be needed to be 100% certain though.

All in all I feel like these are some big wins for Rails. And I’m not done yet, I plan on beating up ActionPack quite a bit more until it submits ;)