directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dave irving (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRMINA-119) Multiple selector loops
Date Wed, 09 Nov 2005 10:15:20 GMT
    [ http://issues.apache.org/jira/browse/DIRMINA-119?page=comments#action_12357117 ] 

dave irving commented on DIRMINA-119:
-------------------------------------

My proposed change wouldn't solve your particular problem.
Although it raises a further question: Maybe the best level of abstraction for the threading
model is at the SocketIoProcessor level (I.e, a SocketIoProcessor has a selector and a selector
loop), but we can potentially have multiple processors.

The reason I didn't do it this way in my prototype is that I wanted to keep refactoring to
a minimum just to see if there was any support for the idea (and the easiest way was to bodge
it in to SocketIoProcessor).

If we do the thread modelling at the SocketIoProcessor level, you could then have a ProcessorFactory
or whatever.
This would enable any-old custom logic to map processors to SocketSessions.

Hmmmm - getting more complex though, and a wider ranging change :o)

Trustin?

> Multiple selector loops
> -----------------------
>
>          Key: DIRMINA-119
>          URL: http://issues.apache.org/jira/browse/DIRMINA-119
>      Project: Directory MINA
>         Type: Improvement
>     Versions: 0.9
>  Environment: All. Benefit is dependant on environment
>     Reporter: dave irving
>     Assignee: Trustin Lee
>     Priority: Minor
>  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