Some more results after the modification I suggest at the end of my last
mail (ie, do the write immediately, instead of using a queue, when we can) :
Mina3 client/ Mina3 server : 10bytes msgs in 38.6 secs | 1k msgs in 42.2 secs |
10k msgs in 45.7 secs
This is a clear 50% speedup compared to my p
Houura :-)
The default socket buffer size is changed by mina 2 ?
Le 5 janv. 2013 06:26, "Emmanuel Lécharny" a écrit :
> Some more results after the modification I suggest at the end of my last
> mail (ie, do the write immediately, instead of using a queue, when we can)
> :
>
> Mina3 client/ Mina
Regarding the message size, I noticed that Mina2 writes only a sub part of
the message (size is computed from the receive buffer size if I remember
correctly) whereas Netty tries to write the buffer buffer to the socket. So
If you did the same in Mina3, it may explain why it is slow
Jeff
On Sat
Le 1/5/13 1:27 PM, Jeff MAURY a écrit :
> Regarding the message size, I noticed that Mina2 writes only a sub part of
> the message
Do you mean the full message don't get written ? I would be extremely
surprised if it were the case, and it would worth a JIRA and a fix...
> (size is computed from
No, I did not mean there's a bug but what I meant is that when Mina2 has to
write a large message, it will split the message in small parts when
writing to the socket whereas Netty tries to write the full message to the
socket (as Mina3 from what you said). This may explain why Netty becomes
slower
Le 1/5/13 7:21 PM, Jeff MAURY a écrit :
> No, I did not mean there's a bug but what I meant is that when Mina2 has to
> write a large message, it will split the message in small parts when
> writing to the socket whereas Netty tries to write the full message to the
> socket (as Mina3 from what you
I'm working on the netty server. It should be ok by the end of the week-end.
Regarding the performance for large message, should'nt it be related to jni
i mean the conversion from the java bytebuffer to a memory array that is
expected by the os socket layer ?
Jeff
Le 5 janv. 2013 19:42, "Emmanuel
perhaps we should try reading/writing direct buffers
On Sat, Jan 5, 2013 at 8:23 PM, Jeff MAURY wrote:
> I'm working on the netty server. It should be ok by the end of the
> week-end.
> Regarding the performance for large message, should'nt it be related to jni
> i mean the conversion from the
Le 1/5/13 8:23 PM, Jeff MAURY a écrit :
> I'm working on the netty server. It should be ok by the end of the week-end.
I just ran the NettyClient/NettyServer test you provided, using Java 7 :
NettyClient/NettyServer
10 : 38.308 - 26104/s
1024 : 39.383 - 25392/s
10240 : 49.132 - 20353/s
Co
Le 1/5/13 1:27 PM, Jeff MAURY a écrit :
> Regarding the message size, I noticed that Mina2 writes only a sub part of
> the message (size is computed from the receive buffer size if I remember
> correctly) whereas Netty tries to write the buffer buffer to the socket. So
> If you did the same in Mina
The problem I see if you choose to copy the user buffer into a DirectBuffer
is that your memory consumption will double even if the DirectBuffer is not
allocated on the heap, it may be problematic
Regards
Jeff
On Wed, Jan 9, 2013 at 11:44 AM, Emmanuel Lécharny wrote:
> Le 1/5/13 1:27 PM, Jeff
Le 1/9/13 11:54 AM, Jeff MAURY a écrit :
> The problem I see if you choose to copy the user buffer into a DirectBuffer
> is that your memory consumption will double even if the DirectBuffer is not
> allocated on the heap, it may be problematic
It will double only the time necessary to copy the buff
Hi!
I saw some benchmarks of direct vs. heap buffers - but I can't remember a
single one where direct buffers were a *big* performance gain. If you're
copying the buffers just to make it perform better, you'll probably get a huge
performance penality caused by the copy-logic itself.
Maybe it's
The performance gain is not related to the nature of the buffer; I mean
writing to an HeapBuffer vs writing to a DirectBuffer but related to
writing the buffer to the socket: if you write an HeapBuffer to a socket,
my guess is that it will be copied to a DirectBuffer before it gets written
to the s
Le 1/10/13 10:56 AM, Jeff MAURY a écrit :
> The performance gain is not related to the nature of the buffer; I mean
> writing to an HeapBuffer vs writing to a DirectBuffer but related to
> writing the buffer to the socket: if you write an HeapBuffer to a socket,
> my guess is that it will be copied
to be a little bit more precise, you will copy 64Mb the first time then
64Mb - 64kb the second time and so on
Jeff
On Thu, Jan 10, 2013 at 12:11 PM, Emmanuel Lécharny wrote:
> Le 1/10/13 10:56 AM, Jeff MAURY a écrit :
> > The performance gain is not related to the nature of the buffer; I mean
Ok I have conducted some experimentations :
1) The HeapBuffer is copied into a DirectBuffer before being written
We see a dramatic performance improvement for the forth test (64Mb
messages), which now takes 14seconds to complete, instead of
timeouting, but the three first tests are going 15% slo
I have played a bit more...
Now, I create a DirectBuffer whn the session is created, its size being
equal to the SendBufferSize, and I reuse this buffer if I can write the
message immediately. If not, or if I can't write it completely, I copy
the HeapBuffer into a DirectBuffer.
Such a strategy ke
Two remarks:
1) if the user buffer is a DirectBuffer, I suppose you use it instead of
your alllocated DirectBuffer
2) why don't you use always your DirectBuffer when you need to write on the
channel ?
Regards
Jeff
On Fri, Jan 11, 2013 at 6:41 AM, Emmanuel Lécharny wrote:
> I have played a bit
Le 1/11/13 9:09 AM, Jeff MAURY a écrit :
> Two remarks:
>
> 1) if the user buffer is a DirectBuffer, I suppose you use it instead of
> your alllocated DirectBuffer
Yes.
> 2) why don't you use always your DirectBuffer when you need to write on the
> channel ?
This is what is done. Either i use the
Hi !
I did some more tests, with different buffer size. Here are the results :
MINA3 :
10b, 1M msg/s : 28,341
1kb, 1M msg/s : 28,884
10kb, 1M msg/s : 25,603
20kb, 1M msg/s : 21,238
50kb, 500k msg/s : 9,425
100kb, 200k msg/s : 7,637
200kb, 100k msg/s : 2,181
500kb, 50k msg/s : 980
Hi !
I did some more tests, with different buffer size. Here are the results :
MINA3 :
10b, 1M msg/s : 28,341
1kb, 1M msg/s : 28,884
10kb, 1M msg/s : 25,603
20kb, 1M msg/s : 21,238
50kb, 500k msg/s : 9,425
100kb, 200k msg/s : 7,637
200kb, 100k msg/s : 2,181
500kb, 50k msg/s : 980
It's only loopback tests ? I wonder if the result would be the same on a
real network.
BTW what would be the use case for writing buffer bigger than 64K ? That's
sounding like a waste of memory for me.
On Mon, Jan 14, 2013 at 8:36 AM, Emmanuel Lécharny wrote:
> Hi !
>
> I did some more tests, w
Le 1/14/13 10:47 AM, Julien Vermillard a écrit :
> It's only loopback tests ? I wonder if the result would be the same on a
> real network.
I don't think it would be any different, except that you will exhaust
your 100Mbs bandwith with 1Kb messages before you reach the peak we get
on the loopback,
24 matches
Mail list logo
