Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I wrote a blog entry on how one of our connectors was developed the
challenges you face doing that.
Its not super technical as I'm saving the juicy details for ApacheCon
And since no one reads my blog, I'll let you guys get it from here :)
http://blog.covalent.net/roller/covalent/entry/20070308
Ok, I did read it in detail. Really good results since it has only 1GB
of RAM (did I read it right ?).
There is an area of the AprEndpoint that needs to be fixed before it
happens though, currently the "Acceptor" thread in APR does this
long socket = Socket.accept(serverSock);
if (!processSocketWithOptions(socket)) {
Socket.destroy(socket);
}
The processSocketWithOptions is a blocking call, hence you wont be able
to acccept new connections as long as your worker threads are all busy.
What we need to do, is set the socket options, then simply add the
socket to the poller waiting for a read event, the poller will assign it
a worker thread when one is available and the socket has data to be read.
I don't really believe in this sort of solution (especially since APR
uses deferred accepts automagically). For sure, I am against always
adding the socket to a poller right away, this would be most likely be
useless overhead. If there are no threads available, then using the main
poller could be sensible, but it could be more productive (and easier)
simply adding the socket to a structure containing longs and processing
it later.
If using a poller all the time, you can try a test where you bombard the
server with HTTP/1.0 requests - no keep-alive - and it would most likely
perform somewhat worse due to the poller overhead (could be worth
measuring).
I will contact you before I run the test to make sure I got everything
configured, I see
But before ApacheCon I will have those numbers, as in my presentation I
will focus on APR and NIO, the old connector is not of that much
interest anymore :)
I am not sure blocking IO is bad, actually. It's very easy to program,
and IMO it could work quite well in the future with the exploding amount
of CPU cores and smarters OSes, the only remaining issue being the
higher memory usage due to the resource usage of a thread (most likely
this could be fixed as well).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
