<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 25, 2013 at 3:37 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">First of all, thank you for taking the time to generate a test case. I haven't reproduced anything yet, but rest assured that I will attempt to do so.<br>
<br>
I do have some quibbles with a couple of your assertions though:</blockquote><div><br></div><div>Great! Part of this conversation is to help me get up to speed quickly on rabbit internals and architecture, since I'm relatively new to it, and we're in the middle of deploying it for a bunch of different uses. So, please correct me if I've misunderstood its behaviour or design. :)<br>
</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-rabbitmq_management listener [{port,4444$n},{redirect_old_port,false}]<br>
<br>
This redirect port will be going away in 3.3.0.<div class="im"><br></div></blockquote><div><br></div><div>Ahhh, this does make sense, and you're right, it doesn't seem to have an adverse affects on cluster operations.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"></div>
Err, your script invokes amqp-publish(1) in a loop. 100,000 times. I suspect most of the slowness is due to the time taken to fork that many processes, open and close that many AMQP connections, and so on. I would guess this goes faster on an SSD because you can fork() faster.<br>
</blockquote><div><br></div><div>Hmmm... I wouldn't expect this to be the case, since I can fork 100000 echos is about 1s on this box. I am willing to admit that there could be issues in the way the data's being generated out of bash, or for any number of other reasons though. However, we did see a cluster of 5 machines backed by 7200 RPM disks get swamped with IO unexpectedly early, which is the issue I'm trying to reproduce, so I'll work harder on a better test case.<br>
</div><div>�<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Certainly I can populate 100 queues with 1,000 messages each in a rather small fraction of a second with the PerfTest tool (<a href="http://www.rabbitmq.com/java-tools.html" target="_blank">http://www.rabbitmq.com/java-tools.html</a>) if the same message goes to all queues 1,000 times, or in less than 10 seconds if each message is distinct.<br>
</blockquote><br></div><div class="gmail_quote">Good to know. I'll be sure to use this when I rework this test case.<br><br>Graeme<br></div></div></div>