While developing services and business processes for Enterprise Applications Integration using TIBCO BusinessWorks, performance always remains the top most concern and requires utmost attention from architecture planner as well as developers.
In this post, I will explain 10 tips for performance improvement of TIBCO BW:
- Use of FLOW LIMIT and MAX JOBS parameters are important for tuning performance of TIBCO BW engines. If your TIBCO BusinessWorks Engine can handle peak message rates you should consider using MaxJobs=0 and FlowLimit = 0.FLOW LIMIT parameter is used to control the number of jobs to be created for incoming requests.
- TIBCO BW engine thread count should also be specified in an optimized way to best utilize the resources. 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.
- For better memory utilization and proper garbage collection, parameter EnableMemorySavingMode=true plays a significant role. This TIBCO BusinessWorks 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. For small scale TIBCO envrironments, 256MB heap size is ideal but it can be changed to 512MB or 1GB 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.
- JDBC activities used in TIBCO BW Processes require greater attention from performance point of view as database related operations have higher delays associated. Try to use lesser JDBC activities to the best possible way. Also, 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.
- Sub process calling using Call Process activity should be considered only when it is necessary to arrange the code in a sub process. When data is mapped from parent process to a sub process, 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 number of sessions created as same session gets used for multiple activities for 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 dynamic fashion which results in better performance.