Franck,<div><br></div><div>Have you checked the timestamps of the involved machines? Sounds like a 4min time difference between the two clocks.</div><div><br></div><div>Pradeep</div><div><a href="http://www.masplantiz.com">www.masplantiz.com</a><br>

<br><div class="gmail_quote">On Tue, Feb 2, 2010 at 10:18 PM, Matthew Sackman <span dir="ltr">&lt;<a href="mailto:matthew@lshift.net">matthew@lshift.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi Frank,<br>
<div class="im"><br>
On Tue, Feb 02, 2010 at 04:26:58PM +0000, Matthew Sackman wrote:<br>
&gt; Not really too sure what to suggest, but others on the list have<br>
&gt; reported better throughput when increasing buffers in Rabbit<br>
<br>
</div>Also, you&#39;re using the python client, to do performance testing, which<br>
is a little questionable - in our experience the python clients tend to<br>
perform badly. I&#39;d suggest you test using our Java client which contains<br>
an example program called MulticastMain which is pretty flexible for<br>
testing performance and sustainable throughput.<br>
<br>
>From the rabbitmq-java-client directory:<br>
ant clean dist<br>
cd build/dist<br>
sh runjava.sh com/rabbitmq/examples/MulticastMain -s 1000000 -r 25 -a -z 20 -q 1<br>
<br>
where the -s parameter specifies the size, in bytes, the -r parameter<br>
specifies the sending rate, -a turns on auto-ack, which you may want for<br>
this, -z says how long to run the test for (in seconds) and -q sets the<br>
qos on the consumer to 1.<br>
<br>
This will create one producer and one consumer on the same box. You<br>
should vary the rate (-r) until the sending rates and receiving rates<br>
are balanced and sustainable (I tend to watch the reported latencies -<br>
if they keep increasing, then it&#39;s not balanced).<br>
<br>
Other if you just provide -? then it&#39;ll print out all the options. If<br>
you want to use different machines for producer and consumer then you<br>
can use -x 0 to turn off producers, and -y 0 to turn off consumers on<br>
each box respectively. If you do do that, then you&#39;ll also need to<br>
specify at least -e to name the exchange, and likely set -t to fanout<br>
otherwise it&#39;ll attempt to use a private queue of the default direct<br>
exchange and thus not route messages to the consumer. Also, start the<br>
consumer first.<br>
<br>
So, the consumer might look like this:<br>
<br>
sh runjava.sh com/rabbitmq/examples/MulticastMain -s 10000000 -r 1 -a -z 20 -q 1 -x 0 -e my_exchage -t fanout<br>
<br>
whilst the producer looks like:<br>
<br>
sh runjava.sh com/rabbitmq/examples/MulticastMain -s 10000000 -r 1 -a -z 20 -q 1 -y 0 -e my_exchage -t fanout<br>
<br>
These certainly work for me.<br>
<div><div></div><div class="h5"><br>
Matthew<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>