Tibco-最大流量限制属性 [英] Tibco - Max flow limit property

问题描述

我有一个启用了最大流量限制的进程.将该值设置为10.这是一个Asyn进程，用于每天获取数千条消息.我们注意到，在高峰时间，随着EMS服务器中队列中消息的增加，tibco流程的性能下降. Tibco的速度慢与EMS消息的流入增加之间是否存在任何依赖关系.如何计算流程的确切流量限制?我们有任何标准程序吗?

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 ?

推荐答案

FlowLimit配置设置是BusinessWorks设置，因此我假设您有使用来自EMS队列的消息的BusinessWorks引擎.

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.

存在流控制的概念是为了确保BusinessWorks引擎的传入偶数不导致JVM超出其可用内存资源. BusinessWorks通过暂时禁用流程启动器直到内存中的作业数量降至阈值以下来实现流控制.对于基于EMS的流程启动器，这需要关闭MessageConsumer，这将导致EMS停止向该流程传递消息.在大容量消息传递方案中，这将导致EMS服务器上积压消息.此外，这将导致客户端的预取缓存中的任何消息都被重新安排优先级，以便在EMS服务器端进行重新传递.发生这种情况时，您会在EMS统计信息中注意到出站邮件数大于入站邮件数.

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.

最好避免进入流程受控的场景.对于分配给JVM的堆大小和正在使用的消息有效负载大小，当前的FlowLimit参数是否现实?您可以增加JVM堆大小，也可以增加FlowLimit吗?您是否能够运行BusinessWorks应用程序的多个实例，而这些实例在同一队列中分派，以提高可伸缩性?这些方法可以帮助您扩展规模并避免积压消息.

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.

这篇关于Tibco-最大流量限制属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！