You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by hwl <wl...@ncs.com.sg> on 2010/02/07 08:36:08 UTC

activemq 5.3 slower than 4.1.2?

Our application previously ran on activemq 4.1.2 and was able to achieve <
500ms response time in average. However, some locking issue was observed
(WAITING on edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar)
and we upgraded the activemq component to 5.3.0. The locking issue does not
occur so far, but the performance drops to >2 second on average response
time which breaches the performance critieria. 

Any idea what could introduce such significant overhead and any way to tune
it?

Our messaging service is non-persistent and activemq has been configured
accordingly.

thanks!

- Wanling
-- 
View this message in context: http://old.nabble.com/activemq-5.3-slower-than-4.1.2--tp27486527p27486527.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: activemq 5.3 slower than 4.1.2?

Posted by hwl <wl...@ncs.com.sg>.
Thanks rajdavies for the quick response. 

it will be difficult or time-consuming to create a junit test case, as the
application is complex and uses UCP as the receiving interface. 

Maybe i can give more info on the problem encountered here. We found out the
threads in our application were stuck with the following error through
JConsole when we used activemq 4.1.2.
Name: ClearTextSMSUCPAdp02-UcpAdapterUcpTextHandler_015
State: WAITING on
edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar@445e0acb
Total blocked: 33,632  Total waited: 24,745

Stack trace: 
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:485)
edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar.await(CondVar.java:76)
edu.emory.mathcs.backport.java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:319)
org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:42)
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:75)
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1175)
org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1663)
org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:542)

The search result from the web suggests it's fixed at a higher version of
activemq, and hence we decided to give the latest version a try, but found
out our application slowed down. I also tried using a lower version,
activemq 5.1.0. The application failed within seconds and we are yet to
identify the root cause. If it's hard to investigate the difference, can we
solve the locking issue by applying some patches to activemq 4.1.2 copy
instead? Or is there any better suggestion?


rajdavies wrote:
> 
> There's been a lot of changes - if you could provide a junit test case  
> that is representative of your application - that would enable us to  
> investigate the difference
> 
> On 7 Feb 2010, at 07:36, hwl wrote:
> 
>>
>> Our application previously ran on activemq 4.1.2 and was able to  
>> achieve <
>> 500ms response time in average. However, some locking issue was  
>> observed
>> (WAITING on  
>> edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar)
>> and we upgraded the activemq component to 5.3.0. The locking issue  
>> does not
>> occur so far, but the performance drops to >2 second on average  
>> response
>> time which breaches the performance critieria.
>>
>> Any idea what could introduce such significant overhead and any way  
>> to tune
>> it?
>>
>> Our messaging service is non-persistent and activemq has been  
>> configured
>> accordingly.
>>
>> thanks!
>>
>> - Wanling
>> -- 
>> View this message in context:
>> http://old.nabble.com/activemq-5.3-slower-than-4.1.2--tp27486527p27486527.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
> 
> Rob Davies
> http://twitter.com/rajdavies
> I work here: http://fusesource.com
> My Blog: http://rajdavies.blogspot.com/
> I'm writing this: http://www.manning.com/snyder/
> 
> 
> 
> 
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/activemq-5.3-slower-than-4.1.2--tp27486527p27494788.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: activemq 5.3 slower than 4.1.2?

Posted by Rob Davies <ra...@gmail.com>.
There's been a lot of changes - if you could provide a junit test case  
that is representative of your application - that would enable us to  
investigate the difference

On 7 Feb 2010, at 07:36, hwl wrote:

>
> Our application previously ran on activemq 4.1.2 and was able to  
> achieve <
> 500ms response time in average. However, some locking issue was  
> observed
> (WAITING on  
> edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar)
> and we upgraded the activemq component to 5.3.0. The locking issue  
> does not
> occur so far, but the performance drops to >2 second on average  
> response
> time which breaches the performance critieria.
>
> Any idea what could introduce such significant overhead and any way  
> to tune
> it?
>
> Our messaging service is non-persistent and activemq has been  
> configured
> accordingly.
>
> thanks!
>
> - Wanling
> -- 
> View this message in context: http://old.nabble.com/activemq-5.3-slower-than-4.1.2--tp27486527p27486527.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Rob Davies
http://twitter.com/rajdavies
I work here: http://fusesource.com
My Blog: http://rajdavies.blogspot.com/
I'm writing this: http://www.manning.com/snyder/






Re: activemq 5.3 slower than 4.1.2?

Posted by Rob Davies <ra...@gmail.com>.
It might be worth turning off producer flow control - see http://cwiki.apache.org/ACTIVEMQ/producer-flow-control.html

On 9 Feb 2010, at 02:04, hwl wrote:

>
> Found a thread in the forum on similar issue that links to
> http://cwiki.apache.org/ACTIVEMQ/my-producer-blocks.html.
>
> We tried, and do not observe the blocking issue so far. However, the
> performance dropped, with the average response time now at about  
> 600ms. We
> set the usageManager limit to 128MB and tried 512MB as well. Are  
> there some
> other configs that we can tune further?
>
> Thanks!
>
>
>
> hwl wrote:
>>
>> Our application previously ran on activemq 4.1.2 and was able to  
>> achieve <
>> 500ms response time in average. However, some locking issue was  
>> observed
>> (WAITING on  
>> edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar)
>> and we upgraded the activemq component to 5.3.0. The locking issue  
>> does
>> not occur so far, but the performance drops to >2 second on average
>> response time which breaches the performance critieria.
>>
>> Any idea what could introduce such significant overhead and any way  
>> to
>> tune it?
>>
>> Our messaging service is non-persistent and activemq has been  
>> configured
>> accordingly.
>>
>> thanks!
>>
>> - Wanling
>>
>
> -- 
> View this message in context: http://old.nabble.com/activemq-5.3-slower-than-4.1.2--tp27486527p27509403.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Rob Davies
http://twitter.com/rajdavies
I work here: http://fusesource.com
My Blog: http://rajdavies.blogspot.com/
I'm writing this: http://www.manning.com/snyder/






Re: activemq 5.3 slower than 4.1.2?

Posted by hwl <wl...@ncs.com.sg>.
Found a thread in the forum on similar issue that links to
http://cwiki.apache.org/ACTIVEMQ/my-producer-blocks.html.

We tried, and do not observe the blocking issue so far. However, the
performance dropped, with the average response time now at about 600ms. We
set the usageManager limit to 128MB and tried 512MB as well. Are there some
other configs that we can tune further?

Thanks!



hwl wrote:
> 
> Our application previously ran on activemq 4.1.2 and was able to achieve <
> 500ms response time in average. However, some locking issue was observed
> (WAITING on edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar)
> and we upgraded the activemq component to 5.3.0. The locking issue does
> not occur so far, but the performance drops to >2 second on average
> response time which breaches the performance critieria. 
> 
> Any idea what could introduce such significant overhead and any way to
> tune it?
> 
> Our messaging service is non-persistent and activemq has been configured
> accordingly.
> 
> thanks!
> 
> - Wanling
> 

-- 
View this message in context: http://old.nabble.com/activemq-5.3-slower-than-4.1.2--tp27486527p27509403.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.