Min,<div><br></div><div>Thanks for this!  Sorry I have been so quiet, I have been sick for the last few days.<br><br><div class="gmail_quote">On Thu, Jul 22, 2010 at 2:22 AM, MinRK <span dir="ltr">&lt;<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I have the basic queue built into the controller, and a kernel embedded into the Engine, enough to make a simple performance test.<div>
<br></div><div>I submitted 32k simple execute requests in a row (round robin to engines, explicit multiplexing), then timed the receipt of the results (tic each 1k). I did it once with 2 engines, once with 32. (still on a 2-core machine, all over tcp on loopback).</div>



<div><br></div><div>Messages went out at an average of 5400 msgs/s, and the results came back at ~900 msgs/s.</div><div>So that&#39;s 32k jobs submitted in 5.85s, and the last job completed and returned its result 43.24s  after the submission of the first one (37.30s for 32 engines). On average, a message is sent and received every 1.25 ms. When sending very small number of requests (1-10) in this way to just one engine, it gets closer to 1.75 ms round trip.</div>



<div><br></div></blockquote><div><br></div><div>This is great!  For reference, what is your ping time on localhost?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div></div><div>In all, it seems to be a good order of magnitude quicker than the Twisted implementation for these small messages.</div><div><br></div></blockquote><div><br></div><div>That is what I would expect.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div><div>Identifying the cost of json for small messages:</div><div><br>

</div><div>Outgoing messages go at 9500/s if I use cPickle for serialization instead of json. Round trip to 1 engine for 32k messages: 35s. Round trip to 1 engine for 32k messages with json: 53s.</div><div><br></div><div>


It would appear that json is contributing 50% to the overall run time.</div><div><br></div></blockquote><div><br></div><div>Seems like we know what to do about json now, right?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div></div><div>With %timeit x.loads(x.dumps(msg))</div><div>on a basic message, I find that json is ~15x slower than cPickle.</div><div>And by these crude estimates, with json, we spend about 35% of our time serializing, as opposed to just 2.5% with pickle.</div>


<div><br></div><div><div>I attached a bar plot of the average replies per second over each 1000 msg block, overlaying numbers for 2 engines and for 32. I did the same comparing pickle and json for 1 and 2 engines.</div></div>


<div><br></div><div>The messages are small, but a tiny amount of work is done in the kernel.</div><div>The jobs were submitted like this:</div><div><div>        for i in xrange(32e3/len(engines)):</div><div>          for eid,key in engines.iteritems():</div>



<div>            thesession.send(queue, &quot;execute_request&quot;, dict(code=&#39;id=%i&#39;%(int(eid)+i)),ident=str(key))</div></div><div><br></div><div><br></div></blockquote><div><br></div><div><br></div><div>One thing that is *really* significant is that the requests per/second goes up with 2 engines connected!  Not sure why this is the case by my guess is that 0MQ does the queuing/networking in a separate thread and it is able to overlap logic and communication.  This is wonderful and bodes well for us.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>Brian</div><div> </div></div><br><br clear="all"><br>-- <br>Brian E. Granger, Ph.D.<br>Assistant Professor of Physics<br>Cal Poly State University, San Luis Obispo<br><a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a><br>
<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
</div>