[ http://issues.apache.org/jira/browse/DIRMINA-119?page=comments#action_12359015 ]
Trustin Lee commented on DIRMINA-119: ------------------------------------- Users might not need to adjust the number of SocketIoProcessor in runtime. Letting user specify an appropriate number they like with the constructor will be fine for now. It would be great if there is any optimal number of processors for the number of CPUs. Any idea? > 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
