Robert Klemme wrote:
> 2006/6/2, Alex Young <alex / blackkettle.org>:
>> Hi all,
>>
>> I'm trying to benchmark a few HTTP server types on Windows (XP Home,
>> specifically - don't ask why), and I've hit a snag with this code:
>>
>> ------------------------------
<snip code>
>> -------------------------
>>
>> The problem is that with n that high, I get an
>>
>>    c:/ruby/lib/ruby/1.8/net/http.rb:562:in `initialize': Bad file
>> descriptor - connect(2) (Errno::EBADF)
>>          from c:/ruby/lib/ruby/1.8/net/http.rb:562:in `connect'
>>         ...
>>         from c:/ruby/lib/ruby/1.8/xmlrpc/client.rb:535:in `do_rpc'
>>
>> error during the second round.  Looking at netstat -a afterwards, I see
>> almost every local port in the range 1026-5000 in the TIME_WAIT state.
>> That's a suspiciously round number, and I suspect there's a
>> 'client_port_max=5000' setting somewhere.  That's not what bothers me.
>> Why are these ports waiting, and how can I close them, or reduce their
>> timeout value?  I'd rather not insert 30 second waits all over the place
>> if that's enough of a delay...
>>
>> Any tips?  Moving to a different OS is not, unfortunately, an option,
>> although shifting up to XP Pro might be in a pinch.
> 
> I guess you were bitten by a limitation in the network handling of
> your version of Windows.  Only server operating systems are allowed a
> high number of incoming connections.  
That's fine.  I don't need concurrent connections.  The problem is, the 
connections are hanging around for far longer than I need them.  Is 
there (likely to be) any way I can explicitly get rid of them, or is the 
delay just one of those annoying little 'features' that MS are using to 
try to convince me to spend more money?

> I don't know whether there is a
> tweak that will fix this but if not you will have to change OS or the
> algorithm (doing sleeps in between for example).
Bah.  Not what I was after, but I guess if there's no other way round it...

> 
> Btw, why did you choose this subject?
If you mean the email subject line, I figured that other people out 
there must be trying to benchmark WEBrick against other HTTP server 
types (mongrel, et al), but not necessarily as a back-end to XMLRPC. 
The problem doesn't seem like it would be limited to XMLRPC to me.

-- 
Alex