[zeromq-dev] Odd numbers with zeromq

[Andrew Hume]

excessive?
you are going from a scheme where packets go out in bulk asynchronously,
to a scheme where a single packet goes out, a process needs to woken up,
processes a single packet, and then send a single packet, and then wake up the sending process.
i think you're lucky to get 1k/s.

a. no. it seems silly from a programming perspective.

b. if you want efficiency, then do bulk asynchronous acknowledgements via another socket.

On Sep 18, 2012, at 9:57 PM, Maninder Batth wrote:

> A difference of 110K to 1k a second seems excessive. But i am not saying it is wrong or right. I am just wondering
> 
> a. Am i doing something silly from api usage perspective
> 
> b. If someone has similar experience, (one way burst, vs send, recieve ack and then send next message), maybe they can share their numbers or validate similar behavior.
> 
> 
> On Tue, Sep 18, 2012 at 10:26 PM, Andrew Hume <andrew at research.att.com> wrote:
> why would you expect different?
> REQ/REP involves a synchronous repsonse so there is no opportunity to do anything fast.
> 
> On Sep 18, 2012, at 8:21 PM, Maninder Batth wrote:
> 
>> Paul,
>> With messages being sent one way, via pub and sub sockets, i am getting a very decent performance. About 80% of our network gets saturated. 
>> The code is zserver.cpp and zclient.cpp
>> 
>> But if i configure the software such that client only sends the next message, after it has received a response from the server, the throughput  is really bad.
>> The code is zserver-ack1.cpp  and zclient-ack1.cpp
>> The difference is that in the former case, i can get 110k messages per second , whereas in the latter case,  i can only get 1k messages per second.
>> The sockets that i use in latter case are of type REQ and REP. Am i using wrong sockets type ?
>> 
>> 
>> 
>> On Tue, Sep 18, 2012 at 9:38 PM, Maninder Batth <whatpuzzlesme at gmail.com> wrote:
>> Paul,
>> Thank you again for your help. Now with message copying, i am getting a throughput of .8Gb, which is what i would have expected on a 1Gb network.
>> 
>> 
>> On Tue, Sep 18, 2012 at 4:20 PM, Paul Colomiets <paul at colomiets.name> wrote:
>> Hi Maninder,
>> 
>> On Tue, Sep 18, 2012 at 10:21 PM, Maninder Batth
>> <whatpuzzlesme at gmail.com> wrote:
>> > Paul,
>> > Here is number of messages as seen by the server in one second. Each message
>> > is 1024 byte excluding tcp/ip and zmq headers. Based on these numbers and i
>> > am getting a throughput of 1.4 Gb/sec.
>> > Enclosed is the source code for the server and the client.
>> >
>> 
>> Zeromq closes the message after sending. So you effectively send
>> messages of the zero length after first one. You should use
>> zmq_msg_copy (or whatever C++ API is there) before  doing send() in
>> case you want to reuse message.
>> 
>> --
>> Paul
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
>> 
>> <zclient.cpp><zclient-ack1.cpp><zserver.cpp><zserver-ack1.cpp>_______________________________________________
>> 
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> ------------------
> Andrew Hume  (best -> Telework) +1 623-551-2845
> andrew at research.att.com  (Work) +1 973-236-2014
> AT&T Labs - Research; member of USENIX and LOPSA
> 
> 
> 
> 
> 
> _______________________________________________
> 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


------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
andrew at research.att.com  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA




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