How to improve performance of starting BPD instance with huge managed asset in project?
Jia Tang 3100009WTC Visits (11179)
When you start BPD instance via java script API tw.s
Firstly, you need to confirm if your performance issue is related to managed asset.
In order to analyze this kind of performance problem, we normally collect instrumentation log and WLE trace.
Note: Regarding how to decode and generate report from instrumentation log, please refer to this document "Reading and decoding instrumentation files for WebSphere Lombardi Edition (WLE), and IBM Business Process Manager (BPM) products."
You will find startBPD method in your instrumentation log, which takes a longer time than you expect (in this case, it took 35 seconds).
period 35163ms 'EJB Calls' Meth
Inside of the startBPD method, there will be some “Asset load” methods, each one takes several seconds (depends on how big the managed assets are).
period 5542ms 'Asset load' id=S
(I attached a instrumentation log and report to this blog, so you can get more detail. Click this file to download: Exam
You can get exact timestamp of method BPDE
And if you check your project, you may find some big jar files as managed asset in the process application, or its dependencies (toolkits).
Here are some suggestions to improve the performance.
1. General tuning suggestion
Mainly the number of managed assets influences the time how long it needs to load them into the cache. If the managed asset class loader cache, managed asset cache, or both caches are small, the cache must be refreshed often, which decreases performance.
There is one classloader instance for each snapshot of a process application. So the value of this parameter should be higher than the number of active process application snapshots.
For example, if you have process app A, B, C, and there are 50 active snapshots for A, 30 for B, 40 for C. Then the clas
This parameter defines the number of Java classes that are inside managed files and cached over all process applications and snapshots on one JVM. So the value should be high enough to cache all managed assets that are used on the JVM.
For example, if you have three jar files as managed assets (maybe in different snapshots of different process application or toolkit) A, B, C, and there are 50 .class files in A.jar, 70 in B.jar, 20 in C.jar, then the value must be 50 + 70 + 100 + reserve = 220 + reserve. Generally you use 10–20 % of the total number as a reserve.
For how to make configuration changes, please refer to my other blog "Step-by-step guide on changing IBM BPM configuration files manually."
2. Design suggestion
Firstly you need to control the size of the managed asset, and ensure only necessary assets are included.
Secondly, if there are many process applications depending on many toolkits, you’d better use same version of a toolkit in different process applications unless there is concrete business justification.
Process Application A, B, C, toolkit X, Y, Z
A depends on toolkit X (1.0.1) & toolkit Y (2.3.1)
B depends on toolkit Y (2.0.4) & toolkit Z (2.1.1)
C depends on toolkit X (1.1.4) & toolkit Z (2.1.2)
This kind of design will introduce many unnecessary managed assets.
3. Warm-up workaround
It is regular and known behavior that a java engine needs time to warm up. The first time a BPD is started the classloader and the caches must be filled. For example, for the first time, starting one BPD instance took more than 30 seconds, and from the second time, it took less than 1 second. In that case, you can create a dummy BPD with a script activity (to print some log message etc.) and start it at the first time, then the managed asset of the project will be loaded to cache, so from the next time, all other BPDs could be started without delay caused by managed asset.