<div dir="ltr">Hi! <br><br>Sorry for the long delay. I did some more tests and found a way to speed things up.<br>After changing {ack_mode, on_confirm} to {ack_mode, on_publish} things started to work well. <br>Which means that the speed of reading the messages from the queue NodeB was the speed they <br>
were published to the queue on NodeA. <br><br>Before this change (when &#39;on_confirm&#39; was set) messages where piling up in the queue on NodeB.<br>So if i published 100 messages per sec into a queue on nodeA, the queue on nodeB would receive all of those and the queue on nodeA would be empty (as it should). But the PHP script on nodeB (below) would read something like 3-8 messages per sec and the rest (92-97 messages per sec) would keep piling up in the queue on nodeB. <br>
That is until i completely stopped writing new messages to the queue on nodeA. Then this script will read messages like crazy until the queue on nodeB was completely empty. <br><br>So I left with a couple of questions. What is causing the write and the read to be so uneven with &#39;on_confirm&#39; given that there no real resources problem? Is this a bug or a feature?<br>
How much reliability do I lose if i use &#39;on_publish&#39; ? Is there a chance messages can just disappear with &#39;on_publish&#39; ? <br><br>Here is the outline of my php test reader, very simple: <br><br>&lt;?php<br>
$connection = new AMQPConnection();<br>$connection-&gt;setLogin(&quot;&lt;login_nodeb&gt;&quot;);<br>$connection-&gt;setPassword(&quot;&lt;password_nodeb&quot;);<br>$connection-&gt;setVhost(&quot;vhostB&quot;);<br>$connection-&gt;connect();<br>
<br>if (!$connection-&gt;isConnected()) {<br>    die(&#39;Not connected :(&#39;. PHP_EOL);<br>}<br>$channel    = new AMQPChannel($connection);<br>$queue      = new AMQPQueue($channel);<br>$queue-&gt;setName(&#39;queueB&#39;);<br>
<br>while(true) {<br>        while($queue-&gt;get(AMQP_AUTOACK)) {<br>           /* do stuff here, count messages, run mps stats etc... */<br>        }<br>        /* sleep some not to eat the whole cpu */<br>        sleep(1);<br>
}<br><br><br>Thanks, <br>Boris<br><br><div class="gmail_quote">On Wed, Feb 13, 2013 at 5:52 PM, Simon MacMullen <span dir="ltr">&lt;<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That sounds very wrong.<br>
<br>
Which version of RabbitMQ are you using? Can you post (a cut down version of) your PHP script somewhere? (I have no familiarity with the PHP client but I&#39;d like to see what it&#39;s doing...)<br>
<br>
Cheers, Simon<div><div><br>
<br>
On 13/02/13 14:33, bratner bratner wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
Hi!<br>
<br>
My setup includes a rabbitmq-c application that publishes messages on<br>
node A.<br>
The publishing rate is about 200mps, each message can be up to 10Kb.<br>
<br>
Shovel (node A) is configured to move them to node B.<br>
On node B i&#39;m dequeuing the messages with a PHP test script with<br>
$queue-&gt;get(AMQP_AUTOACK).<br>
If i keep the publishing rate at 200mps then i can see that the queue on<br>
node A is empty and the Q on node B is<br>
filling up. The read-rate of my test script is really low.<br>
<br>
If i stop the publishing, 3-5 seconds later, my test script starts<br>
reading like crazy until the queue on node B is empty.<br>
<br>
Even If I slow down the publishing rate to 5mps , same is happening ,<br>
messages are piling up on node B until i dial down the pressure.<br>
<br>
This problem disappears if I set ack_mode to on_publish or no_ack. In<br>
this case the reader script reads with the publishing speed.<br>
<br>
My configuration :<br>
<br>
<br>
<br>
[<br>
{rabbit, [<br>
{log_levels, [{connection, error}]}<br>
]},<br>
{rabbitmq_shovel,<br>
[ {shovels, [ {messagemover, [<br>
{sources, [<br>
{broker, &quot;amqp://usera:pass@localhost/<u></u>vhosta<br></div></div>
&lt;amqp://cdrposter:4VkI6MKH@<u></u>localhost/sipout&gt;&quot;},<div><br>
{declarations, [<br>
{&#39;exchange.declare&#39;,[{<u></u>exchange, &lt;&lt;&quot;my-fanout&quot;&gt;&gt;},{type,<br>
&lt;&lt;&quot;fanout&quot;&gt;&gt;},durable]},<br>
{&#39;queue.declare&#39;,[{queue,&lt;&lt;&quot;<u></u>messages&quot;&gt;&gt;},durable]},<br>
{&#39;queue.bind&#39;,[{exchange, &lt;&lt;&quot;my-fanout&quot;&gt;&gt;},{queue, &lt;&lt;&quot;messages&quot;&gt;&gt;}]}<br>
]}<br>
]},<br>
{destinations, [<br>
{brokers, [ &quot;amqp://userb:pass@nodeB/<u></u>vhostb<br></div>
&lt;amqp://<a href="http://cdr_manager:Ci2XOb3b@10.200.10.218/cdrs" target="_blank">cdr_manager:Ci2XOb3b@<u></u>10.200.10.218/cdrs</a>&gt;&quot; ]},<div><br>
{declarations, [<br>
{&#39;exchange.declare&#39;,[{<u></u>exchange, &lt;&lt;&quot;my-fanout&quot;&gt;&gt;},{type,<br>
&lt;&lt;&quot;fanout&quot;&gt;&gt;},durable]},<br>
{&#39;queue.declare&#39;,[{queue,&lt;&lt;&quot;<u></u>messages&quot;&gt;&gt;},durable]},<br>
{&#39;queue.bind&#39;,[{exchange, &lt;&lt;&quot;my-fanout&quot;&gt;&gt;},{queue, &lt;&lt;&quot;messages&quot;&gt;&gt;}]}<br>
]}<br>
]},<br>
{queue, &lt;&lt;&quot;messages&quot;&gt;&gt;},<br>
{prefetch_count, 200},<br>
{ack_mode, on_confirm},<br>
{publish_properties, [{delivery_mode, 2}]},<br>
{reconnect_delay, 5}<br>
]}<br>
]}<br>
]}<br>
].<br>
<br>
<br>
Thank you,<br>
Boris.<br>
<br>
<br></div>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
<br><span><font color="#888888">
</font></span></blockquote><span><font color="#888888">
<br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></blockquote></div><br></div>