> Well, this may be mean, but have you ever considered that "the massive 
> amount of features webrick offers" is part of the problem?  It's 
> difficult to go into a large (or even medium) code base and profile it 
> and then add bolt on performance improvements.  It can be done, but it 
> usually ends up as a wart on the system.
> 
> So, rather than try to "fix" WEBrick I'm just considering it a different 
> solution to a different set of problems.  Mongrel may pick up all the 
> features WEBrick has, but right now it's targeted at just serving Ruby 
> web apps as fast as possible.

I suspected something along those lines :) I would probably do the same 
because starting from the beginning is always more fun than trying to 
understand a large code base. Although I personally think that the latter 
doesn't have to be slower. How long could it take to find a dozen slow 
spots in webrick? Maybe 2-3 days? Another 2-3 days to tune them?

Anyway, I was just curious, and I am looking forward to following along and 
look and learn from the C code. I personally never had the need for 
anything to be faster than Ruby *except* the http stuff. But since I have 
never actually written more than a couple of lines of C I shyed away from 
starting such a thing.

Another tip: Maybe you want to look at Will Glozer's Cerise.

http://rubyforge.org/projects/cerise/

It has a minimum bare bones http server entirely written in Ruby. Maybe it 
is of help. Just a thought.

-Sascha