Application performance is an important parameter that determines the success or failure of any software application / product. This post highlights few simple techniques to tune application performance of Bonita, which would be helpful to the Bonitasoft community. It also provides guidance on resolving issues that arise, while implementing Bonita solutions. A recent implementation of Bonitasoft 6.3.1 has been quoted as an example, which would allow the Bonitasoft community to gain a better understanding of the problems and issues experienced in a real-time Bonitasoft implementation. In the Bonitasoft example quoted here, the requirement of the business entity (client) was to create cases based on customer records present in a Microsoft Excel file, which was available on a shared directory.
Application Performance Testing
The Bonita application was developed using Bonita version 6.3.1, and as per the requirement of the business entity (client), the new software application allowed them to create cases by exporting records from the Microsoft Excel file. During the functional testing phase, no major issue or concern relating to the application performance was highlighted by the quality assurance teams. However, when the Bonita application was moved to the next level, which is the ‘User Acceptance Testing (UAT)’, the QA team signaled out certain application performance issues, especially while performing load testing. What were the primary causes of these application performance issues? Can the development team fix these issues by tweaking application settings? Let’s find out.
Load Testing Parameters
As per the BPM process, a Custom Bonita Wrapper component extracts (loads) a Microsoft Excel file from a shared directory and creates a unique case for each record on the Bonitasoft engine, utilizing the Bonitasoft REST API. The load testing was performed using four thousand records (4,000) records that existed in the Microsoft Excel file. The Custom Bonita Wrapper component started creating cases on the Bonita engine using the REST API. So, what did the load testing benchmarks indicate?
Load Testing Results Summary
Below is the summary of the load testing exercise:
- A few cases failed at email domain validator connector stage with an error message ‘connector time-out exception’.
- The average time that was recorded per case instantiation was ‘5 seconds‘.
- The average time for each case completion was ‘44 seconds‘.
How to Tune Bonitasoft Application Performance?
After carefully analyzing the load testing results and based on the nature of existing workflow, the development team decided to tune few parameters (listed below) of Bonita, which would improve overall performance of the application.
Journal Connection Pool
Bonitasoft engine is accessed utilizing Bonitasoft Portal, Custom Bonita Wrapper Component, Bonita Scheduler Threads, and Bonita Worker Threads. It was observed that the REST API component was creating cases with very low latency and with a default connection pool size, which is preset at 10. The development team also noticed that the default connection pool size was acting as a performance bottleneck and preventing the application to function at its optimal best. The team decided to increase the default pool size to 50 based on the concurrent usage of various components mentioned above. At this point, you may want to know how to increase the default pool size? Below is the code that would allow you do that.
In the example quoted above, Tomcat server was being used and hence the below changes were made:
<Catalina_Home>/conf/bitronix-resources.properties resource.ds1.maxPoolSize=50
Note: In the example cited, the UAT was conducted in a clustered environment with 2 nodes, hence the pool size was changed in both the nodes.
Bonitasoft Connector Time-out
Another issue that was limiting the application performance was ‘connector time-out’ error, the default value of Bonitasoft connector is set to 5 minutes. The development team was facing issues with the ‘validate email domain connector’, as it was consuming a little more than 5 minutes to validate, 5 customer email domains. The development team decided to increase the timeout limit by 10 minutes, which helped in rectifying the issue. Here’s how you increase the timeout limit. All you need to do is change the timeout property value.
<BONITA_HOME>/server/tenants/<TENANT-ID>/conf/services/cfg-bonita-connector-timedout.xml <bean id="connectorExecutor" class="com.bonitasoft.engine.connector.impl.ConnectorExecutorTimedOut"> <constructor-arg name="queueCapacity" value="10" ></constructor> ....... <constructor-arg name="timeout" value="600" ></constructor> ....... </bean>
Invalid Session Cleanup Job Schedule
Another major issue that was hampering application performance was ‘invalid session cleanup job schedule’. The default value of any session of the Bonita tool is set to 2 hours. The Custom Bonita Wrapper component is responsible for creating Bonita sessions, which by default is equal to the number of records in files / cases created by the REST API. In the example quoted, the Microsoft Excel file consisted of four thousand (4,000) customer records, which means Bonitasoft’s REST component was ending up generating four thousand sessions in less than one hour. So, how to fix this issue? The simple solution was to reduce the session cleanup schedule to 30 minutes, by changing the default value which is set to 2 hours. Additionally, the team restricted Custom Bonita Wrapper component code to be used only for ‘session per batch size’, instead of individual cases. Here’s the code that would help you change the session cleanup schedule.
Add the following session cleanup job property:
<BONITA_HOME>/server/platform/conf/bonita-platform.properties org.bonitasoft.engine.clean.invalid.sessions.cron = 1800
Note: Ensure that you specify the time value in seconds.
Conclusion
The extensive efforts of the development team helped in improving the application performance of the BPM application, which was developed using the widely recognized Bonita tool. By making few minor tweaks to the existing parameters in the BPM tool, developers were able to improve the application performance considerably. The development team successfully reduced the average case creation time to 1 Second and overall process execution time by almost 75%, which is a significant achievement. Additionally, the performance of the application was reported as consistent, even when the volume of data used for load testing was increased from 4,000 to 10,000 records.
Author
 |
Hari Prasad Alla is a Associate Technical Architect at Evoke Technologies. He has strong expertise in requirements analysis, design, implementation and release. He has technically adept in Bonitasoft BPM, Java, Spring MVC, Spring Batch, Spring Integration, Hibernate, Web Services (SOAP, REST), JMS, Jasper reports, Hadoop and NoSQL (MongoDB). |
