Configuration 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 bps-datasources.xml file.
- eg: see following section.
<testOnBorrow>true</testOnBorrow>
<validationQuery>SELECT 1</validationQuery>
<validationInterval>30000</validationInterval>
<useDataSourceFactory>false</useDataSourceFactory>
<defaultAutoCommit>true</defaultAutoCommit>
<maxActive>100</maxActive>
<maxIdle>20</maxIdle>
<maxWait>10000</maxWait>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
BPMN Performance Tuning Guide
BPMN runtime frequently accesses the database for persisting and retrieving process instance states. Therefore, performance of BPMN processes depends heavily on the database server. In order to get best performance, it is recommended to have a high speed network connection between BPS instances and the database server.
Execution of each BPMN process instance makes multiple database calls. Therefore, when executing multiple process instances by concurrent threads (i.e. users), multiple database connections are used. Accordingly, database connection pool has to be configured to provide the required number of connections based on the expected maximum concurrent process executions. This can be configured by setting the maxActive parameter of the repository/conf/datasources/activiti-datasource.xml file. To avoid failures that may occur due to the congestion for db connections, maxActive should be equal to the expected number of concurrent process executions. However, lesser number of connections may be sufficient depending on the properties of executed process models (i.e. number/type of tasks) and the behavior of processes (i.e. presence of timer events, reaction time of process participants). If db connection pool size (i.e. maxActive) has to be reduced, it has to be done based on load tests with actual process models and expected process behaviors.
Maximum allowed connections for the database connection pool (i.e. maxActive) should not exceed the maximum allowed connections (i.e. DB sessions) for the database server. In addition, if the database server is shared with BPEL runtime or other server, make sure sufficient number of sessions are available for all shared servers. For example, if BPMN connection pool needs 100 connections and BPEL connection pool needs 50 connections, and if it is expected to have peek BPMN and BPEL loads at the same time, number of database sessions should be at least 150.
BPMN runtime uses a database based ID generator for allocating IDs for all persisted entities. In a highly loaded clustered scenario (i.e. multiple BPS instances with a shared database), database transaction failures may occur if two BPS instances try to allocate IDs at the same time. This can be mitigated by increasing the number of IDs allocated in a single transaction by setting the "idBlockSize" property. Default value of ID block size is 2500. This can be increased by adding the following property to processEngineConfiguration bean in repository/conf/activiti.xml file:
<property name="idBlockSize" value="5000" />
Another option is to configure the StrongUuidGenerator instead of using database based ID generator by adding the following property to processEngineConfiguration bean in repository/conf/activiti.xml file:
<property name="idGenerator">
<bean class="org.activiti.engine.impl.persistence.StrongUuidGenerator" />
</property>