[ http://issues.apache.org/jira/brows...NA-119?page=all ]

Trustin Lee resolved DIRMINA-119:
---------------------------------

Resolution: Fixed

I checked in your patch after some modification.  It works great.   Thanks f
or the great job!

> Multiple selector loops
> -----------------------
>
>          Key: DIRMINA-119
>          URL: http://issues.apache.org/jira/browse/DIRMINA-119
>      Project: Directory MINA
>         Type: Improvement
>     Versions: 0.8
>  Environment: All. Benefit is dependant on environment
>     Reporter: dave irving
>     Assignee: Trustin Lee
>     Priority: Minor
>      Fix For: 0.9
>  Attachments: multipleIoProcessors.zip, multipleIoProcessors.zip, prototyp
e.zip
>
> Mina's SocketIoProcessor currently owns a Selector and employs a single Wo
rker to run the NIO "selector loop".
> I have been running tests where Im trying to maximise throughput and have 
found - that in certain multi-cpu environments - this worker thread can enco
unter a large amount of starvation even though CPU usage is fairly low.
> By testing 2 selector-loops instead of 1, I managed to improve my overall 
test throughput by just under 30%.
> The general idea is to do this:
> - Each SocketIoProcessor.Worker encapsulates its own work queues associate
d Selector
> - It should be possible to configure the number of Workers (and thus selec
tors) employed by SocketIoProcessor
> - When a SocketSession is added to the SocketIoProcessor, a Worker is sele
cted (round-robin) which will be associated with the SocketSession for its l
ifetime. This association is managed by SocketSession (get/setWorker)
> - When someone asks SocketIoProcessor to do some work to a session, instea
d of doing it directly, the processor now asks the session for its Worker, a
nd delegates to the worker (i.e, the same worker is always used for an indiv
idual session)
> I've done some prototyping, and have also checked that the concept works w
ith the latest build.
> The prototype is very hacky - mainly because there are some refactoring is
sues i'd like feed-back on before I submit a "proper" patch for review. Name
ly:
> - How do you want me to tell the SocketIoProcessor how many workers to use? One op
tion is a system property - but thats pretty hacky. I dont think we need to support 
changing the number of workers after operation has begun (It'll probably be a functi
on
of the number of available CPUs) - and this makes the code simpler. However,
 as SocketIoProcessor is a (non lazy created) singleton, we need a way to ge
t the param in. We could refactor, or maybe introduce a ProcessorOptions cla
ss or something. The Socket
IoProcessor could interrigate this when initializing. Any direction on your desired approach
 would be appreciated
> Cheers,
> Dave

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ Post a follow-up to this message ]