关于此任务
设计消息流时，内建节点的灵活性和功能通常表示存在多种方法可完成处理并获得所需的结果。 您会发现，不同的解决方案可提供不同级别的性能，如果性能是您的重要考量因素，那么在设计消息流时应将性能考虑在内。
您的应用程序可通过如下三种方法之一来感知性能：
- 响应时间表明消息流处理消息的速度有多快。 响应时间在很大程度上受到您如何设计消息流的影响。 这在本主题中有进一步的讨论。
- 吞吐量则表明在指定时间内消息流能处理多少条特定大小的消息。 吞吐量主要受配置和系统资源因素影响，在 优化消息流吞吐量中与其他域配置信息一起讨论。
Web 用户界面支持您查看消息流统计信息和审计数据，包括消息流吞吐量和 CPU 以及流中事务的耗用时间。 请参阅 查看消息流统计信息和记帐数据 ，以获取有关如何访问统计数据的更多信息。
消息流响应时间受多个因素的影响。 但是，当您创建和修改您的消息流设计以得到满足您特定的业务需求的最佳的结果时，还应考虑到最终的消息流的复杂程度。 最高效的消息流不一定是最容易理解和维护的消息流；可对可用解决方案进行尝试以找到最符合您需求的解决方案。
会影响消息流响应时间的几种因素包括：
- 您在消息流中包含的节点个数
- 每个节点都会增加集成节点中的必需处理工作量，因此，请仔细斟酌消息流的内容（包括子流的使用）。
请尽可能减少消息流中使用的节点数目；消息流中包含的每个节点都会增加集成节点中的必需处理工作量。 单个流中的节点数量存在上限，单个消息流内节点的个数有上限，该限制受系统资源管理，特别是堆栈大小方面。 有关堆栈大小的更多信息，请参阅 用于消息流开发的系统资源。
- 消息流如何路由和处理消息
在某些情况下，您会发现，系统中可用的内建节点以及可能有的其他节点提供了不止一种方法来实现同一功能。 选择最简单的配置。 当消息流需要处理多种类型的记录时，您可以通过开发一个消息流结构来创建一个易于扩展的框架，在该结构中，可以解析消息以确定类型，然后RouteToLabel节点和标签每种类型的节点。 如果期望的 Label 节点数量较多，请考虑在一个消息流中实施消息解析和 Label 选择，并在另一个消息流中处理每一种标签类型。 这两个流之间应通过队列连接。
- 如果您的消息流包含循环
- 避免重复节点的循环，这些循环效率将会是非常低的，且会引发性能和堆栈问题。 您可能会发现具有多个 PROPAGATE 语句的 Compute 节点避免了在一系列节点之间循环的需要。
- ESQL 的效率
- 检查您为消息流节点创建的所有 ESQL 代码。 当您开发和测试节点时，可能保留了您完成最终化消息处理时不需要的语句。 您可能还会发现您作为两条语句编写的代码可以合并为一句。 花些时间复查和检查您的 ESQL 代码可以简化程序和提高性能。
- 持久和事务性消息的用法
- 消息流处理期间，持久消息会保存到磁盘。 可以通过在输入和/或输出上均指定非持久性消息来避免这种情况。 如果您的消息流仅处理非持久消息，检查节点的配置和消息流自身；如果您的消息是非持久的，事务性支持可能是不必要的。 有些节点的缺省配置强制事务性；如果您更新这些属性并重新部署消息流，可能会改善响应时间。
- 消息大小
- 较大的消息需要花较长的时间进行处理。 如果您能将大消息分割成较小的信息单元，您将能够改善消息流处理它们的速度。
- 消息格式
- 虽然 IBM® Integration Bus 支持多种消息格式，并提供可用于从一种格式转换为另一种格式的工具，但此转换会增加集成节点中所需的处理量。 确保您没有执行任何不必要的转换或变换。
您可以在 developerWorks® 文章 (有关消息流性能的developerWorks 文章) 中找到有关提高消息流性能的更多信息。