I have had several instances lately where clients either from IBM Business Process Manager (BPM) 8.5.* or from IBM Business Process Manager 8.0.* said that it takes a very long time to complete migrating inflight data's process. For example, in one case, it took about 4 hours to finish instance migration (the number of migrations was just about 60,000). It is too slow, right?

Let me first give you some background knowledge for why you would do instance migration.

Often, clients need to make changes to their applications and deploy new application snapshots to IBM Business Process Manager process server. Then they need installing snapshots on a process server, and they need to consider how to handle the business process definition instances that are running on the server. In the other words, when you install a new snapshot, you must decide how to handle the data from the previous snapshot and the instances that are still running from that previous snapshot because the instance runs until the process completes or fails.

The IBM Business Process Manager product documentation offers two ways to migrate process instances:

• While the snapshot is being installed, select Migrate.
• Use the Migrate Inflight Data option after a snapshot is installed.

 

 

If you use BPM Process Admin Console to migrate inflight Data to a new snapshot, there are a lot of factors affecting performance. Here we list some for your reference:

• The number of instances in the process, the number of tasks in those instances, and the size of the execution context.
  The number of tasks associated with an instance and the size of the associated application data affects the migration time.


• The performance of the database.
  Because instance migration is a single-threaded process, database performance will be a constraint on the processing time of instance migration, because of the number of selects, inserts, and deletes performed.


• Process Admin Console will firstly check all snapshots before migrate instances and that takes additional migration time.
  But the wsadmin command (BPMMigrateInstances) will save this snapshot checking time and it will migrate inflight data directly from BPM database.


• And sometimes when you use Process Admin Console to migrate numerous inflight process instances, the web browser might crash or hang because of memory issues.

 

 

Before performing a migration, please first try testing how long the migration takes with 100 instances in the test environment. From that result, estimate the time that the whole migration requires. Then you can conclude if you need to perform tuning for migrating currently running instances to the new version of the selected snapshot. If you indeed need to improve inflight data migration time or just keep the migration running until it completes, please refer to the performance tuning suggestions below for migrating a large number of inflight process instances to adjust the migration configuration options and retest until you get the performance that you need. In the production environment, use what you have learned in the test environment and what you have learned from previous migrations to set the migration configuration options for the production environment.

 

 

Performance tuning suggestions:

 

1. When you use the Process Admin Console to migrate a large number of inflight process instances, the web browser might crash or hang because of memory issues. The server returns very large blocks of instance data to the client browser. However, a configurable property migrate-instances-count has been introduced in APAR JR55159 to let you to specify the number of instances that are migrated during a single migration using the Process Admin Console.
   
   The default value is 1000.
   
   This migrate-instances-count setting can be enabled in the 100Custom.xml file, it applies to both the Process Admin Console and the BPMMigrateInstances command. After each migration, you should check Process Inspector to determine whether there are any remaining instances that are still pending for migration and then perform another migration for the remaining instances.
   
   Note: This new setting is available since IBM BPM 8.5.7 CF 2016.06.


2. Another way to improve performance is to delete system task instances, such as cleanup tasks, that have completed and are no longer needed. Otherwise, the migration program will waste time migrating all those instances and both current and closed tasks on an instance. For information about the command that you can run to delete completed tasks, see BPMTasksCleanup wsadmin command.


3. You can tune <thread-pool-size>, <migrate-tasks> and <defer-ec> to determine which tasks to migrate, set the number of threads in the pool, and whether to defer updating the execution context of the tasks.
   But pay attention to database performance if you increase <thread-pool-size>. So you will need your DBA to monitor database performance. Sometime database performance will be a constraint on the processing time of instance migration.


4. Generally we suggest that you use the BPMMigrateInstances command introduced in APAR JR49332 when migrating large volumes of instances instead of using the Process Admin Console, because it will save the snapshot checking time and migrate inflight data directly from BPM database.

 

 

Where to check the migration settings in your environment

For checking the migration options configuration, you can check the TeamWorksConfiguration.running.xml file in every cluster member to ensure the changes take effect after server startup. The file shows the actual values from all of the IBM BPM configuration files with which the server is actually running.

TeamWorksConfiguration.running.xml Location:

        CUSTOM_NODE_PROFILE\config\cells\cell_name\nodes\node_name\servers\server_name\server_type\

 

I hope the tuning suggestions in this blog can give you some help in actual inflight instance data migration.

 

Tags:  inflight migration instance data process business manager snapshot bpm business_process migrate