Ry,
We recently released WebROaR (http://webroar.in/) - Ruby Application Server
under GPLv3 that uses libebb for HTTP parsing. Libebb is one of the key
components of this server and a major reason for its good performance.

On behalf of the team (Dharmarth, Nikunj & myself), i would like to thank
you for your excellent work on this library. (I am sure lot of other people
would share that sentiment.)

We would keep sending back patches to you upstream if required (as we have
done so far).

Aditya

We haven't done a comparison with Unicorn yet. You can refer the other
benchmarks we have done so far here:

http://webroar.in/blog/2009/11/25/comparison-of-rails-deployment-stac...

Aditya

From http://webroar.in/faq

------------------------
WebROaR has a head process that accepts connections, parses the HTTP
request, and passes it to the appropriate worker process (that has the
corresponding Ruby Web Application code loaded in it). Head and worker are
both written in C, and use the terrific
libev<http://software.schmorp.de/pkg/libev.html> event
loop for all the asynchronous and non-blocking socket communication with
each other as well as the clients.

Worker loads up (aka embeds) the Ruby interpreter, the web framework and the
application code in it. In case any exception occurs while processing a
request or analytics have been enabled for that application, the worker
process dispatches a message packet to Starling Message Queue.

WebROaR Analyzer daemon takes its own sweet time to dequeue messages,
analyze them and stores the required data to a database.

A nice and simple Admin Panel Rails application running in one of the
workers itself helps in easy UI driven deployment. It also shows all the run
time numbers stored in the database in a variety of useful views, along with
the list of exceptions that occur in the deployed applications.

All the server processes talk to each other (whenever required) using SCGI.

<http://webroar.in/faq>------------------------

Jeremy,
It's actually been a while when we went looking around for a suitable
message queue. At that time, Starling was the most battle tested one, didn't
have any other dependencies like some of the other good ones and was simple
enough.

New shinier options have come up on horizon since, and if required we would
move to another one. As of now, WebROaR only uses it as an intermediate
store for analytics data packets and exceptions before they are processed &
stored in the database. So far so good for the applications we have tested
on WebROaR. Based on how it goes for other people and their applications, we
would take a call on it.

Aditya

p.s. Sorry for this awfully long delay in replying to your query. I did send
this on 3rd Dec itself but seems it never made it to the Group. Chanced upon
visiting the group from the web again today, and didn't see it.