<div dir="ltr">Thanks for the info! I read the article, but we can't use that implementation since it seems to be kind of experimental and we need to mantain the app as stable as possible,<div><br></div><div>Regarding the prefetch count, I'm not really sure about how it works in the .net version. I've tried with this code _channel.BasicQos(0, 50, false) and the only difference I see is that unacked messages ratio keep constant. But there's no performance improvement.</div>
<div><br></div><div>We're using: <span style="color:rgb(68,68,68);font-family:Verdana,sans-serif;font-size:12px;text-align:right">RabbitMQ 3.2.2, </span><acronym class="" title="Erlang R16B03 (erts-5.10.4) [64-bit] [smp:4:4] [async-threads:30]" style="background-image:none;color:rgb(68,68,68);padding:0px;border-top-left-radius:2px;border-top-right-radius:2px;border-bottom-right-radius:2px;border-bottom-left-radius:2px;border-style:none none dotted;border-bottom-width:1px;font-family:Verdana,sans-serif;font-size:12px;text-align:right">Erlang R16B03</acronym></div>
<div><br></div><div><b>Setting prefetch count before consuming data:</b></div><div>Deliver 24/s</div><div>Ack 20~24/s</div><div>Published 1600/s</div><div><br></div><div><br></div><div><b>Without prefetch count:</b></div>
<div>Deliver 10~30/s</div><div>Ack 20~30/s</div><div>Published 1600/s</div><div><br></div><div>When we decreased the publish ratio (by adding sleep after sending each message) we could increase the deliver ratio up to 90/s, but when the number of messages within ready state start growing, the deliver ratio decreases to 20/s again.</div>
<div><br></div><div><br></div><div>Thanks!!!</div></div><div class="gmail_extra"><br clear="all"><div>Anni..</div>
<br><br><div class="gmail_quote">2014/1/22 Alvaro Videla <span dir="ltr"><<a href="mailto:videlalvaro@gmail.com" target="_blank">videlalvaro@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Have you considered the approaches explained here:<br>
<a href="http://www.rabbitmq.com/blog/2012/05/11/some-queuing-theory-throughput-latency-and-bandwidth/" target="_blank">http://www.rabbitmq.com/blog/2012/05/11/some-queuing-theory-throughput-latency-and-bandwidth/</a><br>
<br>
Also I think people could help you a bit more if you shared some<br>
numbers about number of messages, consumers, RabbitMQ and Erlang<br>
versions, and so on.<br>
<br>
Regards,<br>
<br>
Alvaro<br>
<br>
On Wed, Jan 22, 2014 at 9:51 PM, Anahi Hojnadel<br>
<<a href="mailto:anahi.hojnadel@gmail.com">anahi.hojnadel@gmail.com</a>> wrote:<br>
> Hi guys!<br>
><br>
> We have an application that has a publisher which sends messages to a<br>
> consumer which process those messages and then stores them in the DB.<br>
> Everything is working fine up to now, but the number of messages we're<br>
> receiving is getting bigger and performance is quite bad. We started to<br>
> analize where the bottleneck was and it seems to be in rabbit queues.<br>
><br>
> I've been reading many posts in Rabbit's blog about optimization but I<br>
> couldn't find how to solve the problem.<br>
><br>
> The main problem is that we're publishing messages faster than we can<br>
> consume them. When the number of messages in ready state (or in unacked<br>
> state) increases, the deliver ratio decrease considerably.<br>
><br>
> I've tried adding more consumers, sending messages more slowly (with time<br>
> sleep)... without luck.<br>
><br>
> I've seen that sending an ack for each message make things slower but we<br>
> actually need to ensure they're delivered. Our current ack ratio is too low,<br>
> so every time the number of unacked messages increases, the deliver ratio<br>
> decreases.<br>
><br>
> Do you have any ideas of what could I try to improve our process<br>
> performance? Or should I just make sure not to send more messages than my<br>
> current ack ratio? Is stacking acks and sending them in batches a safe<br>
> strategy to try out?<br>
><br>
> Adding more queues is not an option since it will add too much complexity to<br>
> our app.<br>
><br>
> Thanks!!<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="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-discuss" group.<br>
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/rabbitmq-discuss/BW62Tn9sQkE/unsubscribe" target="_blank">https://groups.google.com/d/topic/rabbitmq-discuss/BW62Tn9sQkE/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href="mailto:rabbitmq-discuss%2Bunsubscribe@googlegroups.com">rabbitmq-discuss+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a href="mailto:rabbitmq-discuss@googlegroups.com">rabbitmq-discuss@googlegroups.com</a>.<br>
Visit this group at <a href="http://groups.google.com/group/rabbitmq-discuss" target="_blank">http://groups.google.com/group/rabbitmq-discuss</a>.<br>
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank">https://groups.google.com/groups/opt_out</a>.<br>
</font></span></blockquote></div><br></div>