WSO2 BPS 3.2.0 - Performance Tuning - Know When, Why and How

• Following instructions are only applied to WSO2 BPS 3.2.0 . 
• All configuration files are located under $WSO2BPS-3.2.0_HOME/repository/conf/ directory

JDBC connections.

When ?

• When your application requires high throughput  

Why ?

• BPS server has two engines; Apache ODE BPEL processor and HumanTask engine. These two engines are tightly coupled with database layer. They persist every instance data into database. Thus to function BPS properly, you need to allocate enough database connections for BPS datasource.
• Both these engine share same BPS datasource and db connections. Thus generally we are recommending to allocate db connections 50-50 manner for a BPEL + HumanTask application.
• For example if you have total 100 db connections, for a BPEL + HumanTask application, you can use upto 50 db connections for ODE engine and leave the rest of the db connections for HumanTask operations.
• If you have only BPEL usecase, you can allocate many db connections ( see next topic) for ODE engine. 
• Also note that, even you have allocated higher number of db connections for BPS datasource, performance may not increase as excepted. One reason would be, there are no enough db sessions from database side. If that is the case, you need to increase number of db session from database side.  

How ?

• Configure BPS data source using datasources.properties file.
• eg: see highlighted section. 

 ...
 synapse.datasources.bpsds.validationQuery=SELECT 1 FROM DUAL
 synapse.datasources.bpsds.dsName=bpsds
 synapse.datasources.bpsds.maxActive=100
 synapse.datasources.bpsds.maxIdle=20
 synapse.datasources.bpsds.maxWait=10000

 

ODE Scheduler threads

When ?

•  When your application requires high throughput  

Why ?

• In ODE engine, every scheduler thread is associated with a db connection. So the rule of thumb is, number of ODE scheduler threads should be less than or equal to number of db connections allocated for ODE engine. Otherwise some threads may not work properly, because they can't acquire a db connections to work. 
• For example In BPEL + HumanTask scenario, if you have total 100 db connections, your can allocate 50 threads for ODE scheduler. This will grantee that at a given time, only 50 db connections are acquired by ODE engine.    

How ?

• Configure this via bps.xml.
• eg: 

    <tns:odeschedulerthreadpoolsize>50</tns:odeschedulerthreadpoolsize>

HTTP connections

When ?

• When your have lot of service invocations.(external or internal) 

Why ?

• When your BPEL processes do service invocations, they use http connections. By default this http connections are limited. Because of this, thread have to waits for http connections. 
• To avoid this, you can increase this value using Multithreaded Http Connection Manager Configuration. 
• If your processes do lot of service invocation to localhost ( or particular host), then it is required to increase maxConnectionsPerHost configuration as well.

How ?

•  enable this configuration using bps.xml

    <tns:MultithreadedHttpConnectionManagerConfig>
        <tns:maxconnectionsperhost value="350">
        <tns:maxtotalconnections value="400">
    </tns:maxtotalconnections>

 

TimeOuts 

When ?

•  When partner services take more time (slow) to response.

Why ?

• When partner services are slow or take more time to response, callee BPEL process's invoke activity fails due to message exchange timeout. By increasing time will avoid these kind of failures. 
• Also note that, slow partner services will slow entire BPEL process. This will cause to timeout the client application. ( callee of the BPEL process.). Thus it is required increase timeout interval for client application.      

How ?

• Via bps.xml and axis2.xml

Read for more information.
http://nandikajayawardana.blogspot.com/2012/10/how-to-increase-external-invocation.html

 

HumanTask Caching 

When ?

• When you have to deal with large user store.

Why ?

• HumanTasks are tightly coupled with users and user roles/groups. Because of this, BPS does lot of user store lookups for HumanTask operations. These user store calls can take considerable amount of time, if user store is large or located remotely. This causes to degrade performance of the entire HumanTask engine. Caching user and role lookup data at BPS side will reduce those remote user store calls and improve overall HumanTask engine's performance.  

How ?

• Enable HumanTask caching in humantask.xml
• eg: 

    <cacheconfiguration>
        <enablecaching>true</enablecaching>
    </cacheconfiguration>

 

Number of HumanTask Scheduler threads.

When ?

• When you are not using humantask deadline/escalation.

Why ?

• HumanTask deadline and escalation are scheduled tasks, which are executed by HumanTask scheduler. By default 50 threads are allocated for HumanTask scheduler. If you are not using deadline/escalations, you can configure this value to lower value such as 5. This will utilize idle threads in BPS server.
• Note that, you can't set this to 0, because humantask engine has several internal scheduled tasks to run.

How ?

• Configure this value in humantask.xml,
• eg:

    <schedulerconfig>
        <maxthreadpoolsize>5</maxthreadpoolsize>
    </schedulerconfig>