Ok ... Figured out! Now answering my own very latest question -- HWM-arks do matter.
Explaining: If you run with defaults _everywhere_ (hwm=1K) then DEALER(Sender) <-> [ROUTER - ROUTER](Device) <-> DEALER(Receiver) architecture will give you ~ 600K/sec on Sender.send() and same amount on Device.send() and same 600K on Receiver.recv() . But then you will have a problem in Receiver.send() which will be blocking almost all time and will give only 2 ~ 5 K/sec on sending replies back. In case you want not only fast "send" but fast "reply" as well (it's my case!) then hwm-arks should be set like this: DEALER(Sender(hwm_recv=0, hwm_send=default)) <-> [ROUTER(hwm_recv=0, hwm_send=default) - ROUTER(hwm_recv=0, hwm_send=default)](Device) <-> DEALER(Receiver(hwm_recv=0, hwm_send=default)) . With such hwm settings I get almost equivalent amount of traffic in both directions: ~ 400 K/sec! Sender cpu ~ 50%, Receiver cpu ~ 30 %. Very nice! I much appreciate to Panu Wetterstrand! Your suggestion made everything. Thanks again. Whenever you will be in Kyiv be sure bottle of Ballantine's is waiting for you :) My FB -- https://www.facebook.com/artem.vysochyn . 2014-05-23 19:22 GMT+03:00 artemv zmq <[email protected]>: > 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 <[email protected]>: > > Yes. Then there is no unnecessary poll calls. >> 23.5.2014 17.48 kirjoitti "artemv zmq" <[email protected]>: >> >> 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 <[email protected]>: >>> >>>> 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" <[email protected] >>>> >: >>>> >>>> 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" <[email protected]>: >>>>> >>>>>> 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 >>>>>> [email protected] >>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>>>> >>>>>> >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>>> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
