Performance always remains the topmost concern for the Enterprise Applications Integration using TIBCO BusinessWorks. There are some methods to increase the performance of the integrations.
In this post, I will explain some tips for performance improvement of TIBCO BusinessWorks :
FLOW LIMIT and MAX JOBS
FLOW LIMIT and MAX JOBS parameters are important for tuning performance of TIBCO BusinessWorks engines. If the TIBCO BusinessWorks Engine can handle high message rates you should consider using MaxJobs=0 and FlowLimit = 0. FLOW LIMIT parameter is used to limits the number of process instances that can be created. If the number of process instances being created exceeds the value of FlowLimit, the engine suspends the creation of new process instances. However, it continues executing the process instances in memory. The engine resumes creating new process instances when process instances, approximately half the value specified for FlowLimit, have completed.
TIBCO BW engine thread count should also be specified in an optimized way to best utilize the resources. The default value of 8 threads should be used initially but if CPU resources are available and need arises; thread count should be doubled till the time maximum CPU resources get utilized.
parameter Enable EnableMemorySavingMode=true for better memory utilization and proper garbage collection. This property allows the engine to release references to unused process data so that it can be garbage collected by the JVM, thus improving the performance of processes with large amounts of data.
JVM Heap size, garbage collection settings and Server VM vs Client VM settings are also useful while tuning TIBCO BW performance.
HEAP SIZE
For small TIBCO BusinessWorks integrations, 256MB heap size is fine, but it can be changed 1 or 2GB or even more for medium and large-scale TIBCO environments. The total amount of JVM memory needed to operate a TIBCO BusinessWorks Engine should be the memory for each process plus the maximum number of processes that can be in the process pool. If flow control is enabled, the process pool can contain up to the MaxJobs value.
MAX Connection to queue
Set appropriate value for JMS queue connection. If the BW is processing large size messages number of connections should be less. Else increase the connection count to a maximum based on you MAX JOB and FLOW LIMIT settings
JDBC activities
JDBC activities used in TIBCO BW Processes require greater attention from a performance point of view as database related operations have higher delays associated. We need to make sure that JDBC queries used are well optimized and there aren’t high costs associated with these queries. Database table locks should also be taken care of. For JDBC activities, proper timeout parameter should be specified so that unnecessary delays are avoided.
Global variables should be created only when and where needed. Using excessive Global variables results in high latency and additional memory consumption. For shared variables, variable instantiation should be made only at process startup time using OnStartup activity so that same data is used by all processes in the JVM.
Subprocess calling using Call Process activity should be considered only when it is necessary to arrange the code in a subprocess. When data is mapped from a parent process to a subprocess, data copy is created which has an additional cost. Memory limitations should be kept in mind while developing sub-process based TIBCO applications. For heavy asynchronous sub-processes, SPAWN parameter should be used.
In the processes where FTP activities are used, session caching should be used. Session caching can improve performance by reducing the number of sessions created as the same session gets used for multiple activities for the same host.
For SOAP over HTTP or SOAP over JMS, message size should be kept as small as possible as heavy payloads with higher processing requirements affect the performance.
TRANSFORM XML activity has an added overhead associated with it as it invokes XSL parser so it should be avoided. It is suggested to use Mapper activity instead if it can serve the purpose. Mapper works dynamically by loading the definition in a dynamic fashion which results in better performance.
What is MAX JOB, FLOW LIMIT, and THREADS?
Max Jobs:
If the number of process instances in memory has reached the value of Max Jobs, then the process instances created are temporarily held on a disk. These process instances will be moved back into memory when sufficient memory is available.
Flow Limit:
When set, this property limits the number of process instances that can be created. If the number of process instances being created exceeds the value of FlowLimit, the engine suspends the creation of new process instances. However, it continues executing the process instances in memory. The engine resumes creating new process instances when process instances, approximately half the value specified for FlowLimit, have completed.
The number of process instances that can be created in memory is also limited by the memory available on the machine and the memory allocated to the JVM on which the process engine executes.
ThreadCount:
The process instances in memory are executed by the BusinessWorks engine. The number of process instances that can be executed concurrently by the engine is limited by the maximum number of threads, specified by property ThreadCount. Threads execute a finite number of tasks or activities uninterrupted and then yield to the next process instance that is ready.