You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by "hardik.rajani" <ha...@live.in> on 2010/04/13 12:38:25 UTC
Performance improvement via configuration
We have tried below conf but it is not making any difference in performance:
1) turned off persistent by setting broker as persistent="false"
2) set asynchronous and optimise acknowledge as below.
flowName="jms?jmsURL=tcp://localhost:61616?jms.useAsyncSend=true&optimizeAcknowledge=true"
3) Also we tried with flowname as jca instead of jms. In this case queue is
not being created for activemq.
Can anyone tell if we are making any mistake in above or do we need to
configure it any differently?
--
View this message in context: http://old.nabble.com/Performance-improvement-via-configuration-tp28225984p28225984.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Performance improvement via configuration
Posted by Rakesh Desai <rd...@asite.com>.
Hi iocanel,
Thanks for quick response.
I have attached our applicationContext.xml for your reference.
Can you please let us know how do we increase the maximum number of sessions
on the Jms Consumer?
Regards,
Rakesh
iocanel wrote:
>
>
> Rakesh Desai wrote:
>>
>> I am working with Hardik on this project, let me first give you details
>> about our components. We use…
>> servicemix 3.0
>> activeMQ 4.0.2
>> jencks 1.3
>> Spring 2.0
>> JBoss 4.0.2
>>
>
> Unfortunately, you are using version of servicemix and activemq that I am
> not familiar with (I've been using servicemix 3.3 and activemq 5.x and
> there are a lot of differences) so I can't really help regarding the
> configuration.
>
> From what you've told me so far I have the feeling that the problem lies
> in the processing part.
> Can you try to increase the maximum number of sessions on the Jms
> Consumer?
>
>
> Please sent me the application-context.xml or at least the jms
> configuration.
>
>
>
>
>
>
>
>
>
http://old.nabble.com/file/p28241270/applicationContext.xml
applicationContext.xml
--
View this message in context: http://old.nabble.com/Performance-improvement-via-configuration-tp28225984p28241270.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Performance improvement via configuration
Posted by iocanel <ca...@upstreamsystems.com>.
Rakesh Desai wrote:
>
> I am working with Hardik on this project, let me first give you details
> about our components. We use…
> servicemix 3.0
> activeMQ 4.0.2
> jencks 1.3
> Spring 2.0
> JBoss 4.0.2
>
Unfortunately, you are using version of servicemix and activemq that I am
not familiar with (I've been using servicemix 3.3 and activemq 5.x and there
are a lot of differences) so I can't really help regarding the
configuration.
>From what you've told me so far I have the feeling that the problem lies in
the processing part.
Can you try to increase the maximum number of sessions on the Jms Consumer?
Please sent me the application-context.xml or at least the jms
configuration.
-----
Ioannis Canellos
--
View this message in context: http://old.nabble.com/Performance-improvement-via-configuration-tp28225984p28239904.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Performance improvement via configuration
Posted by Rakesh Desai <rd...@asite.com>.
Hi icoanel,
I am working with Hardik on this project, let me first give you details
about our components. We use…
servicemix 3.0
activeMQ 4.0.2
jencks 1.3
Spring 2.0
JBoss 4.0.2
The answers to your query are as below:
1) The message flow is JMS (We have tried with SEDA also but we could not
see any performance improvement)
2) By ‘The servicemix thread pool configuration’ I understand you are
referring to servicemix.corePoolSize which has been introduced since
ServiceMix 3.1 whereas we use ServiceMix 3.0. We have not been able to find
any such setting in 3.0 version, is there any equivalent in 3.0 version?
3) In our load test we are using HTTPS protocol to receive the document. The
configuration for HTTPConenctor is as below:
When we try to change message flow to JCA instead of JMS, the messages do
not reach destination of HTTPConnector i.e. asiteMessageProxy.
<sm:activationSpec componentName="AsiteHttpBinding"
service="foo:AsiteHttpBinding" destinationService="foo:asiteMessageProxy ">
<sm:component>
<bean class="com.asite.supernova.bc.AsiteHttpConnector">
<property name="defaultInOut" value="false"/>
</bean>
</sm:component>
</sm:activationSpec>
<sm:activationSpec componentName="asiteMessageProxy"
service="foo:asiteMessageProxy" destinationService="foo:DroolsRouterPre">
<sm:component>
<bean class="com.asite.supernova.se.AsiteMessageProxy"
id="asiteMessageProxy"></bean>
</sm:component>
</sm:activationSpec>
4) Let me know if you want to take a look at the complete
application-context.xml, I can upload the same.
5) Regarding persistence configuration, please note that we had even tried
turning off persistent by setting broker as persistent="false". Even that
also did not improve performance. Is this correct or do we need to configure
it differently?
6) Another issue which we have observed is that during processing of even
150 documents memory shoots up from 250 MB to 800 MB. While analyzing heap
dump we see that two classes java.lan.string & Char[] comes at the top. Even
at start up & also during the process. Further analysis suggests that there
are loads of string objects like “url”, “JBoss4.0.2”, “using transformer”
etc. Is it some sort of verbose output generated by ServiceMix? Is there any
way we can stop this or reduce this?
Thanks
Rakesh
iocanel wrote:
>
> Hi Hardik,
>
> Could you please post some information about
> i)The Message flow,
> ii)The servicemix thread pool configuration
> iii) The Jms endpoint configuration?
> iv) The service that processes the documents. Its most probable that this
> is the bottleneck so we will need more info to help you tune.
>
> Some general improvements could be:
> i) Replace persistenceAdapter with kaha or kahadb:
> <!-- Kaha Persistence Adapter -->
> <amq:persistenceAdapter>
> <amq:kahaPersistenceAdapter directory="${some.dir}/activemq/kaha"/>
> </amq:persistenceAdapter>
>
> <amq:persistenceAdapter>
> <amq:kahaDB directory="${some.dir}/activemq/kahaDB"
> enableIndexWriteAsync="true"/>
> </amq:persistenceAdapter>
>
> In most cases I find kaha to be the fastest.
>
> ii) Use a vm cursor for pending messages:
> <amq:destinationPolicy>
> <amq:policyMap>
> <amq:policyEntries>
> <amq:policyEntry queue=">">
> <amq:pendingQueuePolicy>
> <amq:vmQueueCursor />
> </amq:pendingQueuePolicy>
> </amq:policyEntry>
> </amq:policyEntries>
> </amq:policyMap>
> </amq:destinationPolicy>
>
> iii) Use VM Transport to connect to the ActiveMQ Broker.
>
>
>
--
View this message in context: http://old.nabble.com/Performance-improvement-via-configuration-tp28225984p28239374.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Performance improvement via configuration
Posted by iocanel <ca...@upstreamsystems.com>.
Hi Hardik,
Could you please post some information about
i)The Message flow,
ii)The servicemix thread pool configuration
iii) The Jms endpoint configuration?
iv) The service that processes the documents. Its most probable that this is
the bottleneck so we will need more info to help you tune.
Some general improvements could be:
i) Replace persistenceAdapter with kaha or kahadb:
<!-- Kaha Persistence Adapter -->
<amq:persistenceAdapter>
<amq:kahaPersistenceAdapter directory="${some.dir}/activemq/kaha"/>
</amq:persistenceAdapter>
<amq:persistenceAdapter>
<amq:kahaDB directory="${some.dir}/activemq/kahaDB"
enableIndexWriteAsync="true"/>
</amq:persistenceAdapter>
In most cases I find kaha to be the fastest.
ii) Use a vm cursor for pending messages:
<amq:destinationPolicy>
<amq:policyMap>
<amq:policyEntries>
<amq:policyEntry queue=">">
<amq:pendingQueuePolicy>
<amq:vmQueueCursor />
</amq:pendingQueuePolicy>
</amq:policyEntry>
</amq:policyEntries>
</amq:policyMap>
</amq:destinationPolicy>
iii) Use VM Transport to connect to the ActiveMQ Broker.
--
View this message in context: http://old.nabble.com/Performance-improvement-via-configuration-tp28225984p28229700.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Performance improvement via configuration
Posted by "hardik.rajani" <ha...@live.in>.
Hi.
Our problem is that when we push around 300 documents the total processing
time comes out to be around 75-80 sec.
In order to improve this time we have taken various trials as written in
original post.
We have tried seda flow also but it is not improving performance of exchange
routing.
Here is our broker configuration:
<amq:broker>
<amq:managementContext>
<bean class="org.apache.activemq.broker.jmx.ManagementContext">
<property name="createConnector" value="true" />
</bean>
</amq:managementContext>
<amq:persistenceAdapter>
<amq:journaledJDBC journalLogFiles="10" dataDirectory="../data/amq"
dataSource="#dataSource"/>
</amq:persistenceAdapter>
<amq:transportConnectors>
<amq:transportConnector uri="tcp://hrajani:85?network=false"/>
</amq:transportConnectors>
<amq:networkConnectors>
</amq:networkConnectors>
</amq:broker>
Let me know if you need any more details.
Thanks,
Hardik
iocanel wrote:
>
> Its hard to tell, cause you are giving so little information about your
> setup.
>
> You could try Seda Flow too.
>
> If you need further help please post the activemq broker configuration.
> And give us more information on where exactly the problem lies.
>
--
View this message in context: http://old.nabble.com/Performance-improvement-via-configuration-tp28225984p28229453.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Performance improvement via configuration
Posted by iocanel <ca...@upstreamsystems.com>.
Its hard to tell, cause you are giving so little information about your
setup.
You could try Seda Flow too.
If you need further help please post the activemq broker configuration. And
give us more information on where exactly the problem lies.
--
View this message in context: http://old.nabble.com/Performance-improvement-via-configuration-tp28225984p28226577.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.