Sunday September 25, 2011

[Time] NameMessage
[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, server code
[17:21] mxp
[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://
[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
[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 "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