[zeromq-dev] Windows throughput perfomance. Once again.

[Геннадий Казачёк]

31 мая 2011 г. 13:42 пользователь Martin Sustrik <sustrik at 250bpm.com>написал:

> Hi Gennadiy,
>
>
>  I've already posted this issue a month ago, but it was stuck, so I want
>> to up that thread with some additions.
>> So, the issue was about very low performance charts under Windows, using
>> tests in perf directory.
>>
>
> The problem with Windows is that's it's a proprietary OS. So, for example,
> I don't have two windows boxes to test on them, same way as I don't have
> HP-UX or AIX boxes. It's up to those with appropriate licenses to optimise
> 0MQ for those platforms.
>
>
>  I make some new test since then, with a couple of linux boxes, so what I
>> have now:
>> Box running remote_thr is a sender(S), and box running local_thr is a
>> receiver(R).
>> Packet sizes are from 64 bytes to 256 Kbytes.
>> Win(S) --> Win(R) - 10-50 Mbit/s
>> Win(S) -->Linux(R) - 150-750 Mbit/s (varies mostly with packet size.
>> Larger the packet - more throughput)
>> Linux(S) -->Win(R) - 450-900 Mbit/s (much more stable results except for
>> 64 byte blocks)
>> Linux(S) --> Linux(R) - 800-950 Mbit/s (very low dispersion and the
>> highest speed).
>>
>
> That sounds pretty bad. More investigation is needed.
>
>
>  All Windows are WinXP SP3. Applications was built by VS2008 with no
>> changes in projects in release mode.
>> Tests were made in every data flow way, so network problems are excluded
>> from list.
>> So what would your suggestions?
>>
>
> What's needed is profiling of individual pieces of the critical path. That
> should show which piece is the bottleneck and should be optimised.
>
> Martin
>


I tried to profile zmqlib, but spent only a couple of hours, so the only
thing I've found was:

USER+KERNEL TIME (seconds)
zmq :: tcp_socket_t :: write - 0.21
zmq :: select_t :: loop - 0.17

ELAPSED TIME (seconds)
zmq :: select_t :: loop - 225,44
zmq :: mailbox_t :: recv - 112,85

I guess (correct me, if I wrong) that this means, that we are waiting for
something 1000 times longer then working.
I can make another test, but don't know what exactly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110531/83ac2486/attachment.htm>