我有一个启用最大流量限制的进程。该值设置为 10。它是一个 Asyn 进程，用于每天获取数千条消息。我们注意到，在高峰期，随着 EMS 服务器队列中消息的增加，tibco 进程的性能下降。Tibco 的缓慢与 EMS 消息流入量的增加之间是否存在依赖关系。如何计算流程的确切流量限制？我们有任何标准程序吗？
问问题
2531 次
1 回答
7
配置FlowLimit设置是一个 BusinessWorks 设置，因此我假设您有 BusinessWorks 引擎正在使用来自 EMS 队列的消息。
存在流控制的概念是为了确保 BusinessWorks 引擎的传入事件数不会导致 JVM 超出其可用内存资源。BusinessWorks 通过暂时禁用流程启动器来实现流控制，直到内存中的作业数量低于阈值。在基于 EMS 的流程启动器的情况下，这包含关闭MessageConsumer，这会导致 EMS 停止向流程传递消息。在大量消息传递方案中，这将导致 EMS 服务器上的消息积压。此外，它会导致客户端预取缓存中的任何消息被重新设置优先级，以便在 EMS 服务器端重新传递。发生这种情况时，您会注意到您的出站邮件计数大于您的 EMS 统计中的入站邮件计数。
你最好避免进入流量控制的场景。您当前的FlowLimit参数对于分配给 JVM 的堆大小和正在使用的消息负载大小是否现实？你能增加你的 JVM 堆大小和你的 JVM 堆大小FlowLimit吗？您是否能够运行从同一个队列分派的多个 BusinessWorks 应用程序实例以提高可伸缩性？这些方法可以帮助您扩展和避免消息积压。
于 2015-02-18T13:03:07.213 回答