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)
Hmm...I looked into this...the limit of 64 is a MS compile-time thing
... and in APR it appears that the constant is actually being re-defined
to 1024 for WIN32 in the poller code. Hence I would not expect that
under Windows this would actually be too much of an issue...1024 sockets
per poller doesn't seem an unreasonable idea... in which case (if true)
the performance implication of having a small number of poller threads
is completely dwarfed by the DoS performance issue I have raised here.
Be that as it may, this is a digression from my main issue...
I think APR is by far the best technology for implementing Servlet 3.0,
but I'm not so sure beyond that. The Vista+ enhancements need a new
major version of APR, so it will take some time (too much IMP).
Yep - we have to work with what we've got... (Sidebar: to your
knowledge is there a working implementation of Servlet 3.0 yet in JBoss?)
The default value of deferAccept is true, but on Windows this option is
not supported in the TCP/IP stack, so there is code that falsifies the
flag if this is the case. In which case, the socket is added straight to
the poller. I'm happy with that approach anyway. But, the act of
getting it across to the poller - which should be a relatively quick
operation (?) requires the use of a worker thread from the common pool.
This gets back to my original point. If the new connection could be
pushed across to the poller asap, (without handling the request), and
without having to rely on the worker threads, then surely this is going
to degrade more gracefully than the current situation where a busy
server is going to leave things in the backlog for quite some time.
Which is a problem with a relatively small backlog.
Yes, but (as I said in my previous email):
- Poller.add does sync. This is bad for the Acceptor thread, but it
might be ok.
- Socket options also does SSL handshake, which is not doable in the
Acceptor thread.
So (as I was also saying) if there is no SSL and deferAccept is false,
it is possible to have a configuration option to have the Acceptor
thread set the options and put the socket in the poller without using a
thread from the pool. That is, if you tested it and you found it worked
better for you.
I might give that a try...I'm less concerned about SSL as I would not
anticipate SSL connection floods in the scenarios I'm considering.
Otherwise, even with Poller.add doing a sync, surely that is still
generally an improved situation versus having to contend for worker
threads to get the connection open?
Also, you are supposed to have a large maxThreads in the pool if you
want to scale. Otherwise, although it might work well 99% of the time
since thread use is normally limited due to the poller for keepalive,
it's very easy to DoS your server. BTW, it's rather cheap (on Linux, at
least ;) ).
You're quite right...with a small number of Worker threads, as things
stand it would be easy to get DoS for /new connections/...that is
exactly my point. I'm specifically looking at Comet situations
here...large numbers of long-lived connections potentially.
But I wouldn't want maxThreads to be more than a few hundred to service
several thousand connections...that was one major reason for using NIO/APR.
In the Tomcat branch, there is code to have multiple acceptor threads,
That stuff wasn't really implemented. I don't think it's such a good
idea to be too efficient to accept and poll, if all it's going to do is
blow up the app server (which would probably be even more challenged by
the burst than the connector). The network stack is actually a decent
place to smooth things out a little (or you could implement a backlog as
part of the accept process).
Maybe. I agree the network stack is not a bad place to handle it, except
for the fact that stupid Windows wants to send a reset if the (size
limited) backlog fills. If you implement an applic backlog on top of
the O/S backlog, to me that is much the same as moving it straight off
to the poller...just a question of which queue it sits in.
I'll see if I can hack the AprEndpoint to test out what would happen.
Cheers,
MT
