Thanks Alexis!<div>Just for the record,<br><div>I think I&#39;ve hit the�ceiling of the throughput ONE queue can provide, because there is not difference between 12 and 24 clients in my tests.</div><div>Faster clients? not really the issue either, my workers just consume and reply, do no extra computation.</div>
<div><br></div><div>Anyway, non-HA queue it&#39;s almost 5 times faster than HA in my tests.</div><div>I wasn&#39;t expecting such a significant difference.</div><div><br></div><div>BRs</div><div>/stone</div><div><br><div class="gmail_quote">
On Thu, Mar 29, 2012 at 10:47 AM, Alexis Richardson <span dir="ltr">&lt;<a href="mailto:alexis@rabbitmq.com">alexis@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">
HA replicates data to queue mirrors, which increases the amount of<br>
networking and data processing per message. �This can impact<br>
throughput.<br>
<br>
You may find you can get higher throughput by using more clients, or a<br>
faster client.<br>
<br>
alexis<br>
<div><div class="h5"><br>
<br>
On Thu, Mar 29, 2012 at 9:35 AM, stone &lt;<a href="mailto:zmstone@gmail.com">zmstone@gmail.com</a>&gt; wrote:<br>
&gt; Hi again.<br>
&gt;<br>
&gt; The traffic rate hit almost 9000/s if the &quot;RPC&quot; queue is non-HA.<br>
&gt; Could someone explain a little bit why HA impact the throughput that much?<br>
&gt;<br>
&gt; BRs<br>
&gt; /stone<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Mar 28, 2012 at 9:23 PM, stone &lt;<a href="mailto:zmstone@gmail.com">zmstone@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi<br>
&gt;&gt;<br>
&gt;&gt; I have a use case which is very similar to RPC:<br>
&gt;&gt; The clients subscribe to their own queues bound to routing key<br>
&gt;&gt; &quot;response.myname&quot;,<br>
&gt;&gt; and they publish messages with routing key &quot;request.myname&quot;, then wait for<br>
&gt;&gt; response.<br>
&gt;&gt;<br>
&gt;&gt; On the other side of the broker, there is this RPC queue, bound to routing<br>
&gt;&gt; key &quot;request.#&quot;,<br>
&gt;&gt; many workers consume from this queue, process the messages then send back<br>
&gt;&gt; response.<br>
&gt;&gt;<br>
&gt;&gt; The request size is around 10K bytes, response is just few bytes, and all<br>
&gt;&gt; &quot;RPC&quot;s are synchronized calls.<br>
&gt;&gt; i.e. client wait for response before send another request.<br>
&gt;&gt;<br>
&gt;&gt; After some benchmark tests, we found that the message rate of the RPC<br>
&gt;&gt; queue hits around 1400.<br>
&gt;&gt; It doesn&#39;t help by increasing the number of publishers or consumers, or<br>
&gt;&gt; both.<br>
&gt;&gt;<br>
&gt;&gt; Hope it&#39;s enough background info to finally ask my question:<br>
&gt;&gt; what could possibly be the bottleneck in my tests, and how to get higher<br>
&gt;&gt; throughput ?<br>
&gt;&gt;<br>
&gt;&gt; -----------------env-------------------<br>
&gt;&gt; Rabbit version:�2.7.1<br>
&gt;&gt; Memory high watermark: 25G<br>
&gt;&gt; CPU (24 processors) model: Intel(R) Xeon(R) CPU X5690 �@ 3.47GH<br>
&gt;&gt;<br>
&gt;&gt; BRs<br>
&gt;&gt; /stone<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; rabbitmq-discuss mailing list<br>
&gt; <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
&gt; <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>
&gt;<br>
</blockquote></div><br></div></div>