directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niklas Therning (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRMINA-119) Multiple selector loops
Date Thu, 01 Dec 2005 15:21:31 GMT
    [ http://issues.apache.org/jira/browse/DIRMINA-119?page=comments#action_12359045 ] 

Niklas Therning commented on DIRMINA-119:
-----------------------------------------

There could be a default singleton SocketIoProcessorPool: SocketIoProcessorPoolImpl.getDefaultInstance()
which is used by all SocketIoAcceptor/Connector instances by default.

One question: why do we need associateProcessor(IoSession s)? Couldn't it just have a getIoProcessor()
method? SocketIoAcceptor/SocketIoConnector would get a processor using this method and give
it to the SocketSessionImpl when constructed.


> 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: prototype.zip
>
> Mina's SocketIoProcessor currently owns a Selector and employs a single Worker 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 encounter 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 associated Selector
> - It should be possible to configure the number of Workers (and thus selectors) employed
by SocketIoProcessor
> - When a SocketSession is added to the SocketIoProcessor, a Worker is selected (round-robin)
which will be associated with the SocketSession for its lifetime. This association is managed
by SocketSession (get/setWorker)
> - When someone asks SocketIoProcessor to do some work to a session, instead of doing
it directly, the processor now asks the session for its Worker, and delegates to the worker
(i.e, the same worker is always used for an individual session)
> I've done some prototyping, and have also checked that the concept works with the latest
build.
> The prototype is very hacky - mainly because there are some refactoring issues i'd like
feed-back on before I submit a "proper" patch for review. Namely:
> - How do you want me to tell the SocketIoProcessor how many workers to use? One option
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 function 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 get the param in. We could refactor, or maybe introduce
a ProcessorOptions class or something. The SocketIoProcessor 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/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message