Posted by ezmobius Thu, 01 May 2008 23:26:00 GMT
Engine Yard is looking for one or two kick ass Erlang programmers to help work on our next generation cloud computing platform. Knowledge of ruby/xmpp/ejabberd/linux is a plus.
If you think you fit the bill then please email me directly at ezra@engineyard.com.
Posted by ezmobius Fri, 25 Apr 2008 00:34:00 GMT
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 ;)
Posted by ezmobius Fri, 18 Apr 2008 06:20:00 GMT
There is a classic tradeoff between threaded servers and event driven servers. Event driven servers tend to be much faster than threaded servers when all the requests are fairly fast. But the event model falls down if you have long requests like file uploads or reporting actions. This is because the long action blocks the event loop, effectively keeping other requests from running.
There are two new event driven ruby webservers at your disposal these days, Thin and Ebb. Both of these servers support the Rack web server interface that merb uses. Until now both of these servers were not the best choice for file uploads or long blocking actions but that’s all changing.
Both ebb and thin have added a deferred?(env) method to their rack adapter interface. Both webservers will call this method on your Rack @app object before they call your call(env) method. This allows your rack adapter to determine if the request should be run in its own thread if it’s slow.
I’ve just committed support for this deferred_actions construct in merb-core. If you want to run on thin or ebb but you have say a file upload action and some slow reporting actions you could add this to your init.rb in your app:
Merb::Config[:deferred_actions] = ["/uploads/create", "/reports/longaction"]
What this means is that all of your actions will run in fast event driven mode except for requests to /uploads/create and /reports/longaction. Any request for either of these urls will be served from a newly spawned thread, all other requests will be served by the main event loop.
This allows us to have the best of both world. Combining threaded and event driven styles to use the strengths of both makes a lot of sense here.
Cheers to the authors of ebb and thin for making the same interface. All of this requires the HEAD versions of ebb or thin so if you want to play along at home you will need to build thin or ebb from source on github: ebb and thin
Posted by ezmobius Fri, 11 Apr 2008 06:59:19 GMT
Jed Hurt and Lance Carlson made a nice wiki engine in merb that we’ve thrown up at http://wiki.merbivore.com. Thanks Guys!
You can get the source to the wiki app on github: Collective Wiki Engine
There are the starts of some good information published already, please feel free to add to it!
Posted by ezmobius Thu, 10 Apr 2008 19:46:00 GMT
GitHub has officially launched! No more invites required to sign up.
In preparation for their launch we set them up on a shiny new Engine Yard cluster. With all the adoption of git/github as well as Rails itself about to switch to github we wanted to make sure everyones favorite git repo hosting can scale as far as folks want to take it.
So go Sign Up already and fork your favorite projects to your hearts desire!
Searching...
