Hi, comments inline
On Fri, 11 Jul 2008 08:42:37 +0530 "ravinder singh" <[EMAIL PROTECTED]> wrote: > Hi, > > Following are my requirements from MINA: > > 1. Around 10k concurrent persistent connections. > 2. Message receive rate approx: 1000 msg/sec > 3. Message sent rate approx: 20 times receive/input rate. > > I am sure that MINA can handle this rate... right? > > Currently I am using MINA 1.1.0 but have never done any performance > run on that. > We are trying to make some changes on server side so I thought it > will be good if we can migrate to > MINA 2.0 (should require only 1-2 hr as we haven't customized > anything in that). > > Before doing this I need to clarify a few doubts: > > 1. Is MINA 2.0 (M2 or any other release) production ready ? Well no it's not a stable release in term of API. That mean for M3 you will probably need to change your code. Anyway I use it in prod, knowing for upgrade I'll need to change your code. > > 2. What should be the right input & output buffer size (Messages can > vary in size, so we are using > \n as delimiter, hence currently using TextLineCodecFactory. Does > size matter here?) There is no rule of thumb for that, I think the best is to try to find a value that are fitting the average data size and do tests for finding the best value. > > 3. Configuration of Thread-pools is removed in MINA 2.0, so I think > it will internally manage the whole thing efficiently... right? Right by default your Aceeptor is created with the best know configuration, anyway if you need you can override those values. > > > It would be great if anyone can help me in this... It's very urgent > for me (need to get the service live on Monday)... > > Any suggestion regarding the configuration (s/w or h/w[current is > Linux box, 64-bit, 16GB RAM, Java 6.0....]) I should use will be a > added advantage... :) From my tests, Sun 1.6 JVM is the fastest for MINA applications. Then the size of the iron will be dependent of your business code too :) Julien > > Thanks!
signature.asc
Description: PGP signature
