help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] keep-alive throttling


From: Paolo Bonzini
Subject: [Help-smalltalk] keep-alive throttling
Date: Fri, 24 Jul 2009 09:51:14 -0400
User-agent: Mutt/1.5.11

Hi all,

on the GNU Smalltalk mailing list a user experienced problems with
Swazoo failing to accept connections due to an EMFILE error.  This
can be reproduced both with real users (25-50 are enough with cold
cache) or with automated scripts.  Swazoo will have more than 1000
open sockets, even though those are sleeping (and they are not
closed, likely, due to Keep-Alive).

The problem in my opinion is that Swazoo does no throttling of
incoming requests.  These should be done in three ways:

1) the accepting loop at HTTPServer>>#start should never create more
than a few dozen clients.

Besides, upon failing to accept a client, some kind of exponential backoff
should be added to avoid repeatedly falling prey of the same EMFILE error.

2) the Keep-Alive header sent by the client is trusted completely in
HTTPConnection>>#keepAliveTimeout.  Mozilla sets it to five minutes,
which is totally unrealistic and should be configurable---by
setting a high timeout, clients will benefit from a quicker response,
on the other hand Apache children would be tied up waiting for clients
when they could be servicing new clients.

3) the Keep-Alive time is always computed from the last request rather
than the first.  This means that you need another knob to limit the
number of requests on a single connection, or else (because of 1
above) you may have a few clients sucking resources from your server
forever forbidding new clients to connect.


If you don't want to have fixed knobs, like 2 and 3, failure to accept a
client could trigger some kind of reaping of dormient Keep-Alive sockets.
This is harder to implement however, and "living on the edge" of available
file descriptors is dangerous because a file server might fail to open
files for the same reason.  So I think this should not be done.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]