您设计的每个消息流必须完整地处理从某个源接收的消息。然而,这可能导致包含大量节点的极其复杂的消息流,并引起性能开销和潜在瓶颈。增加处理消息的消息流数量将为并行处理提供机会,因而会增大吞吐量。
您也可以考虑消息流所执行操作的落实方式,以及处理消息的顺序。
考虑以下用于优化消息流吞吐量的选项:
您可以更新 BAR 文件中已部署的消息流的附加实例属性:代理在单独的线程上启动消息流的附加副本,以提供并行处理。如果您不关心消息的处理顺序,这是处理这种情况的最有效的方法。
如果消息流从 WebSphere MQ 队列接收消息,您可以通过设置 MQInput 队列的排序方式属性在某种程度上影响处理消息的顺序。
对于通过所有受支持协议与代理通信的发布/预订应用程序,代理发布任何给定主题的消息的顺序,与从发布程序接收这些消息的顺序相同(如果适用,将基于消息优先级重新排序)。这通常表示每个订户按特定发布程序发布消息的顺序, 接收从该发布程序经特定代理发布的关于特定主题的消息。
然而,消息可能偶尔不会按顺序传递。例如,如果网络中有一条链路发生故障,而且后续消息由另一条链路路由,就会发生这种情况。
如果需要确保消息接收的顺序,可以在用于每条发布消息的 Publish 命令中使用 SeqNum(序号)或 PubTime(发布时间戳记)参数,以计算发布的顺序。
有关推荐给所有 MQI 和 AMI 用户的技术的更多信息,请参阅 WebSphere MQ Application Programming Guide,和《WebSphere MQ 应用程序消息传递接口》(在 WebSphere MQ SupportPacs Web 页面上作为 SupportPac MA0F 提供);前者针对写入 MQI 的程序,后者针对写入 AMI 的程序。
WebSphere MQ Everyplace 和 SCADA 应用程序使用的消息排序方法不同,WebSphere MQ 移动传输方式和 WebSphere MQ 遥感传输方式中对此分别进行了描述。 代理不会对通过 WebSphere MQ Web Services 传输方式、WebSphere MQ 实时传输方式或 WebSphere MQ 多点广播传输方式接收的消息进行消息排序。
该选项还除去了确定处理消息的顺序的功能。原因是,如果代理中存在多个活动的消息流副本,每个副本都可从同一队列同时处理消息。处理消息所用的时间可能不同,因此访问相同队列的多个消息流会以随机顺序读取来自输入源的消息。消息流所生成消息的顺序可能与原始消息的顺序不一致。
请确保从这些消息流接收消息的应用程序可接受无序消息。
以下两个示例显示在何时您可能要分割消息流:
当完成唯一的处理时,您可能还需要提供另一个输入队列和输入节点以完成 Label 分支连接的任何公共处理。
您还可创建新的消息流复制原始消息流的函数(但仅处理原始消息流直接传递到该消息流的大型消息),该原始消息流已由您进行修改以检查输入消息大小和重定向大型消息。
以下属性控制消息流落实事务的频率: