correct, only 1GB of RAM, -Xmx512m for the Tomcat container.
Filip
Remy Maucherat wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
