Thanks Alexis!<div>Just for the record,<br><div>I think I'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's almost 5 times faster than HA in my tests.</div><div>I wasn'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"><<a href="mailto:alexis@rabbitmq.com">alexis@rabbitmq.com</a>></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 <<a href="mailto:zmstone@gmail.com">zmstone@gmail.com</a>> wrote:<br>
> Hi again.<br>
><br>
> The traffic rate hit almost 9000/s if the "RPC" queue is non-HA.<br>
> Could someone explain a little bit why HA impact the throughput that much?<br>
><br>
> BRs<br>
> /stone<br>
><br>
><br>
> On Wed, Mar 28, 2012 at 9:23 PM, stone <<a href="mailto:zmstone@gmail.com">zmstone@gmail.com</a>> wrote:<br>
>><br>
>> Hi<br>
>><br>
>> I have a use case which is very similar to RPC:<br>
>> The clients subscribe to their own queues bound to routing key<br>
>> "response.myname",<br>
>> and they publish messages with routing key "request.myname", then wait for<br>
>> response.<br>
>><br>
>> On the other side of the broker, there is this RPC queue, bound to routing<br>
>> key "request.#",<br>
>> many workers consume from this queue, process the messages then send back<br>
>> response.<br>
>><br>
>> The request size is around 10K bytes, response is just few bytes, and all<br>
>> "RPC"s are synchronized calls.<br>
>> i.e. client wait for response before send another request.<br>
>><br>
>> After some benchmark tests, we found that the message rate of the RPC<br>
>> queue hits around 1400.<br>
>> It doesn't help by increasing the number of publishers or consumers, or<br>
>> both.<br>
>><br>
>> Hope it's enough background info to finally ask my question:<br>
>> what could possibly be the bottleneck in my tests, and how to get higher<br>
>> throughput ?<br>
>><br>
>> -----------------env-------------------<br>
>> Rabbit version: 2.7.1<br>
>> Memory high watermark: 25G<br>
>> CPU (24 processors) model: Intel(R) Xeon(R) CPU X5690 @ 3.47GH<br>
>><br>
>> BRs<br>
>> /stone<br>
>><br>
><br>
><br>
</div></div>> _______________________________________________<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>
</blockquote></div><br></div></div>