ZeroMq IRC Log

Sunday September 25, 2011

[Time] Name	Message
[06:29] bitcycle	Hey all. Is there a common pattern for administrating a distributed app that uses zeromq to process work (via pub/sub pattern)?
[08:26] mxp	hey everyone
[08:27] mxp	i cant seem to get 1000 req/rep per second :(
[08:27] mxp	even with plain echo server
[08:27] mxp	how can i make it faster
[08:27] mxp	?
[11:55] mxp	anybody alive?
[12:54] phantomcircuit	mxp, BRAINS
[14:42] abhishekkuamr	can someone help me, I am try to run one of the java example for zmq, but getting an error
[14:42] abhishekkuamr	ruby lookUpListener3.rb Connecting to hello world server... Sending request 0... lookUpListener3.rb:13: undefined method `send_string' for #<ZMQ::Socket:0x7f0bf8777c38> (NoMethodError) from lookUpListener3.rb:11:in `upto' from lookUpListener3.rb:11 abhishek@dv-lp-abhishek:~/zeroMQTest$ vim lookUpListener3.rb abhishek@dv-lp-abhishek:~/zeroMQTest$ vim lookUpListener5.rb abhishek@dv-lp-abhishek:~/zeroMQTest$ ruby lookUpListe
[16:54] mxp	i am not get more than 1000 req/rep per second
[16:54] mxp	what am i doing wrong?
[16:56] mxp	I ave used the hello world example code
[16:56] mxp	wat am i doing wrong
[17:00] mxp	anyone alive?
[17:01] mxp	:S
[17:01] mxp	is this channel dead or wat
[17:01] mxp	?
[17:09] blk	mxp, what are youexpecting?
[17:14] cremes	mxp: show us the code...
[17:15] cremes	and the output
[17:21] mxp	cremes, http://www.pastie.org/2589951 server code
[17:21] mxp	http://www.pastie.org/2589956
[17:21] mxp	client takes 12 seconds for 100000 cycles
[17:22] mxp	1.3 for 10000
[17:22] mxp	why is it so slow?
[17:26] cremes	mxp: slow compared to what?
[17:26] cremes	your round-trip time is about 120 microseconds
[17:26] cremes	what do you expect it to be?
[17:27] cremes	on my machine, a similar set of code has a round-trip of around 105 microseconds
[17:27] cremes	on a server-class box at work, the same code has a round-trip of around 55 microseconds
[17:28] cremes	mxp: try running the local_lat/remote_lat examples that ship with the library
[17:29] cremes	they do essentially the same thing but are easier for us to discuss since everyone has the same code
[17:29] cremes	(btw, your client code does not need 2 i/o threads in its context; that will not help performance and may even hurt it in this case)
[17:35] mxp	cremes, how are other key value stores able to do 100000 req in milli secs?
[17:35] cremes	mxp: you are comparing apples and oranges
[17:36] mxp	cremes, :S em i using the wrong tool kit for creating a storage worker?
[17:36] cremes	no, you are misunderstanding the req/rep pattern and how it works
[17:36] cremes	in 0mq, the req/rep sockets work in lock-step; another request cannot be serviced until the current one
[17:36] cremes	is completed
[17:37] cremes	in your hypothetical key-value store you mention above, you are probably firing requests as fast as
[17:37] cremes	possible and collecting replies as they come in
[17:37] cremes	right?
[17:38] mxp	cremes, redis works in a single thread envoirment
[17:38] mxp	strictly speaking request response cycle
[17:38] mxp	it uses select poll though
[17:38] cremes	mxp: let me ask my question another way...
[17:38] mxp	epoll and all the event driven thing will that really help?
[17:39] cremes	in redis, are you waiting for each request to arrive before sending the next one?
[17:40] mxp	its using select poll so when sockets connects it accepts them and waits for select() to give them the readable sockets
[17:40] mxp	once selected reads the data from them
[17:40] cremes	stop
[17:40] mxp	and then processes them
[17:40] cremes	sto
[17:40] cremes	sto
[17:40] cremes	stop
[17:40] mxp	ok
[17:40] mxp	:P
[17:40] cremes	irrelevant
[17:40] cremes	0mq works the same way under the covers
[17:40] cremes	you need to compare the example code you pasted to the same thing that redis is doing
[17:41] cremes	otherwise your comparison has no merit
[17:41] mxp	ok
[17:41] mxp	sure
[17:41] mxp	what I am actually confused about is
[17:42] mxp	what pattern would be reasonable for such server client thing
[17:42] mxp	?
[17:42] blk	for thruput you should use asynchronous messaging
[17:42] blk	xrep/xreq
[17:42] cremes	exactly
[17:43] mxp	blk, whats difference ?
[17:43] cremes	mxp: have you read the socket descriptions?
[17:43] cremes	this is very basic stuff
[17:43] mxp	not all of them
[17:43] cremes	the guide covers the use cases
[17:43] mxp	i saw req/rep from there
[17:43] cremes	there are only 3 different pairs of sockets... :)
[17:44] mxp	req/rep, pubsub, pipeline?
[17:44] cremes	then you will see that req/rep enforces a strict send/recv notion
[17:44] cremes	whereas xreq/xrep let you send and recv in any pattern
[17:44] mxp	cremes, :) ooo i think i missed that
[17:44] cremes	so, with req/rep, you must do send/recv/send/recv/send/recv otherwise
[17:44] cremes	it blows up
[17:45] mxp	cremes, wasnt it PAIR something?
[17:45] cremes	xreq/xrep can do send/send/send/send/recv/recv/recv/recv so you can get more work done by
[17:45] cremes	overlapping
[17:45] cremes	pair is an outlier and isn't useful for much
[17:45] mxp	cremes, lemme see and modify code to see if it helps
[17:45] cremes	it can only do one-to-one connections whereas all other types can to n-to-n, 1-to-n, n-to-1
[17:46] mxp	would that take performance higher
[17:46] cremes	mxp: please don't, you'll just confuse yourself more
[17:46] cremes	please read the guide
[17:46] mxp	cremes, sure :) will read it all first
[17:46] cremes	thank you
[17:46] cremes	it will save all of us much frustration if you get the basics down first
[18:16] sadie	Hi I am having trouble writing a server that would accept HTTP connections and send them to backend servers via zeromq sockets, I am using python
[18:18] sadie	it should work as a proxy with HTTP interface to my own custom database servers that will be talking zeromq
[19:02] mikko	hi stevo
[19:04] Steve-o	yo
[19:12] mikko	hmm
[19:12] mikko	Assertion failed: ok (mailbox.cpp:79)
[19:13] Steve-o	lol
[19:13] mikko	No such file or directory
[19:13] mikko	rc != -1 (kqueue.cpp:76)
[19:13] mikko	tend to run into these two often on mac
[19:15] Steve-o	losing messages in the command pipe
[19:16] mikko	the kqueue one seems to happen when remote peer exits
[19:17] Steve-o	so a race on close
[19:20] mikko	ttps://gist.github.com/68fdf6b67492d69bd035
[19:20] mikko	this fixes the symptoms
[19:20] mikko	but i wonder if there is a deeper cause for this
[19:20] mikko	sustrik: there?
[19:22] Steve-o	this is only the kqueue impl though
[19:23] Steve-o	never had to touch kevent
[19:25] Steve-o	obviously would help if the issue could be found with poll
[19:27] mikko	probably
[19:27] mikko	it seems to be kevent specific
[19:29] Steve-o	be a PITA if your chasing a kernel bug
[19:37] mikko	probably not
[19:37] mikko	looks like the handle is invalid before the event delete is called
[19:37] mikko	https://github.com/mkoppanen/pzq/blob/master/src/main.cpp#L116
[19:38] mikko	fair amount of boiler plate :)
[19:41] Steve-o	that's not too pretty
[19:42] mikko	would probably need to write a bit higher level C++ abstraction
[19:43] Steve-o	for only small bits of ugly it is hardly worth it though
[19:43] Steve-o	too many layers just makes it confusing
[19:44] mikko	would be nice to have a few things like sending multipart message from vector
[19:44] mikko	and returning vector for received multipart
[19:46] Steve-o	that sounds good
[20:03] blk	mikko: fwiw, we use such an abstraction at my company
[20:04] blk	re: the vector of msg parts
[20:08] mikko	blk: is it available anywhere?
[20:10] mikko	i've also been thinking about using dsn to set socket options
[20:10] mikko	like tcp://*:1234?snd_hwm=100&rcv_hwm=10
[20:10] mikko	etc
[20:10] blk	mikko: sorry, it is not. I've talked to the developer about writing something similar for cppzmq
[20:11] blk	but we are so busy right now :X
[20:12] blk	I'll bring it up with him again
[20:12] mikko	that's the IT problem i guess
[20:12] mikko	there is another new c++ binding available as well
[20:13] mikko	can't remember the name
[20:13] mikko	it would be cool to combine these efforts to create a higher level binding
[20:13] Steve-o	mikko: yes, that's on my todo too for pgm
[20:14] mikko	Steve-o: there is a minor typo on miru website
[20:14] Steve-o	probably more than just one
[20:14] mikko	just spotted while reading
[20:14] Steve-o	especially the chinese one
[20:14] mikko	http://miru.hk/services/ "Server clients can vary from destkop systems to network appliances."
[20:15] Steve-o	my site is not good :(
[20:15] mikko	well, mine is just a blog
[20:15] mikko	not very active one
[20:15] Steve-o	I think I've managed to at least update every year
[20:16] Steve-o	:))
[20:16] mikko	are you based in new york now?
[20:16] Steve-o	pretty much
[20:16] Steve-o	challenge now is to find a nice big sponsor
[20:16] mikko	for visa?
[20:16] Steve-o	for 0mq work
[20:16] mikko	oh, nice
[20:18] Steve-o	but even asking many companies that are advertising for low-latency work, 0mq is a confusing change of paradigm
[20:21] mikko	i think zeromq is slowly picking up more and more
[20:22] Steve-o	yes, I think people are burnt enough not to look at FTL
[20:22] mikko	i think industries outside finance are adopting it a lot faster
[20:23] mikko	especially web start ups
[20:23] Steve-o	being free helps :D
[20:23] Steve-o	TIBCO prices are amazing
[20:23] mikko	free and fairly quick to get actually working stuff
[20:24] Steve-o	which is why the BSD interface is important
[20:24] Steve-o	TIBCO invented a new one for FTL, but attempted MAMA style abstraction to run either on IP or RDMA
[20:26] Steve-o	it would be nice to have a native Java impl though
[20:27] mikko	it would mean a lot of duplication
[20:27] mikko	but that would help java adoption a lot
[20:30] Steve-o	with nio2 stable it hopefully should require too many re-implementations
[20:31] mikko	and i guess if the protocol could be moved to something like a parser generator
[20:31] mikko	then you could generate compatible implementations from common source
[20:31] mikko	like thrift or so
[20:31] mikko	(def not recommending thrift though_
[20:32] Steve-o	I guess the biggest problem is the iterations for best performance and eventual divergence from original architecture
[20:32] mikko	is that a problem though?
[20:33] mikko	currently we only have one implementation which is 'the reference implementation'
[20:33] Steve-o	a nice problem probably
[20:33] mikko	nothing prevents people using the patterns and so and creating alternative implementations
[20:33] mikko	just needs a lot of time
[20:33] mikko	maybe good candidate for summer of code
[20:33] Steve-o	yes, good idea
[20:35] mikko	im gonna play a game of starcraft2
[20:35] mikko	bbl
[20:35] Steve-o	:D

ZeroMq Home

Sunday September 25, 2011