[ http://issues.apache.org/jira/browse/DIRMINA-119?page=all ]
dave irving updated DIRMINA-119:
--------------------------------
Attachment: multipleIoProcessors.zip
First attachment was empty... Sorry :o)
> 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,
> 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
