directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Panicker <>
Subject Re: [mina] Performance issues
Date Thu, 24 Mar 2005 16:12:54 GMT
On Thu, 24 Mar 2005 09:03:41 -0500, Berin Loritsch
<> wrote:
-- snip --

> > 1. No backlog support currently provided with IoProtocolAcceptor
> This is something that the blocking sockets do for us.  Essentially it
> amounts to just not responding to a socket until we are done with
> another.  There should also be a timeout to simply kill the connection
> if it has been in the backlog too long.

I doubt we can configure a timeout.  Dunno if its there in TCP - maybe I forget

-- snip --

> > 3.  Client/Server CPU usage.  The number of connections per second
> > steadily keeps decreasing as the total connections increase.  Client &
> > Server both are at 100% CPU.  That is what is weird.  I'm aiming to
> > isolate the problem.  I'm currently a bit doubtful about the way the
> > Connector works, but wont be able to point out anything concrete until
> > more permutations & combinations are tried.
> A couple of thoughts here.  First it is normal for the number of
> connections per second to decrease as the total connections increase.
> The key here is how quickly it decreases.  Ideally we would have a
> smooth taper off of connections per second instead of an abrupt drop.
> That means the system scales well.  Secondly, the 100% CPU cycles can be
> a symptom of how you are running your loops.  I have found that calling
> Thread.yeild() will sometimes allow another thread to run, and sometimes
> not--on the same system.  No matter what, the processor is still pegged.
>  The next question to ask is how often do we need to poll, really?  I
> find that even the process of forcing the loop to sleep 1 millisecond
> between iterations will greatly reduce the load on the processor.  In
> the life of connection times the loss of a millisecond is nothing, the
> the reduction in stress on the CPU is tremendous.  It helps the CPU stay
> busy with real work.  Same thing with game loops.  If you draw a new
> screen each iteration you might have 200+ FPS but your processor will be
> busy doing work that you will never truly appreciate.

Due to this problem, I've stopped using the MINA based client of mine.
 I'm using a normal blocking IO client right now and it doesnt exhibit
this behaviour.  On Monday, will be coding a NIO based single-threaded
client that will be a more effective comparison with MINA.  Am aware
of all the points you have stated.

> > I'm expecting that MINA should be able to take 100K connections on the
> > server.  It cant go over 65K for the client due to lack of available
> > port numbers.
> Thats where multiple clients come in to play.  Quick question, are you
> checking the number of sustained client connections or the number of
> connection requests?

Yes of course.  If you see my latest update, the sustained (concurrent
connections) stayed around 85K, whereas the total number of
connections accepted have even gone up to 95K.  And yes, multiple
clients are being used for this due to the 64K limit.

> > When I ran a test for file descriptors, the Linux/FreeBSD boxes could
> > easily allocate up to 262144 FD's (I stopped testing at this number).
> > The Windows box gets limited to a bit over 100K - maybe I can get
> > around that as well.
> I'm not sure how you are handling threading, but on normal user accounts
> with Linux there is a limit of 500 threads/processes total for that user.

Can be upped to ridiculous figures :)  and have been done.  Also, I
remembered that the Windows box fd limit had not been tested.  Will do
that on Monday too.  But I've seen 100K+ file handles being used on my
box when I was running the initial tests on the client.

> Thanks for the update.  Its very encouraging.

The real fun will be coming when I start with the throughput tests. 
That will definitely show the real power (or lack thereof) of NIO. 
Which gets me to the question, how can throughput be effectively

Guys, repeating the call for suggestions for the benchmark suite for
MINA to make it as real-world a test as possible.


View raw message