阅读有关消息流节点的概念主题。
设计消息流时,内置节点的灵活性和丰富性通常表示存在多种方法可完成处理并由此获得所需的最终结果。但是,您还可以发现这些不同的解决方案所传递的性能不同的,如果这是重要的注意事项,您必须在设计时不光要考虑功能还要考虑性能。
有两种方法可以让您的应用程序了解性能:
有几个方面的因素影响消息流响应时间。但是,当您创建和修改您的消息流设计以得到满足您特定的商务需求的最佳的结果时,还必须考虑到最终的消息流的复杂程度。最高效的消息流不一定是最容易理解和维护的消息流;可对可用解决方案进行尝试以找到最符合您需求的解决方案。
会影响消息流响应时间的几种因素包括:
在消息流中使用尽可能少的节点;您在消息流中包含的每个节点都会增加代理中的开销。在单个流内节点的个数有上限。该限制受系统资源管理,特别是堆栈大小方面。
有关堆栈大小的更多信息,请参阅开发消息流的系统注意事项。
例如,您可能有一消息流,它处理八种不同的消息(发票、派送注意事项,等等)。您可以包含 Filter 节点以识别消息的每种类型,并根据它的类型来路由它。您可通过在最前面的 Filter 节点中测试最常用的消息类型来优化此技术的性能。但是,第八种消息类型必须总是经过八个 Filter 节点。
如果您可以分组消息类型(例如,如果消息类型为数字,且您能测试所有类型是大于四还是不大于四),则可以减少所需的 Filter 节点数。第一个 Filter 节点测试是否大于四,并将消息传递到两个进一步的 Filter 节点(连接到 true 和 false 终端),这两个节点分别测试是否小于二和小于六。然后,另外四个 Filter 节点可以测试一或二,三或四,等等。尽管需要的 Filter 节点的实际数字是相同的,但每条消息经过的节点数减少了。
您可能会发现使用带一组 Label 节点的 RouteToLabel 节点提供了代替 Filter 节点序列的更好方法。每条消息经过的节点数更少,吞吐量便会提高。但是,您也必须考虑到使用 RouteToLabel 节点就表示要使用 Compute 节点:该节点的开销可能超过了它所带来的优点。 如果您处理有限数量的消息类型,较少的 Filter 节点数效率更高。
航空公司订票样本说明了您如何在 XML_PassengerQuery 消息流中不使用多个 Filter 节点而使用 RouteToLabel 和 Label 节点。消息路由样本说明了在消息流中将数据库表中的路由信息存储在内存高速缓存中。
如果您从前发行版导入了消息流,则根据 V5.0 中可用的 ESQL 检查您的 ESQL 语句,以查看是否可使用新的函数或语句来提高其效率。
有关消息流性能的 developerWorks 文章中提供了更多有关提高消息流性能的信息。