Selector cleanup
Rémi Forax
forax at univ-mlv.fr
Fri Jan 25 13:20:29 UTC 2008
Alan Bateman a écrit :
> Rémi Forax wrote:
>> ok, no valueOf(), i'm not an expert in Windows API.
>> But are you agree that class FdMap is not necessary.
> I agree and I assume you will replace it with an embedded Map. I
> suspect it will be hard to see a difference (with the server VM anyway).
i'am pretty sure to see no perf difference but it will use less memory.
>
>> yes, very hard to mesure until you span 1k thread with one selector
>> each.
> The typical NIO server tends to handle lots of concurrent connections
> so with a relatively small number of threads (one per core for
> example) and a small number of Selectors. It sounds like your server
> might be different. Selector creation is relatively expensive so you
> might run into issues there.
Selector are pre-created, during startup, so no problem.
We have observed that a selector doesn't work well with a lot of keys.
That's why i use more threads than one per core.
I have found someone else saying the same thing:
see http://blogs.sun.com/oleksiys/entry/multiple_selector_read_threads_in
>
>> btw if you take a look to EPollArrayWrapper, idlSet already use boxing.
> The idle set is almost always empty and an aside from one case, there
> shouldn't be any boxing when the set is empty.
I not agree, reading the code, idle set is used when setInterestOps(0)
is called.
I'm not sure that case is not frequent.
By example, you can found this code in grizzly:
// disable OP_READ on key before doing anything else
key.interestOps(key.interestOps() & (~SelectionKey.OP_READ));
see
http://weblogs.java.net/blog/jfarcand/archive/2006/06/tricks_and_tips.html
>
>> Do you have any idea when openjdk will be reopen ?
> Mark and others are working hard to make this happen very soon. As I
> understand it they have some infrastructure work to complete before
> they can allow changesets to be pushed.
>
>
>> My small server is a research project that embeds a non-blocking
>> parser in a webserver and
>> claims to have the same performance than grizzly. I will post a blog
>> entry about it
>> when all benchmarks will be finished.
> I look forward to it.
>
> -Alan.
Rémi
More information about the core-libs-dev
mailing list