Spark Toolkit and Process DB

Vignesh Dhakshinamoorthy

November 18, 2016 at 12:22 pm #3124

We have been having performance problems with our process center, and we are hoping to see if Spark has anything to do with it.

I have various questions around this topic, that I would like to share:

How much records would SPARK toolkit create on the LSW_PO_VERSIONS table for every snapshot?

After we reviewed our LSW_PO_VERSIONS table, it is found that the PO TYPE with highest record count (200,000 records) is: LSW_RESOURCE_BUNDLE_KEY. That is 20% of our overall size of 1M records.

More detailed investigation reveals that our toolkit has a resource bundle called “SPARK” that contains 9215 keys. Does this count affect the performance in any way? If I take 20 of my snapshots, with SPARK in it, will it generate 200k records?

If customers need support for just English, should we be using a slimmed down version of that bundle?

 

SPARK Support

December 16, 2016 at 9:54 am #3312

Hi Vignesh,

If the underlying dependency of your Snapshot is SPARK version 4.4.5-EE for instance, and you import multiple versions of your application, the toolkit will not be duplicated.  The same can be said of IBM toolkit dependencies.  In fact, SPARK should at some point support the same number of languages as Responsive Coaches for example.  Taking snapshots will be working as designed for BPM.

As for managing the performance of a BPM server with various versions of toolkits, you may wish to review IBM’s documentation on Managing and Using Toolkits.

Regards,

Stephen P.

Vignesh Dhakshinamoorthy

February 20, 2017 at 12:28 pm #3780

Hi Stephen, thanks for your answer. Yes you are right, I did more reading on the topic about the underlying implementation. As long as everyone is using the same version, it is better.

The IBM Coaches toolkit also has around 5000 keys, due to the nature of language support that is required to be offered.

SPARK Support

February 22, 2017 at 9:41 am #3795

Hi Vignesh,

Thank you for the additional feedback.

Regards,

Stephen P.