Le mercredi 18 octobre 2006 à 14:40 +0200, Frédéric Brégier a écrit : > Oups ! I hope my last answears on the same kind of > subject was not too buggy... > (see [MINA 1.x] IoThreadPoolFilter & ProtocolThreadPoolFilter). > > So if I try to make a resume (I love this word since it is in my mother > tongue) :
On dit "mother language" en anglais, "tongue" c'est pour l'organe, Attention au sens de ta phrase ;) > First, we don't need to specify any thread pool in: > IoAcceptor acceptor = new SocketAcceptor(); > (but here we have 16 threads by default, and if we have > 16 processors ?) Exactly default Executor is : new ThreadPoolExecutor(16, 16, 60, TimeUnit.SECONDS, new LinkedBlockingQueue() ) > Second, no need to use ThreadModel.MANUAL. > Third, inserting a threadpool filter is useless if set before. > OK. > > One more question to set a more accurate Executor: > 1) The ExecutorThreadModel API says : > "public void setExecutor(Executor executor) > Changes the underlying Executor of this model. Previous settings such as > the number of threads should be configured again. Only newly created > IoSessions will be affected." > 2) Also the default ExecutorFilter inserted by Mina uses 16 threads but > there is a constructor with an Executor as parameter. > > I try to read from API or code, but I must admit that I was not able > to fully understand how to set up my own ThreadModel. > My 2 cents would be to define it through ExecutorThreadModel.setExecutor, > but is this correct ? I think so, try instantiations like "new ThreadPoolExecutor(16, 16, 60, TimeUnit.SECONDS, new LinkedBlockingQueue() )", tuning size of the pool (first '16') and max pool size (the second '16' value). > > To add some information on my project : > For the moment, I am not ready to test my project on big servers, > but I should be able to do so in about 6 months on a 16 to 32 > processors server (Power5 AIX5.3). > The project is about something like a file server with about > 2^64 files and 200 000 users. Sound very interesting feedback on MINA behaviour on this configuration. > I check every day the mailing list to find how people say they improve > their performance in order to do some right choice already from now. > I saw the heap buffer, another mail on thread performance, > and of course on JDK 1.5. > I look in the code of Mina and saw a lot of "synchronized" that > many benchmarks (outside Mina) report this is less efficient than > native concurrent version. > I know that Mina start from 1.4, so I understand clearly > the reasons why. > I saw a lot of HashMap that should be easily changed to > ConcurrentHashMap, removing the unecessary synchronized > and using backport in the mean time for people not in JDK 1.5. > If I had some time, I will try on a copy of Mina to see if it works > and how. > Also, the main BlockingQueue in mina.util, even if it is not so simple, > coule be changed to a ConcurrentLinkedQueue or so > (I try and it was not working with some exception but no time > to investigate further). > Sure, with integration of the j.u.concurrent backport dependency we have a new space of optimization for MINA, but it's a pretty young integration. Julien
