[zeromq-dev] Poor performance for DEALER <-> ROUTER - ROUTER <-> DEALER in hello_world scenario .

Charles Remes lists at chuckremes.com
Fri May 23 19:15:07 CEST 2014


Try sending with DONTWAIT set so it is completely async.

cr

On May 23, 2014, at 11:22 AM, artemv zmq <artemv.zmq at gmail.com> wrote:

> Hey Panu, 
> 
> That helped (unfortunately partially) ...  But still you made my day!  Many thanks.
> 
> What I got now -- I can send fast all the way: from DEALER  to-device--> ROUTER to-> ROUTER from-device--> DEALER . This works really  fast!  Your suggestion given me 500K/sec.  Nice,  but that's only half of what I need, because   opposite flow gives ~  2 or 3 K/sec. Also I see that Sender process using 60% of CPU  while   Receiver using ~ 5 % of CPU, so most of the time Receiver  now  blocking on sending response  back.  I  debugged  a bit and found that bottleneck is .send() method on Receiver. So, in short:  the problem now -- we can send fast  but  can't   reply fast . 
> 
> Any ideas?
> 
> 
> 
> 
> 2014-05-23 18:06 GMT+03:00 Panu Wetterstrand <panu.wetterstrand at iki.fi>:
> Yes. Then there is no unnecessary poll calls.
> 
> 23.5.2014 17.48 kirjoitti "artemv zmq" <artemv.zmq at gmail.com>:
> 
> Panu Wetterstrand , 
> 
> 
> Do u mean like this:
> 
> ...
> for (; ; ) {
>   poller.poll(1000);
>   if (poller.pollin(0)) {
>     // block here and .recv() from socket until .recv() return null .
>   }
> }
> ...
> 
> 
> Is this is what  you are proposing?
> 
> 
> Thanks  for heads up /
> 
> 
> 
> 
> 2014-05-23 17:22 GMT+03:00 Panu Wetterstrand <panu.wetterstrand at iki.fi>:
> Sorry. Event count relates to sockets so that is fine but try to read until socket is empty and recv returns nil.
> 
> 23.5.2014 17.16 kirjoitti "Panu Wetterstrand" <panu.wetterstrand at iki.fi>:
> 
> You should handle all events before calling poll again. Poll returns event count. Only with phone so cant write example.
> 
> 22.5.2014 21.21 kirjoitti "artemv zmq" <artemv.zmq at gmail.com>:
> I'm following advice from a guide to come with as-simple-solution-as-possible before moving further, and experiencing poor performance on a very simple scenario.
> 
> My test case is to check how ROUTER/DEALER constructions are working, how far they scale.  My environment:  windows_7_64bit/java7/4xCPU/8g/zmq-3.2.2/jzmq-3.0.0
> 
> Got two java processes. One process(called Sender) hosts ROUTER-ROUTER device   and  forever-loop DEALER  constantly sending "hello zmq world"  message.  Second process(called Receiver) is hosting  single DEALER which is sort of simple worker -- receives message and sends it back.
> 
> The whole point is measure how much messages per sec I can get at this very raw scenario. Here's java code:
> 
> Sender -- http://pastebin.com/mM7dqvSw
> Receiver -- http://pastebin.com/dS2SLA2G
> 
> 
> The test result ~ 40K/sec  which is much-much less than I expected. Because you can't have two java processes (both taking 50% cpu)  and rendering 40K  at  "hello world"  scenario..
> 
> 
> 
> Thanks in advance for a help.
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140523/627f8a1b/attachment.htm>


More information about the zeromq-dev mailing list