Hi,

This is maybe a suitable thread for me to discuss some of the performance
analysis that I've just started doing.

We are using MINA for an application that ideally requires both high
throughput and low latency. We use MINA both for clients and for servers.

SocketIoProcessor observations:

A given SocketIoProcessor will flush all the bytebuffers in the write
request queue for all sessions handled by that SocketIoProcessor. This
means that if a client makes a lot of requests to a server and therefore
fills up the writeRequestQueue for the session, and is expecting responses
from the server for those requests, the latency experienced on the first
requests is high simply because it doesn't start doing reads until the
queue is emptied (assuming the kernel buffer does not fill up).

In addition, the fact that a single thread is responsible for doing reads
and writes on a given socket means that you cannot do concurrent reads and
writes on a socket.

I think it would therefore be worthwhile having 2 threads per
SocketIoProcessor in order to improve latency for "highly active writers".

I have done some very quick and dirty hacking of SocketIoProcessor to do
this and it does appear to improve latency significantly in this type of
case. I do need to do more testing of this however.

I have also implemented an "AIOSocketIoProcessor" using the IBM alphaworks
aio package (which is not open source but useful nonetheless to determine
whether it is worth building an AIO library). Even using the naive
threadpool that comes by default with the IBM library, latency was improved
significantly on win32. I was going to do further testing with the IBM AIO
library but unfortunately it doesn't support the linux version we run on
our larger boxes (RHEL 3). Does anyone know of any other AIO libraries for
Java?

Minimising Copying:

One of the operations our servers do is take in data and retransmit it
unmodified to a number of subscribers as quickly as possible. Therefore
minimising copying of data is important for us.

We are using the cumulative protocol decoder and currently there is quite a
lot of copying going on:

In SocketIoProcessor:
* Allocate a buffer of size "read buffer size" (then read bytes from the
network)
* Allocate a buffer of size "bytes read from network" and copy data just
read into it, before passing it to the filter chain
In CumulativeProtocolDecoder:
* Allocate a buffer of "initial capacity" which can autoexpand (side
comment: should this not be the higher of "initial capacity" and the size
of the buffer passed in since if the buffer passed in is bigger than
initial capacity it will just force an expansion immediately in the next
step?)
* Copy the data read from the network into the just-allocated buffer
* If you want to use a subset of the buffer in the ProtocolDecoderOutput
this is tricky unless you copy the data
* compact the session buffer

I was not aware of DIRMINA-165 so I implemented my own (again quick and
dirty) slice() function on ByteBuffer (creating a "SlicedByteBuffer"
subclass of ByteBuffer that handled the ref counting). This worked although
I have not done much performance testing yet since I am about to look at
what I call "ChainedByteBuffer": in order to get rid of the copying
completely I think a byte buffer that is comprised of one or more smaller
byte buffers but from the caller's perspective looked like one byte buffer
would be one solution (and writing these out using writev). Does that sound
like a good idea?

We are going to be doing performance testing with larger numbers of
connections (e.g. 500) later this month and I will report on my findings.

I would be interested in people's comments on my findings and analysis so
far.

Robert


                                                                                
                                                      
                      "Trustin Lee"                                             
                                                      
                      <[EMAIL PROTECTED]        To:       
[email protected]                                                
                      m>                       cc:       "Apache Directory 
Developers List" <[email protected]>, "Ofer         
                                                Kalisky" <[EMAIL PROTECTED]>    
                                                
                      25/02/2006 08:47         Subject:  Re: Performance in 
MINA                                                      
                      Please respond to                                         
                                                      
                      mina-dev                                                  
                                                      
                                                                                
                                                      
                                                                                
                                                      




Hi Ofer,

I apologize for this late reply first of all.

On 2/9/06, Ofer Kalisky <[EMAIL PROTECTED]> wrote:
>
> I'd like to use the MINA for a server that serves TCP connections (let's
> say
> something simple - holds connections and sends them notifications about
> events). What are the numbers for performance such a project?


There's no exact numbers for MINA yet.  You'll have to try by yourself even
though most users say that it performs good and is very reliable.  We're
going to do some performance test at least before we release 1.0.

Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6





This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein 
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries 
and affiliates.

Reply via email to