【发布时间】：2015-04-17 02:51:03
【问题描述】：
我有一个启用最大流量限制的进程。该值设置为 10。它是一个 Asyn 进程，用于每天获取数千条消息。我们注意到，在高峰期，随着 EMS 服务器队列中消息的增加，tibco 进程的性能下降。 Tibco 的缓慢与 EMS 消息流入的增加之间是否存在依赖关系。如何计算流程的确切流量限制？我们有任何标准程序吗？
【问题讨论】：
【发布时间】：2015-04-17 02:51:03
【问题描述】：
FlowLimit 配置设置是一个 BusinessWorks 设置，因此我假设您的 BusinessWorks 引擎正在使用来自 EMS 队列的消息。
存在流控制的概念是为了确保 BusinessWorks 引擎的传入事件数不会导致 JVM 超出其可用内存资源。 BusinessWorks 通过暂时禁用流程启动器来实现流控制，直到内存中的作业数量低于阈值。对于基于 EMS 的流程启动器，这会导致关闭 MessageConsumer，这会导致 EMS 停止向流程传递消息。在大量消息传递方案中，这将导致 EMS 服务器上的消息积压。此外，它会导致客户端预取缓存中的任何消息被重新设置优先级，以便在 EMS 服务器端重新传递。发生这种情况时，您会注意到您的 EMS 统计信息中的出站邮件计数大于入站邮件计数。
你最好避免进入流量控制的场景。您当前的 FlowLimit 参数对于您分配给 JVM 的堆大小和您正在使用的消息有效负载大小是否现实？你能增加你的JVM堆大小和你的FlowLimit吗？您是否能够运行从同一个队列分派的多个 BusinessWorks 应用程序实例以提高可伸缩性？这些方法可以帮助您扩展和避免消息积压。
【讨论】：
-
在正常情况下，tibco 每小时处理 50-60K 消息。随着流入量的增加，处理的消息数量下降到 50K 以下，我认为这是因为流量限制停止消息消费者在 EMS 客户端服务器上处理和重新优先级和重新传递消息。我的理解是否正确？任何更好的方法来避免它..我们还需要流量限制，否则实例的数量会增加并逐渐占用服务器中的全部资源..
-
我个人觉得流量限制和 JVM 对正常负载来说是好的，但是每小时有 5-10K 的额外消息，它受到了打击。从统计上讲，我可以显示性能下降，但需要从技术上证明可以向流程中添加额外的资源。可以给我建议吗？
-
如何找到BW引擎中存在的流量控制的阈值限制？
-
2.假设您有足够的可用内存，增加流量控制值不会对您的常规“稳态”音量产生不利影响。这只是意味着您有更多的能力来处理高峰量，这似乎会有所帮助。
-
可以使用 tra 文件中的
Engine.ThreadCount或在管理员的“服务器设置”选项卡上进行更改。不过，我会提醒您，更多线程并不总是更好。在某些时候，您会引入资源争用、过度的上下文切换和抖动，因为 CPU 必须为各种线程分配时间片。引擎线程的默认值为 8，这通常是一个不错的数字。鉴于 BW 的多任务处理能力，您不需要或不希望流量限制等于线程数。实际上，一个与另一个无关。