This may be too obvious, but do you increase the number of processor threads on your multi-core machines? E.g.,
new SocketAcceptor(Runtime.getRuntime().availableProcessors(), new NewThreadExecutor()); -Greg On 3/30/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
Hi, Gaston, I forgot to tell that even if I use a faster server than the one where I ran the tests (the tests were conducted on a dual core intel based iMac), I get almost the very same resulst : no more than 2000 req/s (I also tested it on a 8 dual core CPU server). It looks like MINA itself can't handle more than this load (if we consider the application being super fast). I would expect better results, but may be some network tuning/MINA tuning is necessary. I'm not at all a network expert though... Emmanuel On 3/30/07, Gaston Dombiak <[EMAIL PROTECTED]> wrote: > > Hey Emmanuel, > > I'm not sure I understand your point or if there is a problem. :) I would > say that it is fine and even expected to find that most of your CPU time is > spent in MINA (or I/O work) if your application is super fast (e.g. does > not do much) and all you do is send and receive data to the server. > > However, if you see that MINA is slowing you down then the story is > different. But I don't see that from your stats. Or may be I'm missing > something. :) > > Regards, > > -- Gato > > -----Original Message----- > From: Emmanuel Lecharny [mailto:[EMAIL PROTECTED] > Sent: Friday, March 30, 2007 10:26 AM > To: dev@mina.apache.org > Subject: High latency in Mina ? > > Hi guys, > > I'm currently doing some performance tests on Apache Directory Server, and > I'm a little bit puzzled but some of the results I get. First of all, we > are > using MINA-1.0.1, with different JVM (JRockit, IBM, Sun) on different > platforms (Linux, Mac OSx). > > The tests is quite simple : I have some Ldap clients (a very simple > injector > which binds, launch N threads and for each threads launch P searches > requests). I cannot go farther than 2000 requests/s... > > I have added some timer in the code, and I have been very surprised to see > that ADS itself does not cost that much. In fact, we have 3 importants > parts > : > 1) decode a message > 2) handle the message > 3) encode the response > > The sum of those three operations just cost less than 10 percents of the > global cost for the operation to be fullfilled. (so an operation cost > around > 0,5 ms, and only 10 micro seconds into ADS). MINA cost 0,490 ms alone. > > To be sure, I added a loggingFilter, and I computed the duration of a > message processing (I added some info in messageReceived and messageSent : > as a Ldap message may be sent in more than one piece, and so is the > answer, > I consider the last time for a message sent compared to the last time a > message has been received, so I compute the date when thelast bit has been > sent minus the date when the first bit has been received). > > Here is what I get (all the number are in nanoseconds, and they have been > computed using an accumulator, printed every 1000 messages) : > > Delta write = 4925 > Encode cost : 944 > Delta write = 6613 > Decode cost : 1656 > Search cost : 44239 > Delta write = 2263 > Encode cost : 1062 > Delta write = 2893 > Delta write = 5544 > > Mina costs 872 051 (including all the above, 70 138 ns). Ok, those number > are just given as an example, but what we see is that MINA represent 90% > of > the total cost. > > I have done this test on my desktop, with a client on my desktop, or with > a > client on another desktop (100 Mb/s ethernet). The volume of transfered > data > is not enormous, it's around 1kb per message, so for 2000 messages per > second, it's around 16 Mb/s, far under the maximum network capacity. The > sockets are never closed, and no new threads are being created. > > Ok, I have reached my limit, I don't know MINA enough to go farther ... > Any > advice? Any clue? > > Thanks very much for any help ! > > PS: the code is of course available on > svn.apache.org/repos/asf/directory/apacheds/trunk > > -- > Cordialement, > Emmanuel Lécharny > www.iktek.com > -- Cordialement, Emmanuel Lécharny www.iktek.com
