[zeromq-dev] tcp vs zeromq

[Diego Duclos]

Not sure if this'll be useful, but I made some latency testing code at the
latest zmq gathering in brussels, I've tested it successfully to measure
how much a micro instance on ec2 could take asynchronously when getting
traffic from europe. It's in python though, but feel free to try it out:
https://github.com/cncfanatics/latencyTest


On Fri, Jul 12, 2013 at 11:13 PM, ashwini ramamurthy <
ashwini.ram21 at gmail.com> wrote:

> Hi ,
> Thank you all for your inputs. Your right, I should do asynchronous tasks
> and multi-cast to compare. That was my next step. I will be using PUB-PUB
> and PUSH-PULL.
>
>
> -Ashwini
>
>
> On Fri, Jul 12, 2013 at 4:21 PM, Pieter Hintjens <pieterh at gmail.com>wrote:
>
>> Right. If you care about performance you will always want an asynchronous
>> model, and in this case ZeroMQ's batching will make a big impact. A latency
>> critical request reply scenario is very uncommon.
>>
>> Pieter
>> On Jul 12, 2013 9:00 PM, "Trevor Bernard" <trevor.bernard at gmail.com>
>> wrote:
>>
>>> In your performance experiment ZeroMQ will always be slower than TCP.
>>> There is a small overhead to using ZeroMQ but it's mitigated by other smart
>>> things it does like smart batching to avoid redundant network stack
>>> traversals. But if all you're doing is a synchronous PING/PONG, you lose
>>> that speed benefit entirely and might as well just use TCP.
>>>
>>> ZeroMQ's value-add over TCP is stuff like API simplicity,
>>> asynchronicity, message queuing/routing, multi-cast, atomic multi-part
>>> messaging, etc. If speed is your concern, I would suggest redefining your
>>> problem and try to model it asynchronously.
>>>
>>> One embodiment might be:
>>>
>>> Use PUSH/PULL to distribute the work and PUB/SUB to aggregate the
>>> results.
>>>
>>> Warmest regards,
>>>
>>> Trev
>>>
>>> On Fri, Jul 12, 2013 at 3:19 PM, Diego Duclos <diego.duclos at gmail.com>wrote:
>>>
>>>> Seeing as zeroMQ is most likely running on top of tcp in this case, it
>>>> seems natural that for small messages the processing time of this extra
>>>> layer of code is adding a noticeable processing time.
>>>> You can find a really detailed write-up on performance at
>>>> http://www.zeromq.org/results:0mq-tests-v03
>>>>
>>>>
>>>>  On Fri, Jul 12, 2013 at 7:51 PM, ashwini ramamurthy <
>>>> ashwini.ram21 at gmail.com> wrote:
>>>>
>>>>>  Hi All,
>>>>>
>>>>> To compare the performance of zeromq and tcp  I did the following
>>>>> experiment
>>>>>
>>>>>
>>>>>
>>>>> *Experimental setup for zeromq *
>>>>>
>>>>>    -  android client(Motorola razr) which runs jeromq.
>>>>>    -  java server(PC running Linux) which runs java binding of zeromq
>>>>>    -  Using the REQUEST-REPLY messaging pattern
>>>>>    - Sending 100/1000 messages to the server and 100/1000 messages to
>>>>>    client (synchronous)
>>>>>    - The client sends a hello message and waits for a reply from the
>>>>>    server to send another message(ping-pong)
>>>>>    - The server waits for a message and replies with a hello for
>>>>>    every message sent
>>>>>    - Both the devices were connected through wifi
>>>>>    - *On an avg:For 100 messages the time taken was 937 msec*
>>>>>    - *On an avg:For 1000 messages the time taken was 8270 msec*
>>>>>
>>>>> *Experimental setup for TCP*
>>>>>
>>>>>    - android client (Motorola razr)
>>>>>    - java server (PC running Linux)
>>>>>    - Using a REQ-REP pattern(ping-pong)
>>>>>    - Sending 100/1000 messages to the server and 100/1000 back to
>>>>>    client(synchronous)
>>>>>    - Same as above, client sends a hello message to server and waits
>>>>>    to receive a world message before sending the next message.
>>>>>    - Both the devices were connected through wifi
>>>>>    - *On an avg:For 100 messages the time taken was 504 msec*
>>>>>    - *On an avg:For 1000 messages the time taken was 5240 msec*
>>>>>
>>>>> Is this excepted? or am i missing something or doing something wrong?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ashwini
>>>>>
>>>>> _______________________________________________
>>>>> 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/20130713/977c22dd/attachment.htm>