GKN*_*GKN 2 tibco ems tibco-ems
我有一个启用了最大流量限制的流程.该值设置为10.它是一个Asyn进程,用于每天获取数千条消息.我们注意到,在高峰时段,随着EMS服务器队列中消息的增加,tibco进程的性能下降.在Tibo的缓慢与EMS消息的流入增加之间是否存在任何依赖性.如何计算过程的确切流量限制？我们有任何标准程序吗？
该FlowLimit配置设置是BusinessWorks设置,所以我假设你有BusinessWorks引擎是从EMS队列消费消息.
存在流控制的概念是为了确保到BusinessWorks引擎的传入数量不会导致JVM超过其可用内存资源.BusinessWorks通过暂时禁用进程启动器来实现流控制,直到内存中的作业数低于阈值.在基于EMS的流程启动器的情况下MessageConsumer,这会导致关闭,这导致EMS停止向流程传递消息.在高容量消息传递方案中,这将导致EMS服务器上的消息积压.此外,它将导致客户端的预取高速缓存中的任何消息被重新优先化,以便在EMS服务器端重新传递.发生这种情况时,您会注意到您的出站邮件计数大于EMS统计信息中的入站邮件计数.
最好避免进入流控制场景.您当前的FlowLimit参数是否适合您分配JVM的堆大小以及您正在使用的消息有效负载大小？你能增加你的JVM堆大小FlowLimit吗？您是否能够运行多个BusinessWorks应用程序实例从同一队列调度以提高可伸缩性？这些方法可以帮助您扩展和避免消息积压.