Hi Mladen...I'd be also be interested in your thoughts about the main
aspect to my question concerning JBossWeb behaviour with APR in regards
to new connection establishment. Specifically, because on Win32 the
backlog queue is limited to 200, it's easy to get not very graceful DoS
behavior to a relatively small flood of new connections if the worker
threads are all rather busy, because a worker thread is needed to get
the connection open. Assume that SSL is switched off. I proposed that
the socket should be moved over to the poller straight away (with a
deferred accept on the actual request) and that this be done in the
context of the acceptor thread? Cheers...MT
Mladen Turk wrote:
Remy Maucherat wrote:
Why is poller performance bad in Windows? Is that a consequence of the
I've been told it uses select, which works only on 64 sockets at a time.
So if you have a large poller, then the poll call performance degrades.
Mladen is really the only one who can answer Windows questions.
(personally, I think it is a lot cause for really high scalability)
Well, we are forcing it to 1024 by setting the FD_SIZE before
including the socket.
Anyhow, this still requires multiple poller threads.
The Vista+ windows has WSAPoll which is equivalent even on
the API level to unix poll, and it doesn't bring any limitation
on the pollset size. I've tested it with 32K sockets, and there
is no performance degradations caused by the size like there is
on the select implementation.
I've added the WASPoll support to APR2, but there are some
other things with APR2 that are still to be resolved before we
can create tomcat-native 2. It merged with apr-util and introduced
feature modules, so instead one it might end up with tens of dll's.
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
