3

I have a process with max flow limit enabled. The value being set at 10. Its a Asyn process and used to get thousands of messages daily. We noticed that at peak time, with the increase in messages in queue in EMS server, the performance of the tibco process decline. Is there is any dependency between slowness in Tibco with increased inflow of EMS messages. How to calculate the exact flow limit for a process ? do we have any standard procedure ?

GKN
  • 107
  • 1
  • 2
  • 8

1 Answers1

7

The FlowLimit configuration setting is a BusinessWorks setting, so I am assuming that you have BusinessWorks engines that are consuming messages from an EMS queue.

The concept of flow control exists in order to ensure that the number of incoming evens to a BusinessWorks engine does not cause the JVM to exceed its available memory resources. BusinessWorks implements the flow control by temporarily disabling the process starter until the number of jobs in memory falls below a threshold. In the case of EMS-based process starters this entains closing the MessageConsumer, which causes EMS to stop delivering messages to the process. In high-volume messaging scenarios this will cause a backlog of messages on the EMS server. Additionally it will cause any message in the prefetch cache on the client-side to be re-prioritzed for re-delivery on the EMS server side. When this happens you will notice that your outbound message count is greater than you inbound message count in your EMS statistics.

You are best off avoiding getting into flow-controlled scenarios. Is your current FlowLimit parameter realistic for the heap size you are allotting your JVM and the message payload sizes you are working with? Can you increase your JVM heap size and also your FlowLimit? Are you able to run multiple instances of the BusinessWorks application dispatching off the same queue in order to increase scalability? The approaches may help you scale and avoid message backlogs.

nochum
  • 755
  • 4
  • 10
  • In Normal case, The tibco processes 50-60K messages per hour.. With the increased inflow, the number of messages processed falls below 50K and i assume it is because of stopping of message consumer by flow limit process and re-priority and re-delivery of messages at EMS Client server.. Is my understanding correct? Any better ways to avoid it.. Also we need flow limit, else the number of instances will increase and gradually take the entire resources in the server.. – GKN Feb 23 '15 at 16:41
  • I personally feel the flow limit and JVM are good for normal payload but with 5-10K extra messages per hour, it is getting a hit.. Statistic wise, i can show the degradation in performance but Need to prove technically to add additional resources to the process.. Can suggest me any idea? – GKN Feb 23 '15 at 16:41
  • How to find the threshold limit for the flow control present in the BW engine? – GKN Feb 23 '15 at 16:48
  • 2. Assuming you have enough available memory, increasing your flow-control value should not have a detrimental affect on your regular "steady-state" volume. It just means that you have more capacity to handle peak volumes, which appears may be helpful. – nochum Feb 24 '15 at 18:07
  • 3. The maximum value for flow-control limits is based on the size of your message payloads (and intermediate messages/objects being passed during message procvessing), and the number of concurrent processes you have running. Keep in mind that multiple process starters in your engine are all using the same shared JVM heap. Typically the best approach is an empirical one where you run tests in a non-production environment. This will help you understand how memory is used by this specific application. – nochum Feb 24 '15 at 18:08
  • For very small messages having a flow-control value of several hundred or even a few thousand may be okay. But your mileage will vary based on what you have in the BW engine. – nochum Feb 24 '15 at 18:08
  • The Size of the messages will vary and it be in 10KB - 25KBs.. The BW Engine is simple but has a java utility which seems quite heavy and does takes lot of memory – GKN Feb 24 '15 at 19:54
  • Here's another thing to consider. It is extremely important to ensure that anything done in java code completes very quickly. Performing external calls in Java code is a bad thing (I'm not saying you do, I'm just suggesting not to do it). The reason for this is that unlike some of the other activities (such as the SOAP Request/Response, HTTP Request/Response, JMS Request Response, etc.), the Java activities execute in the engine thread rather than private threads. Therefore if you are using the default 8 worker threads per engine you can have situations where all 8 threads are in java code – nochum Feb 25 '15 at 02:29
  • I would suggest looking at Hawk methods such as `GetActivities` for the various processes in the engine. This can help you identify where your bottlenecks are and point you in the right direction. – nochum Feb 25 '15 at 02:32
  • How to identify the number of threads for the BW Engine? My flow limit is 20.. Suppose my BW Engine thread is less than 20, then it means my job Java part has to wait for BW free threads.. Am i right? – GKN Feb 25 '15 at 23:43
  • 3
    It can be changed using the `Engine.ThreadCount` in the tra file, or on the "Server Settings" tab in Administrator. I would caution you though that, ***more threads is not always better***. At some point you introduce resource contention, excessive context-switching and thrashing as the CPU has to give time slice to various threads. The default value for engine threads is 8, and that's usually a good number. Given BW's multi-tasking capabilities you don't need or want the flow limit to equal the number of threads. In actuality one has nothing to do with the other. – nochum Feb 26 '15 at 02:15
  • Flow limit simply limits memory. It has nothing to do with concurrency. The goal is to ensure that you don't take in too many events that would cause your engine to incur an OutOfMemoryException. You should see more stable and better performance by increasing the flowlimit rather than increasing threads. – nochum Feb 26 '15 at 02:19