[rabbitmq-discuss] Very slow get (dequeue) on node B if shovel on node A is configured with {ack_mode, on_confirm}
Simon MacMullen
simon at rabbitmq.com
Thu Feb 21 15:57:25 GMT 2013
Hi. If the shovel is on node A then {ack_mode, on_publish} is not
particularly safe - if the network connection goes down then you will
lose messages that were on the wire.
If the shovel were to be running on node B then {ack_mode, on_publish}
would be safer, as it would tolerate network failures (but not a crash
at node B).
on_confirm would still be better. Of course, since you're consuming in
autoack mode in the php script you can lose messages there anyway...
You didn't say which version of RabbitMQ you were running. The script
seems perfectly reasonable (I assume that you are not doing anything
AMQPish in the part elided by "/* do stuff here, count messages, run mps
stats etc... */").
So it's a bit of a puzzle. If confirms + persistence are so much slower
than persistence alone, then I wonder if somehow you have a machine that
fsyncs very slowly, since that's the primary difference in what node B
will be doing.
Cheers, Simon
On 21/02/13 15:10, bratner bratner wrote:
> Hi!
>
> Sorry for the long delay. I did some more tests and found a way to speed
> things up.
> After changing {ack_mode, on_confirm} to {ack_mode, on_publish} things
> started to work well.
> Which means that the speed of reading the messages from the queue NodeB
> was the speed they
> were published to the queue on NodeA.
>
> Before this change (when 'on_confirm' was set) messages where piling up
> in the queue on NodeB.
> 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.
> 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.
>
> So I left with a couple of questions. What is causing the write and the
> read to be so uneven with 'on_confirm' given that there no real
> resources problem? Is this a bug or a feature?
> How much reliability do I lose if i use 'on_publish' ? Is there a chance
> messages can just disappear with 'on_publish' ?
>
> Here is the outline of my php test reader, very simple:
>
> <?php
> $connection = new AMQPConnection();
> $connection->setLogin("<login_nodeb>");
> $connection->setPassword("<password_nodeb");
> $connection->setVhost("vhostB");
> $connection->connect();
>
> if (!$connection->isConnected()) {
> die('Not connected :('. PHP_EOL);
> }
> $channel = new AMQPChannel($connection);
> $queue = new AMQPQueue($channel);
> $queue->setName('queueB');
>
> while(true) {
> while($queue->get(AMQP_AUTOACK)) {
> /* do stuff here, count messages, run mps stats etc... */
> }
> /* sleep some not to eat the whole cpu */
> sleep(1);
> }
>
>
> Thanks,
> Boris
>
> On Wed, Feb 13, 2013 at 5:52 PM, Simon MacMullen <simon at rabbitmq.com
> <mailto:simon at rabbitmq.com>> wrote:
>
> That sounds very wrong.
>
> 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'd like to see what it's doing...)
>
> Cheers, Simon
>
>
> On 13/02/13 14:33, bratner bratner wrote:
>
> Hi!
>
> My setup includes a rabbitmq-c application that publishes
> messages on
> node A.
> The publishing rate is about 200mps, each message can be up to 10Kb.
>
> Shovel (node A) is configured to move them to node B.
> On node B i'm dequeuing the messages with a PHP test script with
> $queue->get(AMQP_AUTOACK).
> If i keep the publishing rate at 200mps then i can see that the
> queue on
> node A is empty and the Q on node B is
> filling up. The read-rate of my test script is really low.
>
> If i stop the publishing, 3-5 seconds later, my test script starts
> reading like crazy until the queue on node B is empty.
>
> Even If I slow down the publishing rate to 5mps , same is
> happening ,
> messages are piling up on node B until i dial down the pressure.
>
> This problem disappears if I set ack_mode to on_publish or
> no_ack. In
> this case the reader script reads with the publishing speed.
>
> My configuration :
>
>
>
> [
> {rabbit, [
> {log_levels, [{connection, error}]}
> ]},
> {rabbitmq_shovel,
> [ {shovels, [ {messagemover, [
> {sources, [
> {broker, "amqp://usera:pass@localhost/__vhosta
> <amqp://cdrposter:4VkI6MKH@__localhost/sipout>"},
>
> {declarations, [
> {'exchange.declare',[{__exchange, <<"my-fanout">>},{type,
> <<"fanout">>},durable]},
> {'queue.declare',[{queue,<<"__messages">>},durable]},
> {'queue.bind',[{exchange, <<"my-fanout">>},{queue, <<"messages">>}]}
> ]}
> ]},
> {destinations, [
> {brokers, [ "amqp://userb:pass@nodeB/__vhostb
> <amqp://cdr_manager:Ci2XOb3b@__10.200.10.218/cdrs
> <http://cdr_manager:Ci2XOb3b@10.200.10.218/cdrs>>" ]},
>
> {declarations, [
> {'exchange.declare',[{__exchange, <<"my-fanout">>},{type,
> <<"fanout">>},durable]},
> {'queue.declare',[{queue,<<"__messages">>},durable]},
> {'queue.bind',[{exchange, <<"my-fanout">>},{queue, <<"messages">>}]}
> ]}
> ]},
> {queue, <<"messages">>},
> {prefetch_count, 200},
> {ack_mode, on_confirm},
> {publish_properties, [{delivery_mode, 2}]},
> {reconnect_delay, 5}
> ]}
> ]}
> ]}
> ].
>
>
> Thank you,
> Boris.
>
>
> _________________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.__rabbitmq.com
> <mailto:rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/__cgi-bin/mailman/listinfo/__rabbitmq-discuss
> <https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>
>
>
> --
> Simon MacMullen
> RabbitMQ, VMware
>
>
--
Simon MacMullen
RabbitMQ, VMware
More information about the rabbitmq-discuss
mailing list