[zeromq-dev] best practice

[Andrew Hume]

gosh! thanks for the great replies.
i have a new pattern which seems significantly faster.
s4 is the high volume socket

plist = zpoller_new(s1, s2, s3, s4)
for(;;){
	read up to 50 msgs NOBLOCK from s4
	sock = zpoller_wait(plist)
	if(sock == s1 or s2 or s3) process sock
	// if sock was s4, we’ll catch it next time around the loop
}

this gives me the code for s4 in exactly one spot,
it limits the latency for s[123] traffic,
50 is an experimentally determined value.
the only cost is the subtlety of polling for s4 but not processing it
where we process the other returns.

thanks again for the insight!
(it reminds me of the Unix pipe story.)

	andrew

On Dec 11, 2013, at 4:33 PM, Bruno D. Rodrigues <bruno.rodrigues at litux.org> wrote:

> 
> On Dec 11, 2013, at 14:43, Pieter Hintjens <ph at imatix.com> wrote:
> 
>> On Wed, Dec 11, 2013 at 1:40 PM, Andrew Hume <andrew at research.att.com> wrote:
>> 
>>> i’ve just switched to using poller and wanted to verify my “pattern”.
>>> i have 4 incoming sockets. 3 are (very) low volume but need low latency
>>> the other socket is high volume where (almost) any latency will do.
>>> 
>>> my pattern is to initialize the poller with the high volume socket last,
>>> but when i get a hit on that socket, i read up to 100 messages before
>>> going back to polling.
>>> 
>>> is there a better way to do this?
>> 
>> Sounds right. The order that you register sockets won't be significant
>> IMO (worth measuring). On all systems (but OS/X specifically), you
>> will win by doing non-blocking reads until there are no messages left,
>> and only then switch to polling.
> 
> I need to get some time to test this further and prepare a pull request for the main code, but in the meantime for Andrew here’s an example of the pattern I’ve used for the half-poll that turns linux almost twice as fast and mac almost at pair with linux.
> 
> https://github.com/davipt/libzmq/blob/fix-002-proxy_lat_thr/perf/proxy.cpp#L128
> 
> (note: should change those &= into NORs, but in java I think it’s ~= but it didn’t work on c)
> 
> Like Pieter said, the cost of a recv(DONTWAIT) is practically zero, so it’s cheaper to recv from all sockets even if only some have data, and then revert back to poll when there’s a bigger period where no socket has data.
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


-----------------------
Andrew Hume
949-707-1964 (VO and best)
732-420-0907 (NJ)
andrew at research.att.com



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