我有一个启用了最大流量限制的进程。该值设置为10。这是一个Asyn进程，每天用于获取数千条消息。我们注意到，在高峰时间，随着EMS服务器中队列中消息的增加，tibco流程的性能下降。 Tibco的速度慢与EMS消息的流入增加之间是否存在任何依赖性。如何计算流程的确切流量限制？我们有任何标准程序吗？
最佳答案
FlowLimit配置设置是BusinessWorks设置，因此我假设您有使用来自EMS队列的消息的BusinessWorks引擎。
存在流控制的概念是为了确保传入BusinessWorks引擎的偶数不导致JVM超出其可用内存资源。 BusinessWorks通过临时禁用流程启动器直到内存中的作业数降至阈值以下来实现流控制。对于基于EMS的流程启动器，这需要关闭MessageConsumer，这会导致EMS停止向该流程传递消息。在大容量消息传递方案中，这将导致EMS服务器上积压消息。此外，这将导致客户端的预取缓存中的任何消息都被重新安排优先级，以便在EMS服务器端重新发送。发生这种情况时，您将在EMS统计信息中注意到出站邮件数大于入站邮件数。
最好避免进入流程受控的场景。对于分配给JVM的堆大小和正在使用的消息有效负载大小，当前FlowLimit参数是否现实？您可以增加JVM堆大小，也可以增加FlowLimit吗？您是否可以运行BusinessWorks应用程序的多个实例，而这些实例可以在同一队列中分派(dispatch)，以提高可伸缩性？这些方法可以帮助您扩展规模并避免消息积压。
关于tibco - Tibco-最大流量限制属性，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/28544050/