10 Tips for Tuning TIBCO BW Performance

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:

  1. 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.
    RecommendedAn Overview of Using MAX JOBS, FLOW LIMIT and ACTIVATION LIMIT For Process Configuration
  2. 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.
  3. 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.
  4. 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 environments, 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.

For a deeper look, you can refer to my video on TIBCO BW Design & Development Best Practices where various best practices are explained in detail.

Ajmal Abbasi

Ajmal Hussain Abbasi is Integration Consultant By Profession with 13+ years experience in Integration domain mainly with TIBCO products. He has extensive practical knowledge of TIBCO Business Works, TIBCO Cloud, TIBCO Flogo, TIBCO Mashery, TIBCO Spotfire, EMS and TIBCO ActiveSpaces. He has worked on a number of highly critical integration projects in various sectors by using his skills in TIBCO Flogo, TIBCO API Management (Mashery), TCI, Tibco Designer, TIBCO Business Studio, Adapters, TIBCO EMS, RV, Administrator, TIBCO BE, TIBCO ActiveSpaces etc. Ajmal Abbasi has experience with MuleSoft ESB as well. Ajmal Abbasi is also experienced in the area of API Management particularly with WSO2 API management platforms. Ajmal Abbasi is also experienced in developing solutions using Core Java and J2EE Technologies. You can contact Ajmal Abbasi for Consultancy, Technical Assistance and Technical Discussions.

More Posts - Website - Facebook - LinkedIn - YouTube

6 thoughts on “10 Tips for Tuning TIBCO BW Performance

  1. Anjan

    I have few questions .. can you please provide answers for them ..
    What is the max # of cpu’s a BW engine can use?
    What determines the # of cpu’s a process can use?
    How many cpu’s can an EMS server use?

    Reply
  2. Ashok Satwaliya

    Hi Ajmal,

    Thanks for your post. Its very much helpful.
    I am working as an Tibco Administrator along with configuration & deployment of BW applications.
    I am also working on Tibco EMS/BW configurations for setting up FT/LB instances. I have done it many times, but I did not got a chance to set up a SSL configuration for EMS. Could you please help me on that and share your suggestion on my mail.

    Regards,
    Ashok Satwaliya
    ask.cse07@gmail.com

    Reply
  3. MB

    Hi Ajmal
    You have written shared variable should only be instantiated in OnStartup activity. But is there any other place or case scenario to instantiate shared variable other than onstartup activity. As in tibco doc it is written that it should be shared by all the processes.

    Reply
    1. Divya

      Yes it is shared by all the process.

      But the logic here is to initialize that variable at the very starting with the help of On startup.
      After that the value of the shared variable can be accessed by any of the processes as per the requirement.

      Reply
  4. Sebastián

    Hi Ajmal
    I wonder if there is a correct way to configure the thread pool so that the threads are cut or finished after 30 seconds, currently the threads are taken for indefinite minutes and we can only kill them per system. Thanks a lot.

    Reply

Leave a Reply to Anjan Cancel reply

Your email address will not be published. Required fields are marked *