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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [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
