IBM BPM performance tuning strategy part IV

In the last blog we discussed on IBM BPM platform (or “TeamWorksConfiguration”) level performance tuning. In this this part, we will focus on “Application Review and Tuning”.

APPLICATION REVIEW AND TUNING

Application Review requires to focus on the below areas.

Turn off auto-tracking in BPDs if it is not required

• Auto tracking capability of IBM BPM allows you to auto-track the variable. This creates multiple events which are being proceed by the Performance Data Warehouse. Please note that this is an additional cost.
• If the tracking points are pre-defined as part of the requirement, it is always better to go with Track Group capability and track the variables at particular tracking points as part of your BPD. Now you can disable the auto tracking for the BPD. As this approach will generate the tracking events only at your specified tracking points, the number of events will be much lesser than the auto-tracking events. This will improve the performance of the system.

Usage of Variables

• Minimize the number of variables used by removing unused variables from the BPD and services
• Avoid large Business Objects
  • As Business Objects are being stored in the database, storing and retrieving requires deserialization and serialization. If the size of the business object is large, it will affect the performance.
  • According to the Red Book, “IBM Business Process Manager V8.0 Performance Tuning and Best Practices”, objects that are 5 MB or larger might be generally considered “large” and require special attention. Objects of 100 MB or larger are “very large” and generally require significant tuning to be processed successfully.
  • So it is recommended to avoid large Business Objects wherever possible.
• Set variables, such as DB result sets/ XML Objects etc, to null when they are no longer needed.

Usage of Server side Javascripts

• Avoid extensive use of server side Javascripts
  • Avoid large JavaScript blocks because JavaScript is interpreted and therefore is slower to process than other compiled mechanisms such as Java code.
  • According to the Red Book, “IBM Business Process Manager V8.0 Performance Tuning and Best Practices”, as a general guideline, limit a JavaScript block to 50 lines. If your implementation exceeds this value, reevaluate the design and refactor the implementation to use smaller JavaScript blocks.
  • The recommendation is to implement the logic in Java and use the Java Integration service which would be much faster than a Javascript block.
• User Management API in the case of LDAP
  • If LDAP is configured as part of user management, all the User Management API functions will require to connect to LDAP for getting information. This will make User Management API calls expensive.
  • Avoid the user management API’s if the required information is available with you within one or more variables.
  • Avoid using User Management API’s within “for loops” wherever possible.

Examine SQL Queries

• Get the AWR report from the database team to identify the expensive queries. Apply proper indexes for application specific tables.
• Examine the query to take care of SQL tuning/optimization. Below are some of checks you can perform for SQL Query. The Below list contains the basic checks to be performed. For more information, you can involve your DB expert to optimize the SQL.
  • Use the column names in select projection instead of “SELECT * FROM …”
  • Select limited data- Avoid unnecessary columns in the SELECT list
  • Remove unnecessary tables in “JOIN” conditions if any.
  • Avoid using “HAVING” clause, instead use where clause with multiple criteria.
  • Avoid using “IN” as part of where clause to avoid the slower output.
  • Instead of “LIKE” search, use full text search for searching textual data.
  • Try to use “UNION ALL” instead of “UNION”.
  • Avoid functions on Right Hand Side of the operator.
• Do not construct the SQL with where clauses like “where empID = tw.local.empID” instead use parameterized queries (where empID =?) wherever possible.
• Set the reference of the result set variable explicitly to null after using it
• If you are using a third party ORM such as Hibernate, then please turn on the trace query flag in that tool to review the SQL queries being generated by that ORM.

Purge data regularly

• One should apply the strategy of purging the instances from time to time.
• Purging improves the performance of the SQL queries which will improve the response time of the My Tasks, Team Performance Dashboard and Process Performance dashboards.

Avoid looping of the flow inside the BPD to achieve polling requirements

• Sometimes the design requires to run the BPD forever to achieve polling for some events continuously.
• In such scenarios, avoid using the looping flow for such BPD’s. Instead use the UCA (Under Cover Agent), to run the BPD at regular intervals.
• Also, turn off the auto-tracking for these BPDs to avoid excessive traffic to the Performance Data Warehouse.

Avoid UCA wherever possible

• As part of the design, try to avoid using UCA if you have other alternatives.
• For example –Assuming that the design requires to poll a file continuously at a specific location and the file is being placed in that location by a third party system (like IBM IIB). If the third party system has the capability to use REST API’s/Web-Service API’s, implement a logic in the third party system to run the BPM service (The service which you want to run when the UCA triggers) directly as soon as the file is available.
• This will improve the performance.

Avoid never ending services to prevent memory leak problems

• Try to avoid never ending services wherever possible
• Wherever possible, make sure that the references to all the large variables are explicitly set to null once the use of the variable is completed.