From: "Iñaki Baz Castillo" Date: 2010-01-08T02:51:56+09:00 Subject: Re: Non-blocking communication between Ruby processes El Jueves, 7 de Enero de 2010, Robert Klemme escribió: > I don't know about your requirements. Just try it out - you can start > multiple clients and vary the number of threads and the queue size in > the server at will. To me it seemed pretty fast. I did > > $ for i in 1 2 3 4 5 6 7 8 9 10; do ./c.rb & done > > and message came really fast. Also note that each client prints timing > so you can see how fast it is on your machine. > > If you need more performance then I'm sure you'll find a Ruby binding to > any of the queuing framework like GNU Queue, NQS and whatnot. But I'd > start with the simple DRb based solution. It's easily done, you have > everything you need and do not need to install extra software, not even > gems. Thanks a lot. I've tryed a code similar to this one: http://www.idle-hacking.com/2007/11/iopipe-for-interprocess-communication/ It uses a pipe file (of course there is no queue at all). Well, sending 100000 strings (with a loop) it takes 2-3 seconds to receive and print all the received data. however using the DRb solution it just didn't finish (I had to interrupt the process after 30 seconds due to CPU usage). I'd like a simple solution. Using DRb could be nice. However using a pipe file seems simpler and faster. The doubt I have now is about how secure is a pipe. Could it leak memory if some process die or the reader process is not so fast to handle the received data? > I just notice, there was a bug in my code: I used Benchmark.times which > prints timings of the current process. What I meant was > Benchmark.measure. I have changed the code a bit so you can easy > experiment with queue ssizes, thread counts and message counts (see below). > > With this command line > > t=10;for i in `seq 1 $t`; do ./c.rb 10000 >"cl-$i"& done; for i in `seq > 1 $t`; do wait; done; cat cl-* > > I get pretty good timings of 7.6ms / msg with unlimited Queue size and > default thread count (5) for this unrealistic test that the queue is > hammered. Really thanks a lot, I'll try it. -- Iñaki Baz Castillo