[ECOS] Idle timeout and maximum # of sockets for athttpd

[ECOS] Idle timeout and maximum # of sockets for athttpd

[Øyvind Harboe]

> > I don't quite understand CYG_HTTPD_SOCKET_IDLE_TIMEOUT
> > in detail, but it is hardwired to 300 seconds which appears to be
> > rather long for the default maxim # sockets (16).
>
> The time of 5 minutes before an inactive socket is closed was
> chosen without much concern to the maximum number of
> sockets. Its intentions were mainly to close sockets that have
> been inactive for more than 5 minutes, regardless of the reason:
> In other words I felt that with persistent connections (and very
> few sockets available to begin with) it is important to reclaim
> any and all resource you might think are not actively used.
>
> The sockets might be dead, or the user of the client might just be
> enjoying a sandwich before she comes back surfing: Either way
> if the socket is idle for 5 minutes I want to be able to reclaim it for
> connections that actually carry some traffic.
>
> We can make a case for making this a CDL option..

I hate options :-) I guess if it was to be an option I would like to
have a minimize # of
sockets option.

> > Could CYG_HTTPD_SOCKET_IDLE_TIMEOUT be set to 0?
> > What would happen?
>
> I can interpret this question two ways:
>
> 1) CYG_HTTPD_SOCKET_IDLE_TIMEOUT equal 0 means that
> there is no timeout (i.e. remove the call to
> cyg_httpd_close_unused_sockets(). In this case the sockets will
> be opened forever. You are now at the mercy of the stack to
> determine that a socket is dead. Might work, but I have not
> experimented with it. Now, your delay is even more hardcoded
> (this time inside the stack itself.)
> 2) CYG_HTTPD_SOCKET_IDLE_TIMEOUT is active and equal 0
> in which case, with the current code you would effectively resort
> to closing each connection after the request was served. In other
> words, you void the advantages of persistent connections by
> reverting to HTTP 1.0. If you think 16 sockets are not enough
> with persistent connections you will hate the alternative, where a
> single web page with a lot of pictures can exhaust the number of
> sockets.

Is there a reason I would not want to minimize the # of sockets used?
I guess athttpd would
typically be used for some sort of logging/configuration server.
Performance is not so
much an issue at that point.

The minimum # of sockets would then presumably be with
CYG_HTTPD_SOCKET_IDLE_TIMEOUT  being somewhat near the length
of processing a request. 5 seconds seems like a reasonable default at
that point...


-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Idle timeout and maximum # of sockets for athttpd

[Anthony Tonizzo]

Oyvind:


> I hate options :-) I guess if it was to be an option I would like to
> have a minimize # of
> sockets option.

Not quite sure how you want to achieve that. By the patches you yourself
have submitted, you are by now pretty familiar with the way sockets are
handled and disposed. The only way to mnimize sockets is to use persistent
connection, and that is something that is already there by virtue of HTTP 1.1
support. It does make a huge difference because, as I said, a single request
was all it took to freeze older HTTP 1.0 versions of atHTTPD. At this point,
assuming that you do not use the CYG_HTTPD_MODE_CLOSE_CONN
flag too often, the number of sockets used is only dependent by how many
different clients connecto to the server.

> Is there a reason I would not want to minimize the # of sockets used?
> I guess athttpd would typically be used for some sort of logging/configuration
> server. Performance is not so much an issue at that point.

For a web server used only for configuration you are certainly capable of
dropping the number of sockets.

> The minimum # of sockets would then presumably be with
> CYG_HTTPD_SOCKET_IDLE_TIMEOUT  being somewhat near the length
> of processing a request. 5 seconds seems like a reasonable default at
> that point...

That would not work, unfortunately. When you close() a socket, that socket
is not returned to the pool right away. The stack (or, to use the
lastest Microsoft
buzzword, the "TCP Chimney", I am not kidding you!) holds on to it for a couple
of more minutes to make sure that stray data is not still in the wire (back when
the giants walked the earth, TCP connections could take that much to deliver the
goods...) This time, spent by the stack waiting, is on top of whatever time you
set for CYG_HTTPD_SOCKET_IDLE_TIMEOUT.

During this time you better have some spare sockets available, otherwise
the whole thing will freeze until a socket _is_ finally relesed. Your
request, which
has been pending since it was received, is now going to be served, but you are
not going to like the constant waiting.

Because of all this, I have always found that 16 sockets are not a bad number
at all. Once you have opened all your files, there is still enough
left for a few
HTTP connections.

Cheers!
Tony

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Idle timeout and maximum # of sockets for athttpd

[Øyvind Harboe]

[the awful truth deleted]

Now I understand the awful truth. I wonder if there is anything that
could be done
to clue other athttpd users onto that they need to increase # of
sockets to avoid
the waiting problem....


-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Idle timeout and maximum # of sockets for athttpd

[Tom Deconinck]

On Dec 13, 2007 4:14 PM, Øyvind Harboe <oyvind.harboe@zylin.com> wrote:
> [the awful truth deleted]
>
> Now I understand the awful truth. I wonder if there is anything that
> could be done
> to clue other athttpd users onto that they need to increase # of
> sockets to avoid
> the waiting problem....
>
>
> --
> Øyvind Harboe
> http://www.zylin.com - eCos ARM & FPGA  developer kit
>
> --
>
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

Hi,

Just a thought: maybe you can disable the socket linger timeout (=the
time it waits to completely close a socket).
I've done it in the past on Linux, so I don't know if you can do it
with the eCos networking stack.
Or you can try resetting a socket when you know it's closed, it's a
violation of normal way of working, but if it does the trick...

Tom

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Idle timeout and maximum # of sockets for athttpd

[Øyvind Harboe]

I don't quite understand CYG_HTTPD_SOCKET_IDLE_TIMEOUT in detail, but
it is hardwired to 300 seconds which appears to be rather long for the
default maxim # sockets (16).

Issuing 8 or so http requests, e.g. via wget, in rapid succession will
cause the server to
sit there for a while before recovering. No requests appear to be
dropped on the floor,
but if there is no response from a server on the LAN within 30 seconds
it will be very hard to
distinguish that from a crashed server for most users. Servicing an
actual request takes << 1 second
in my tests and by increasing the maxim # of sockets to 64, the
athttpd appeared quite robust. Still
it is possible to overflow it, but the by the time it has overflowed
I'd expect sockets to start getting
freed again...

Any thoughts?

Make CYG_HTTPD_SOCKET_IDLE_TIMEOUT configurable via cdl w/default being some
multiple of maximum # of sockets?

Could CYG_HTTPD_SOCKET_IDLE_TIMEOUT be set to 0? What would happen?

-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss