Hi again,
@Emmanuel: Sorry ... I (again) only replied to you, instead of the list
:-(
@others: please read my reply below ...
I now tried to play with different receive buffer sizes. And voilá .. Now
it works. But I still don't know why. But here are the details...
I added the following lines to my server and client (for client, I of
course used "connector" instead of "acceptor"):
----
System.out.println("read buffer size =
"+acceptor.getSessionConfig().getReadBufferSize());
System.out.println("send buffer size =
"+acceptor.getSessionConfig().getSendBufferSize());
System.out.println("recv buffer size =
"+acceptor.getSessionConfig().getReceiveBufferSize());
----
Output with Win7 for client as well as for server:
---
read buffer size = 2048
send buffer size = 1024
recv buffer size = 1024
---
The read buffer size seems to be the size that the IoProcessor tries to
read.
The receive buffer size, seems to be the size on the socket for receiving
data.
I then tried the same on WinXP. Client and server had again the same
values. So there's no difference between Win7 and WinXP.
If I increase on the server the recv buffer size to 2048, I still have
performance problems. If I use 2050 bytes for recv buffer, it's already
fast. And if I use 10240 bytes, it's extremly fast.
So, can someone explain why Win7 and WinXP behave differently with the
same buffer sizes? According to the already linked knowledgebase article,
this issue should be visible with WinXP, but not with Win7.
In my case (and it is already tested on other machines too), it's the
other way around. WinXP is fast, Win7 is slow.
My second als last question for this mail is:
Why is the IoProcessor waiting for 2048 bytes when the socket's buffer is
at 1024. My understanding is, that MINA is then always trying top read more
from the socket as there is data available in recv buffer. Does this make
any sense?
I also tried it other way around: Let recv buffer size at 1024, but set
the read buffer of IoProcessor to 512... But with this setting, it's also
damn slow :-( Why?!
br,
Alex
On Thu, 17 Jun 2010 14:08:17 +0200, Alexander Christian <[email protected]>
wrote:
> On Thu, 17 Jun 2010 12:13:07 +0200, Emmanuel Lecharny
> <[email protected]>
> wrote:
>> On 6/17/10 11:42 AM, Jens Reimann wrote:
>>> Maybe this is not a MINA issue but a Windows issue:
>>>
>>> http://support.microsoft.com/kb/823764
>>>
>>> This seems exactly the case for my problem.
>>>
>>
>> Sounds like a good catch !
>>
>> The workaround 2 (increase the send buffer size) should solve the
>> problem here. That also means the server should send smaller buffer
than
>
>> the configured size.
>
> Hmm, okay. The article also says that it's related to non-blocking IO
and
> that blocking IO doesn't have this problem. That would explaint why my
> first reproducer application using Java IO works quite well.
> But there are two big questionmarks in an orbit around my head:
>
> 1) If you scroll to the bottom of the article, one can read that also
> WinXP is affected by the problem. Windows 7 is not mentioned at all.
> 2) When I run my MINA reproducer application, it's only Win7 which has
the
> transfer slowdown.
>
> So the sympton only matches 50% to the article :-(
> I will now test with increased buffer sizes ...
>
>>
>> Who said that W$ sucks, btw ? :)
>
> ;-) All I can say: I don't have that kind of problems with linux or
MacOS
> X ...
>
> br,
> Alex
