# WEBrick on Windows

**URL:** <https://www.ruby-forum.com/t/webrick-on-windows/62295>\
**Category:** Ruby\
**Created:** [June 2, 2006, 11:50am UTC](https://www.ruby-forum.com/t/webrick-on-windows/62295 "2006-06-02T11:50:36Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\
**Post date:** [June 2, 2006, 11:50am UTC](https://www.ruby-forum.com/t/webrick-on-windows/62295/1 "2006-06-02T11:50:36Z")

</div>

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:

* * *

require ‘xmlrpc/server’  
require ‘xmlrpc/client’  
require ‘benchmark’

class ServerObject \< XMLRPC::Server  
def initialize  
super(8080)  
@server.config[:AccessLog] = [[’’, ‘’]]  
self.add\_handler(‘benchmark.simple’) do  
test()  
end  
end  
def test  
‘test’  
end  
end

test\_obj = ServerObject.new  
serving\_thread = Thread.new{ test\_obj.serve }

client = XMLRPC::Client.new(‘127.0.0.1’, ‘/’, ‘8080’)

n = 2000  
Benchmark.bmbm(20) do |b|  
b.report(‘Direct RPC’) { for i in 1…n;  
client.call(‘benchmark.simple’); end }  
end

* * *

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.

---

<div class="post-metadata">

**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\
**Post date:** [June 2, 2006, 8:36pm UTC](https://www.ruby-forum.com/t/webrick-on-windows/62295/2 "2006-06-02T20:36:15Z")

</div>

2006/6/2, Alex Y. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> end  
> client.call(‘benchmark.simple’); end }  
> from c:/ruby/lib/ruby/1.8/xmlrpc/client.rb:535:in `do\_rpc’  
> 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. 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).

Btw, why did you choose this subject?

Kind regards

robert

---

<div class="post-metadata">

**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\
**Post date:** [June 3, 2006, 10:59am UTC](https://www.ruby-forum.com/t/webrick-on-windows/62295/3 "2006-06-03T10:59:39Z")

</div>

Robert K. wrote:

> 2006/6/2, Alex Y. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):
> 
> > 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:
> > 
> > * * *

\>\> error during the second round. Looking at netstat -a afterwards, I see \> 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.

---

<div class="post-metadata">

**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\
**Post date:** [June 4, 2006, 9:53pm UTC](https://www.ruby-forum.com/t/webrick-on-windows/62295/4 "2006-06-04T21:53:25Z")

</div>

Francis C. wrote:

> Are you sure your connections are being closed after each call to  
> client.call(…)?  
> A quick hunt through the Net::HTTP code seems to indicate so. If I’m  
> reading it right, there’s a call to Net::HTTP::Post#end\_request which  
> closes the socket client-side.

> You may be hitting a per-process limit on open  
> descriptors. Are you running netstat while your process is running or after  
> it ends with the EBADF error? If the latter, then try catching EBADF and  
> put  
> in a long sleep, then look at netstat on a different shell. Localhost  
> connections don’t usually need to spend much time in the TIME\_WAIT state.  
> They are still alive, but vanish as soon as the process dies, which  
> would seem to indicate that either the call to close the socket is  
> wrong, or it’s not being respected.

–  
Alex

---

<div class="post-metadata">

**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\
**Post date:** [June 4, 2006, 11:41pm UTC](https://www.ruby-forum.com/t/webrick-on-windows/62295/5 "2006-06-04T23:41:14Z")

</div>

So while your process is still running, the connections are in  
TIME\_WAIT,  
and then they vanish as soon as your process dies? That means they are  
being  
closed as you expect. A closed TCP connection spends a little time in  
the  
TIME\_WAIT state, but as I said above, on a localhost connection it’s  
usually  
very short or zero. Try your program on an actual network connection to  
another machine. When your process ends, the TIME\_WAITing connections  
should  
NOT vanish, but will stick around for a short period of time (usually  
not as  
long on Windows as on Unix).

It that happens, it’s a sign that you should probably rethink your  
design.

---

<div class="post-metadata">

**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\
**Post date:** [June 3, 2006, 1:49pm UTC](https://www.ruby-forum.com/t/webrick-on-windows/62295/6 "2006-06-03T13:49:03Z")

</div>

Are you sure your connections are being closed after each call to  
client.call(…)? You may be hitting a per-process limit on open  
descriptors. Are you running netstat while your process is running or  
after  
it ends with the EBADF error? If the latter, then try catching EBADF and  
put  
in a long sleep, then look at netstat on a different shell. Localhost  
connections don’t usually need to spend much time in the TIME\_WAIT  
state.

---

<div class="post-metadata">

**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\
**Post date:** [June 5, 2006, 10:07am UTC](https://www.ruby-forum.com/t/webrick-on-windows/62295/7 "2006-06-05T10:07:20Z")

</div>

Francis C. wrote:

> not as  
> long on Windows as on Unix).  
> I’m not entirely sure I understand. If the sockets being in the  
> TIME\_WAIT state is a sign that they’ve been closed normally, why am I  
> running out of resources? Surely there isn’t a hard limit on the number  
> of sockets a process can _ever_ open?

> It that happens, it’s a sign that you should probably rethink your design.  
> See, that’s the problem. I’ve only put a very thin layer around stuff  
> that’s in the standard library, using code that’s directly inspired by  
> examples in the docs. If that’s wrong, I’m not sure where I should  
> begin to analyse it or attempt to improve it.

–  
Alex

---

<div class="post-metadata">

**Author:** ![regularfry](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@regularfry](https://www.ruby-forum.com/u/regularfry)\
**Post date:** [June 5, 2006, 11:18am UTC](https://www.ruby-forum.com/t/webrick-on-windows/62295/8 "2006-06-05T11:18:12Z")

</div>

Most kernels have hard and soft limits on the number of connections that  
can  
be in an any state, including TIME\_WAIT, but I don’t know what those  
limits  
are in XP Home. Have you tried making 1000 calls, then waiting for a  
minute,  
then making 1000 more, and so on? I’m proposing that as an experiment,  
not  
as a solution. I would expect that you’ll see the TIME\_WAITing  
connections  
drain out during the sleep interval. I’m still a little surprised that  
you’re seeing this with localhost connections though. By definition, the  
kernel knows the location of all the network segments in a localhost  
connection so it shouldn’t need to spend much time in TIME\_WAIT.

What’s the value of TCPTimedWaitDelay in your registry?