LSPS Documentation
Perform general performance check:
spy="true" to the LSPS datasource: <subsystem xmlns="urn:jboss:domain:logging:<VERSION>"> add Check your LSPS performance:
CREATE_PROCESS_LOG server setting: recommended setting is MODULE. Further information about the setting, is available in the Deployment guide.
<bean-instance-pools>
<strict-max-pool name="slsb-strict-max-pool" max-pool-size="200" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
<strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
<thread-pools>
<thread-pool name="default">
<max-threads count="10"/>
...
</thread-pool>
</thread-pools>
To compile modules on server restart and prevent their compiling later, you can pre-load the modules: On server start, the server will compile the modules defined by the INITIAL_MODELS_SQL entry in the LSPS_SETTINGS database table.
To enable and define pre-loading of modules when the server is restarted, do the following:
Set SQL logging level of Hibernate to ALL.
For the embedded Wildfly server, add org.hibernate.SQL.level=ALL to <LSPS_WORKSPACE>\.LSPSEmbedded\wildfly<VERSION>\standalone\configuration\logging.properties.
Log in the LSPS database as administrator.
On the default H2 database, the DB URL is //localhost/h2/h2;MVCC=TRUE;LOCK_TIMEOUT=60000, the user name and password are lsps.
--Inserts the INITIAL_MODELS_SQL key with the select that returns the IDs
--of the most recently uploaded my-process and my-contracts modules to LSPS_SETTINGS:
INSERT INTO LSPS_SETTINGS (ID, VALUE)
VALUES ('INITIAL_MODELS_SQL',
'select ID from LSPS_MODULES where
NAME=''my-process'' and
UPLOAD_DATE = (SELECT MAX(UPLOAD_DATE) from LSPS_MODULES where NAME=''my-process'')
union
select ID from LSPS_MODULES where
NAME=''my-contracts'' and
UPLOAD_DATE = (SELECT MAX(UPLOAD_DATE) from LSPS_MODULES where NAME=''my-contracts'')');
If a model instantiation fails with an exception (its interpretation fails), the model instance data is lost. This behavior can cause performance issues due to too large model instances with exceptions being stored. Consider enabling storing of the errors with the marshalled model instances in the database.
To enable the setting, perform the following insert on the LSPS database:
If a model contains many goals with conditions, checking of the conditions might cause performance issues since the conditions are checked whenever any of the goals changes its status or a token is moved. This happens when the interpretation strategy is set to FULL_PARALLEL. However, the default setting is BPMN_FIRST.
You can set the checking to happen only when all transactions finish (all tokens are moved as far as possible).
To do so, issue the following insert statement on the LSPS database:
To improve performance of Shared Record search, define indexes on the Records and their Relationships.
Check the setting of cache regions in the <YOUR_APP>-ejb/src/main/resources/cache-regions.properties file of your LSPS application.
Make sure that the Hibernate statistics feature is deactivated: you can do so on the MBean tab of JConsole, the node com.whitestein.lsps > Statistics -> Attributes > StatisticsEnabled
Search for expression calls with long execution time and identify the cause for the long duration.
Performance issues in processes are typically caused by the following:
foreach: if you are collecting results of iterations in a new collection, consider using functions of the Standard Library, for example, collect(), fold(), exist(), forAll(), etc.Inefficient queries
Typically, queries or functions that call other queries perform poorly.
Assignments in conditions of asynchronous modeling elements, such as, start conditional event, goal precondition, etc.
These might result in an infinite loop: make sure such a situation does not occur
Also consider that the server checks for all changes on such conditions in each transaction: this can mean that the system might perform such extensive checks on every change of a goal status for example. Also consider the BPMN_FIRST server setting.
Multiple processes that communicate concurrently with signals or similar mechanisms
Avoid too frequent communication between different model instances with signals or shared data, when the signals or data is used in conditions or filters of events. Consider moving the processes into one model, so that the communication takes place within one model instance.
Frequent timer checks
Consider setting the TimerInterval to a non-zero value.
Large objects in Signals and in properties of model instances
(Model instance properties can be set, for example, when the model instance is created with the createModelInstance(synchronous*: Boolean, model*: Model, properties:Map<String, Object>) function.)
Search for expression calls with long execution time with Profiler.
Performance issues in obtaining persisted data are typically caused by the following:
Record fields of complex data types
Transform record fields of complex data types to related records; complex field values must be serialized and deserialized frequently.
Unindexed shared Records
Make sure indexes are created for all shared records.
Inefficient getting of related records
Set lazy or eager loading of related records on data relationships. Also consider using data caching for shared records that are used frequently, e.g., code tables but do not change often.
Editing items of records via relationships with List multiplicity
Changes on such records are expensive since they require rebuilding of the entire entity and possibly additional SQL statements for shared Records. Therefore, if a List relationship end cannot contain the same item twice, switch it to Set: When you change the Set value, for example, add a new item to the Set, the system checks and updates only the particular item, while for a relationship of the List type, the entire List entry is rebuild.
sort(list* : List<E>, comparator* : {E, E : Integer}) : List<E> function If possible, use the sortByKey() function with the parameters which returns a list of elements sorted by the keys produced by the keyExtractor. The function takesPerformance issues in obtaining persisted data are typically caused by the following:
Many components in a single form
Divide the form into multiple screens of a screen flows.
if statement; note that the Conditional component is included in the hierarchy on initialization and initialized, while the Expression component is set when the screen context is created as the returned expression. Note that you cannot recalculate the content of the Expression component once it was initialized.