Nov 27th, 2011, 12:57 AM
performance of amqp-inbound-gateway with various values of concurrent-consumer
I am using amqp-inbound-gateway in one of my projects to receive/send messages over a synchronous call.
I was playing around with different values of concurrent-consumer.What i am seeing is that the performance studily increases from 1 to 15 concurrent-consumer threads. Beyond 15 there is no much increase in the performance. In fact i noticed a performace degradation for values 25 and 50. Do some body have any idea about an ideal value for concurrent threads ?
My environment/settings are some thing like this.
Broker :rabbit mq
Exchange :direct exchange
Queue Type : non execlusive,durable,
Consumer from Q : 1 to 50 ( controlled with the concurrent-consumer of amqp-inbound-gateway
My requests /response are text/plain types (xml) and the request is of size 400 bytes always ,and my response are of various sizes ( 400 bytes ,4k,40k,400k,4m).
I run a program where 10 message producers produces message in parallel. Each message produces runs a loop of 1000 times and produces 1000 messages.
There are 50 concurrent consumers listening to these messages from same Queue.
I am seeing that the performance is much much slower with this setting.
However, when i have 10 message consumers (concurrent-consumer =10), i see my turn around time are much better.(This is true for payloads of all size (400 b to 4m).
I found that the turn around time with 10 consumers is almost half of that of with 50 consumers.
I am not able to explain the behaviour:
Questions in my mind are :
-Is the overhead of managing 50 consumers (50 threads in si) much more than my message turn around time itself?
-Could the bottle neck be in rabbit broker?
-Could it be collision? i.e more than one consumer tries to pick up the same contend for picking the same message,and only one of them picks it up after negotiation with the broker (and the time for resolving the collision) is decreasing the through put?
If some one have already done some research/have any idea, please throw up some light.
Nov 27th, 2011, 05:47 AM
How many processor cores do you have? Simply ramping up threads and expecting that to improve throughput wont work and as I suspect you are already seeing switching threads on and off the core can be expensive. Increasing the probability that needs to be done by the OS by increasing threads will start decrease throughput at some point.
Regarding an ideal number of threads predicting that is hard but unless there is lots of blocking it is likely to be found with a low multiplier of the number of cores and may even be a multiplier of one.
When using AMQP you might also need to consider channels per connection. AMQP support in Spring generally opens one socket connection and shares that between multiple consumers who each use a channel to talk to the broker. In some situations you may find more than one TCP connection helps but I don't think thats your main issue here.
Nov 30th, 2011, 01:38 AM
12 physical cores and 24 with hyper thread.
Tags for this Thread