Performances questions

[yann Blazart <ya...@gmail.com>]

Hi ! I try to code a replacement of rmi using mina.

In Jdk 5 Rmi take 0.16 ms to make a remote call, but with my mina
implementation I had 0.89 ms !

So I spiciest my own way of coding and made a simple test : a client that
send a string to server (10000 loops)

One call take 0.12 ms !

 If a make the client wait for the server response the average call time
take 0.44ms.

Is it normal that mina is so long ?

Re: Performances questions

[yann Blazart <ya...@gmail.com>]

Thanks for the url, but I prefer to code my solution, spring must be good,
but I don't like the big-swiss-knives framework, I have the feel to use a
buldozer to take a flower...


My framemork will do a little bit more than rmi:

- Object assigned to a client can be shared/pooled or other things (thanks
to IoSession !)
- Life cycle
- Auto detection of serveur on network (broadcasting)
- no need of registry.
and so on.




On 4/5/07, Maarten Bosteels <mb...@gmail.com> wrote:
>
> On 4/5/07, yann Blazart <ya...@gmail.com> wrote:
> >
> > Thanks !
> >
> > My use case is to provide a framework to make a replacement of Rmi for
> > internal use in entreprise (RAD) without the f... problems of registry
> > SecurityManager and codebase and Remote interface.... , based on Mina
> > (very
> > fun framework you've done !)
>
>
> If you just want a replacement  for RMI you should take a look at the
> Spring
> Remoting options:
> http://www.springframework.org/docs/reference/remoting.html
>
> They make it very easy to remote a POJO and solve a lot of the problems of
> RMI.
>
> But if scalability is your main concern, MINA will probably be a better
> solution :-)
>
> Maarten
>
>
> I will try to improve my framework (called Roc),  code a specific codec
> and
> > make a bench under heavy loading against Rmi, I will send to this list
> the
> > conclusions of my benches.
> >
> > Thanks a lot !
> >
> > On 4/5/07, Vinod Panicker <vi...@gmail.com> wrote:
> > >
> > > On 4/5/07, yann Blazart <ya...@gmail.com> wrote:
> > > > Hi thanks for your answer, but I 've tried to set the tcpNoDelay to
> > > false on
> > > > each side and I didn't saw any really performance improvment.
> > > > The first problem is that if I test by only sending message but not
> > > waiting
> > > > for response, mina take 0.12 ms per call, aigainst Rmi that take
> 0.16ms
> > > per
> > > > call with the response. Is NIO slower than BIO, but more robust ?
> > >
> > > I guess you can say that NIO is more efficient that BIO in most cases.
> > > Usually servers need to handle lots of concurrent connections and
> > > that is where NIO really shines.  In your use case, if you have just a
> > > single server and client and if there is no cpu starvation for the
> > > threads, it is not at all surprising to see better performance from
> > > BIO.  In fact, due to recent OS level improvements, using a
> > > thread-per-connection model with BIO for a server seems to work pretty
> > > well for quite a few use cases.
> > >
> > > If your client and server are over the internet, do remember to factor
> > > in I/O wait times that will occur if you use BIO.  If you can tell us
> > > what your use case is, we can provide better suggestions.
> > >
> > > HTH,
> > > Vinod.
> > >
> >
>

Re: Performances questions

[Maarten Bosteels <mb...@gmail.com>]

On 4/5/07, yann Blazart <ya...@gmail.com> wrote:
>
> Thanks !
>
> My use case is to provide a framework to make a replacement of Rmi for
> internal use in entreprise (RAD) without the f... problems of registry
> SecurityManager and codebase and Remote interface.... , based on Mina
> (very
> fun framework you've done !)


If you just want a replacement  for RMI you should take a look at the Spring
Remoting options:
http://www.springframework.org/docs/reference/remoting.html

They make it very easy to remote a POJO and solve a lot of the problems of
RMI.

But if scalability is your main concern, MINA will probably be a better
solution :-)

Maarten


I will try to improve my framework (called Roc),  code a specific codec and
> make a bench under heavy loading against Rmi, I will send to this list the
> conclusions of my benches.
>
> Thanks a lot !
>
> On 4/5/07, Vinod Panicker <vi...@gmail.com> wrote:
> >
> > On 4/5/07, yann Blazart <ya...@gmail.com> wrote:
> > > Hi thanks for your answer, but I 've tried to set the tcpNoDelay to
> > false on
> > > each side and I didn't saw any really performance improvment.
> > > The first problem is that if I test by only sending message but not
> > waiting
> > > for response, mina take 0.12 ms per call, aigainst Rmi that take 0.16ms
> > per
> > > call with the response. Is NIO slower than BIO, but more robust ?
> >
> > I guess you can say that NIO is more efficient that BIO in most cases.
> > Usually servers need to handle lots of concurrent connections and
> > that is where NIO really shines.  In your use case, if you have just a
> > single server and client and if there is no cpu starvation for the
> > threads, it is not at all surprising to see better performance from
> > BIO.  In fact, due to recent OS level improvements, using a
> > thread-per-connection model with BIO for a server seems to work pretty
> > well for quite a few use cases.
> >
> > If your client and server are over the internet, do remember to factor
> > in I/O wait times that will occur if you use BIO.  If you can tell us
> > what your use case is, we can provide better suggestions.
> >
> > HTH,
> > Vinod.
> >
>

Re: Performances questions

[yann Blazart <ya...@gmail.com>]

Thanks !

My use case is to provide a framework to make a replacement of Rmi for
internal use in entreprise (RAD) without the f... problems of registry
SecurityManager and codebase and Remote interface.... , based on Mina (very
fun framework you've done !)

I will try to improve my framework (called Roc),  code a specific codec and
make a bench under heavy loading against Rmi, I will send to this list the
conclusions of my benches.

Thanks a lot !

On 4/5/07, Vinod Panicker <vi...@gmail.com> wrote:
>
> On 4/5/07, yann Blazart <ya...@gmail.com> wrote:
> > Hi thanks for your answer, but I 've tried to set the tcpNoDelay to
> false on
> > each side and I didn't saw any really performance improvment.
> > The first problem is that if I test by only sending message but not
> waiting
> > for response, mina take 0.12 ms per call, aigainst Rmi that take 0.16 ms
> per
> > call with the response. Is NIO slower than BIO, but more robust ?
>
> I guess you can say that NIO is more efficient that BIO in most cases.
> Usually servers need to handle lots of concurrent connections and
> that is where NIO really shines.  In your use case, if you have just a
> single server and client and if there is no cpu starvation for the
> threads, it is not at all surprising to see better performance from
> BIO.  In fact, due to recent OS level improvements, using a
> thread-per-connection model with BIO for a server seems to work pretty
> well for quite a few use cases.
>
> If your client and server are over the internet, do remember to factor
> in I/O wait times that will occur if you use BIO.  If you can tell us
> what your use case is, we can provide better suggestions.
>
> HTH,
> Vinod.
>

Re: Performances questions

[Vinod Panicker <vi...@gmail.com>]

On 4/5/07, yann Blazart <ya...@gmail.com> wrote:
> Hi thanks for your answer, but I 've tried to set the tcpNoDelay to false on
> each side and I didn't saw any really performance improvment.
> The first problem is that if I test by only sending message but not waiting
> for response, mina take 0.12 ms per call, aigainst Rmi that take 0.16 ms per
> call with the response. Is NIO slower than BIO, but more robust ?

I guess you can say that NIO is more efficient that BIO in most cases.
 Usually servers need to handle lots of concurrent connections and
that is where NIO really shines.  In your use case, if you have just a
single server and client and if there is no cpu starvation for the
threads, it is not at all surprising to see better performance from
BIO.  In fact, due to recent OS level improvements, using a
thread-per-connection model with BIO for a server seems to work pretty
well for quite a few use cases.

If your client and server are over the internet, do remember to factor
in I/O wait times that will occur if you use BIO.  If you can tell us
what your use case is, we can provide better suggestions.

HTH,
Vinod.

Re: Performances questions

[yann Blazart <ya...@gmail.com>]

Hi thanks for your answer, but I 've tried to set the tcpNoDelay to false on
each side and I didn't saw any really performance improvment.
The first problem is that if I test by only sending message but not waiting
for response, mina take 0.12 ms per call, aigainst Rmi that take 0.16 ms per
call with the response. Is NIO slower than BIO, but more robust ?

On 4/5/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi,
>
> On 4/4/07, yann Blazart <ya...@gmail.com> wrote:
> > Hi ! I try to code a replacement of rmi using mina.
> >
> > In Jdk 5 Rmi take 0.16 ms to make a remote call, but with my mina
> > implementation I had 0.89 ms !
> >
> > So I spiciest my own way of coding and made a simple test : a client
> that
> > send a string to server (10000 loops)
> >
> > One call take 0.12 ms !
> >
> >  If a make the client wait for the server response the average call time
> > take 0.44ms.
> >
> > Is it normal that mina is so long ?
>
> MINA takes longer to accept a connection than blocking I/O because the
> acceptor thread and read/write threads are separated, and it's causing
> high latency.  But once a connection is established, it will perform
> well.  Sending messages asynchronously definitely improves
> performance.  In HTTP, it is called 'connection pipelining'.
>
> Also you might need to adjust socket options such as tcpnodelay if the
> size of a message is small.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>

Re: Performances questions

[Trustin Lee <tr...@gmail.com>]

On 4/5/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi Trustin,
>
> it would be very interesting if we can build some kind of performance tests
> with different scenarii and expose the results on the web site. Many people
> are just wondering if MINA is fast or not, and if mina can support thousands
> of concurent users. I'm sure that people will feel confortable if they see
> that with a specific perf scenario, the performance is above their
> expectations. And they will be able to check the code to see how the
> scenario is built.
>
> wdyt ?

I agree with you that we need such a test like SPEC.org does.  The
remaining question is who implements the test.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Performances questions

[Emmanuel Lecharny <el...@gmail.com>]

Hi Trustin,

it would be very interesting if we can build some kind of performance tests
with different scenarii and expose the results on the web site. Many people
are just wondering if MINA is fast or not, and if mina can support thousands
of concurent users. I'm sure that people will feel confortable if they see
that with a specific perf scenario, the performance is above their
expectations. And they will be able to check the code to see how the
scenario is built.

wdyt ?


-- 
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Performances questions

[Trustin Lee <tr...@gmail.com>]

Hi,

On 4/4/07, yann Blazart <ya...@gmail.com> wrote:
> Hi ! I try to code a replacement of rmi using mina.
>
> In Jdk 5 Rmi take 0.16 ms to make a remote call, but with my mina
> implementation I had 0.89 ms !
>
> So I spiciest my own way of coding and made a simple test : a client that
> send a string to server (10000 loops)
>
> One call take 0.12 ms !
>
>  If a make the client wait for the server response the average call time
> take 0.44ms.
>
> Is it normal that mina is so long ?

MINA takes longer to accept a connection than blocking I/O because the
acceptor thread and read/write threads are separated, and it's causing
high latency.  But once a connection is established, it will perform
well.  Sending messages asynchronously definitely improves
performance.  In HTTP, it is called 'connection pipelining'.

Also you might need to adjust socket options such as tcpnodelay if the
size of a message is small.

HTH,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6