You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by da...@daune-consult.com on 2006/02/13 19:36:00 UTC
[Mina] Architecture advice
Hi,
I must re-implement a legacy protocol using Mina, and I wonder whether someone
could provide some architectural 'tips'.
I must transfer files using a TFTP-like protocol (over TCP). The file size does
not exceed 1 MB.
The file is truncated in numbered 512 bytes slices, each slice is acknowledged
using a message.
A same file is requested many times, by different clients. So there is room for
message caching and sharing.
My main question is how to make most benefit of Mina given those two
characteristics: 1) message cache and 2) multiple concurrent read-only use of
same messages.
I am not even sure non-blocking I/O are the appropriate way for this.
Thanks & Regards,
J-F
Re: [Mina] Architecture advice
Posted by Trustin Lee <tr...@gmail.com>.
On 2/14/06, daune.jf@daune-consult.com <da...@daune-consult.com> wrote:
>
> > NBIO can handle this of course IMHO.
>
> Yes it can, but I wonder whether it brings something over BIO in term of
> performance.
>
> This is a general question I have towards NBIO.
>
> NBIO brings better scalability, at the price, IMHO, of complexity (less
> intuitive model, require use of FSM-based protocol handler).
>
> I always wonder from which nr of simultaneous connections NBIO take the
> advantage over BIO.
>
> I also wonder whether BIO perform better when load is not high.
>
> Actually, it would be interesting to implement the same protocol (average
> complexity) using BIO and NBIO, and compare their performance under
> several
> loads. Does such benchmark already exist?
JGroups guys published one:
http://www.jgroups.org/javagroupsnew/docs/Perftest.html
And there was also a test result that BIO with Linux NPTL outperforms NIO
even with thousands of threads:
http://www.theserverside.com/discussions/thread.tss?thread_id=26700
I think the result can change if MINA supports native AIO.
HTH,
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
Re: [Mina] Architecture advice
Posted by Trustin Lee <tr...@gmail.com>.
On 2/14/06, daune.jf@daune-consult.com <da...@daune-consult.com> wrote:
>
> > NBIO can handle this of course IMHO.
>
> Yes it can, but I wonder whether it brings something over BIO in term of
> performance.
>
> This is a general question I have towards NBIO.
>
> NBIO brings better scalability, at the price, IMHO, of complexity (less
> intuitive model, require use of FSM-based protocol handler).
>
> I always wonder from which nr of simultaneous connections NBIO take the
> advantage over BIO.
>
> I also wonder whether BIO perform better when load is not high.
>
> Actually, it would be interesting to implement the same protocol (average
> complexity) using BIO and NBIO, and compare their performance under
> several
> loads. Does such benchmark already exist?
JGroups guys published one:
http://www.jgroups.org/javagroupsnew/docs/Perftest.html
And there was also a test result that BIO with Linux NPTL outperforms NIO
even with thousands of threads:
http://www.theserverside.com/discussions/thread.tss?thread_id=26700
I think the result can change if MINA supports native AIO.
HTH,
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
Re: [Mina] Architecture advice
Posted by da...@daune-consult.com.
Quoting Trustin Lee <tr...@gmail.com>:
> Hi J-F,
>
> On 2/14/06, daune.jf@daune-consult.com <da...@daune-consult.com> wrote:
>>
>> I must transfer files using a TFTP-like protocol (over TCP). The file size
>> does
>> not exceed 1 MB.
>>
>> The file is truncated in numbered 512 bytes slices, each slice is
>> acknowledged
>> using a message.
>>
>> A same file is requested many times, by different clients. So there is
>> room for
>> message caching and sharing.
>>
>> My main question is how to make most benefit of Mina given those two
>> characteristics: 1) message cache and 2) multiple concurrent read-only use
>> of
>> same messages.
>
>
> To fulfill both requirement, we need ByteBuffer.duplicate(). MINA
> ByteBuffer doesn't provide duplicate() of slice() method for now. We're
> going to resolve this issue somehow. There's a discussion realated with it
> here:
>
> http://issues.apache.org/jira/browse/DIRMINA-165
Thanks for info. I'll take a look at it.
> Messages can be cached of course. Moreover, if we can cache the encoded
> bytebuffer, the performance at a certain case will increase dramatically
> because it can bypass the actual encoding process. I hope this feature is
> included with MINA 0.9.2.
I also do hope it will.
>> I am not even sure non-blocking I/O are the appropriate way for this.
> NBIO can handle this of course IMHO.
Yes it can, but I wonder whether it brings something over BIO in term of
performance.
This is a general question I have towards NBIO.
NBIO brings better scalability, at the price, IMHO, of complexity (less
intuitive model, require use of FSM-based protocol handler).
I always wonder from which nr of simultaneous connections NBIO take the
advantage over BIO.
I also wonder whether BIO perform better when load is not high.
Actually, it would be interesting to implement the same protocol (average
complexity) using BIO and NBIO, and compare their performance under several
loads. Does such benchmark already exist?
Best regards,
J-F
Re: [Mina] Architecture advice
Posted by Trustin Lee <tr...@gmail.com>.
Hi J-F,
On 2/14/06, daune.jf@daune-consult.com <da...@daune-consult.com> wrote:
>
> I must transfer files using a TFTP-like protocol (over TCP). The file size
> does
> not exceed 1 MB.
>
> The file is truncated in numbered 512 bytes slices, each slice is
> acknowledged
> using a message.
>
> A same file is requested many times, by different clients. So there is
> room for
> message caching and sharing.
>
> My main question is how to make most benefit of Mina given those two
> characteristics: 1) message cache and 2) multiple concurrent read-only use
> of
> same messages.
To fulfill both requirement, we need ByteBuffer.duplicate(). MINA
ByteBuffer doesn't provide duplicate() of slice() method for now. We're
going to resolve this issue somehow. There's a discussion realated with it
here:
http://issues.apache.org/jira/browse/DIRMINA-165
Messages can be cached of course. Moreover, if we can cache the encoded
bytebuffer, the performance at a certain case will increase dramatically
because it can bypass the actual encoding process. I hope this feature is
included with MINA 0.9.2.
I am not even sure non-blocking I/O are the appropriate way for this.
NBIO can handle this of course IMHO.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C