[zeromq-dev] recv() on a ZMQ_REQ socket is slow

[Doron Somech]

It is part of 4.2, a new thread safe socket types.

You can read more here:
https://github.com/zeromq/libzmq/blob/master/doc/zmq_socket.txt#L68

Anyway if you send requests one-by-one you will enjoy zeromq
performance only at the server side, able to handle high throughput of
requests.
I don't recommend to use the REP socket on the server side, try to use
a pattern from the zeromq guide, the load balancing might be right:
http://zguide.zeromq.org/page:all#toc69







On Mon, Oct 10, 2016 at 9:25 AM, Dimos Stamatakis <dimstamat at gmail.com> wrote:
> Hi Doron,
>
> thanks for your response! We actually prefer to have synchronous behavior,
> since we will be using it for RPC calls and we want to know the status of
> the operation before proceeding to the next one.
>
> What is the client-server patter you mentioned? I didn't find it in the
> documentation.
>
> Thanks,
>
> Dimos
>
> On Sat, Oct 1, 2016 at 10:32 AM, Doron Somech <somdoron at gmail.com> wrote:
>>
>> REQ-REP pattern is slow because zeromq is not tuned for one message at a
>> time but for batch of messages. I suggest to use the dealer-router or better
>> the client-server.  You can use uuid or just sequnce number for request
>> identifier. However if your use case is one message at the time so the
>> benefit of zeromq will be throughput at the server side.
>>
>>
>> On Thu, Sep 29, 2016, 01:30 Dimos Stamatakis <dimstamat at gmail.com> wrote:
>>>
>>> Hi everyone,
>>>
>>> I have been testing the ZeroMQ library combined with Thrift to compare
>>> the performance. I have a simple ZeroMQ example where I create ZMQ_REP and
>>> ZMQ_REQ sockets for a simple client-server communication. In the example,
>>> client simply sends a message to the server and waits for a reply. The only
>>> slow part I measured is the client receive, which makes sense. But it is
>>> almost three times slower than a native TCP socket.
>>> So the actual benchmark is the Thrift with ZeroMQ, as officially released
>>> by apache:
>>>
>>> https://github.com/apache/thrift/tree/master/contrib/zeromq
>>>
>>> I measured the overhead of using ZeroMQ for Thrift's communication,
>>> instead of a native TCP socket.
>>> The client response is much higher when using ZeroMQ and I was expecting
>>> to be caused by the copying that must be done from Thrift data structures to
>>> ZeroMQ data structures (zmq::message_t).
>>> However the copying is negligible. The actual overhead is the recv() of
>>> the client, waiting for the server to reply. Is it normal for a ZeroMQ
>>> REQ-REP socket to be almost three times slower than a native TCP socket? Is
>>> there something I can do to optimize it? I am using the default send and
>>> recv with no flags.
>>>
>>> I thought that maybe something is wrong with the way Thrift-ZeroMQ is
>>> implemented so I also ran the hello example:
>>> http://zguide.zeromq.org/cpp:hwserver
>>> This also takes more time in the recv().
>>>
>>>
>>> Many thanks in advance,
>>> Dimos
>>> _______________________________________________
>>> 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