threaded ebb
I've become obsessed with getting Ebb to handle threads better and I think it's doing much better now. The main benchmark that I measure against is an application which sleeps every 10 requests for a given amount of time. This is a very realistic situation, I think; you would not want your server performance to crumble because of a single slow resource. Mongrel, which handles each request in its own thread, does this the best. But now Ebb can handle this too while only taking a modest hit at the throughput. Here is the benchmark showing all other servers being pummeled by the odd slow request.
(ebb_sequential is the exact same code base but without threading the requests. It can be enabled with the -S option to ebb_rails.)
To demonstrate that ebb_threaded still performs well with fast applications here are my standard graphs:
As you can see the sequential ebb is faster and perhaps might work better on websites where the application responds quickly to each request. Some sort of hybrid configuration would be easy to hack onto Ebb so that you could use threaded processing for certain URLs and sequential for others. The key bit looks like this
while @running
FFI::server_process_connections()
while client = FFI::waiting_clients.shift
if threaded_processing
Thread.new(client) { |c| c.process(app) }
else
client.process(app)
end
end
endYou'd just have to first evaluate
client.env['PATH_INFO'] to see if you want threaded processing or sequential.
I'll play around with this code for a few more days before I release it in a gem. It's quite possible there is something incredibly buggy and/or wrong.
![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small}
four) wrote,
