Hi Garrett, thanks for your answers. I will parallelize my code to open multiple links. Where can i find an example of Raw REQ/REP ?
Pierre On 01/16/2015 06:11 PM, Garrett D'Amore wrote:
On Jan 16, 2015, at 8:00 AM, Pierre Salmon <pierre.salmon@xxxxxxxxxxxxx> wrote: Hi, I have a little question, what is the best architecture to have request/response system with high performance (300000 msg/s). Now, i use REQREP socket pattern but, with simple example, i hace only ~30000 msg/s (1 thread with REQ socket and 1 thread with REP socket). if i add new threads (REP+REQ) in apps, i cannot increase this result (always 30000). what am i doing wrong ? PierreThis begs many, many questions. The code can probably achieve > 1M messages per second, but *not* if you’re running a vanilla req/rep socket. Those sockets are strictly serialized, and you wind up losing performance because you can only have a single message *outstanding*. Networking latency thus becomes the limiter in that situation. The solution to that problem is to make sure you’re using raw modes — RREQ/RREP if I recall the code properly. (In mangos you get this by setting the socket option to Raw mode, but nanomsg instead makes you select it during socket initialization.) Be aware that running in raw mode means that you have to take care to match replies to requests, by looking at the header, and copying the header from the request to the reply. There may be other factors limiting you too. For example, do you have enough resources; do you have other serialization points in your application code; does your threading code properly engage multiple cores; do you have enough bandwidth to serve the traffic; etc. etc. But at *first* guess, its probably the raw vs. cooked mode that is limiting you. If you’re already in raw mode, you will need to do further analysis. If you have to run serialized, you won’t be able to get such high message rates per second. To get 300K messages per second you’d need to have a round trip latency of only 3 usec. I’m not aware of any commodity transport that can do that, or even get close. TCP transports over ethernet are probably on the order of 10x that latency. (Note that raw ethernet, assuming 64-byte frames, can do about 9M packets per second over 10Gbe, or just under 1M for 1Gbe. That’s running at wire rate with zero interpacket latency. At 1GbE even 1 usec latency cuts that rate in *half*, so you *have* to get parallelization to achieve high rates.) - Garrett
