IBM WebSphere DataPower SOA Appliance是根据特定目的构建的设备，通常充当网关和/或Enterprise Service Bus (ESB)来帮助保护、加快、转换、扩展和路由消息。本文介绍了如何调 WebSphere DataPower以实现理想的性能结果。
本文将遍历完整的性能调优过程，即首先进行概要分析，然后进行实际调优，最后进行性能测试，并提供了先决条件、方法和技巧。
本文的所有信息、步骤和图表都基于WebSphere DataPower Integration Appliance XI50设备，固件3.8.0.1。
概要分析
在开始调优WebSphere DataPower之前，您需要收集一些有关部署的解决方案的运行时统计信息和数据。
部署代码(XSLTs)、配置对象(ex:MQ Object)、入站/出站连接和处理规则，这些内容都应该进行分离并执行概要分析，从而确定对性能影响最大（即使用了最多的设备资源）的部分。
XSLT
XSLT 也许是您发现的最常见的性能影响因素，因为您将在这里编写（有时复杂的）业务转换逻辑，特别是如果您使用的是url-open扩展函数的话。
WebSphere DataPower提供了XSLT概要分析特性，下面的步骤用于对任何调用中执行的所有 XSLT 文件启用概要分析功能。
转到Objects>XML Processing>XML Manager>default（除非使用另外的管理器）
在 Main 选项卡中，选择 Compile Option Policy（或者另外创建）
编辑所选的Compile Option Policy
选择默认的（或创建一个新的）Profile rule
保存新的配置并重新运行客户机应用程序后，可以在以下部分找到概要分析结果：
打开Status>XML Processing>Stylesheet Profiles
图 1. Profiled Stylesheets
可以看到，Count和Time列很清楚地显示了结果，XSLT文件花了更多的时间来执行这两个列，还要注意，Time值合计了在所有执行尝试中消耗的时间（如Count所示）。
服务
可以按照如下步骤对Web Service Proxy或XML Firewall之类的服务对象进行概要分析：
启用统计数据
这一步骤将启用统计数据收集，这对于不同对象的概要分析非常有用。
打开Administration>Device>Statistics Settings
启用它–如果尚未启用的话-然后单击Apply
查看概要分析信息
打开Status>Connection>Transaction Times
图 2. Transaction Times
现在可以看到每一个服务的平均处理时间。
消息流
消息流可以分为4种类型：
消息（Message）：处理来自客户机的请求消息的时间，加上服务器的处理时间，再加上设备处理服务器响应的时间（完整的事务周期）。
请求（Request）：在将请求消息发送给服务器之前由 DataPower对消息进行处理的时间。
服务器（Server）：服务器用于处理接收自 WebSphere DataPower的请求消息的时间。
响应（Response）：在将消息发送回客户机之前，WebSphere DataPower用于处理接收自服务器的消息的时间。
遵循以下步骤来对设备中的消息流执行概要分析：
创建Message Duration Monitor
打开Objects>Monitoring>Message Duration Monitor。
单击Add。
选择measure，这是以上描述的四种类型之一。
完成表单并Apply。
查看统计数据
打开Control Panel > Status。
单击Messages (duration)。
您将找到刚刚创建的Duration Monitor。
图 3. Message Duration Monitor
连接
您可以获得入站、出站和内部TCP连接的快照，还可以观察在特定端口上监听的服务，如图 4 所示。
打开Status>IP-Network>TCP Port Status或TCP Port Summary
图 4. TCP Port Status
请注意，更多的连接意味着更多的内存。还要注意，打开/关闭连接将消耗CPU时间。
后端
除了在 WebSphere DataPower 上运行性能测试外，还可以直接在后端重新运行测试并比较两次测试中的延迟。
这可以说明延迟是由设备引起还是由后端引起，也可以通过使用前面消息流小节中的类型为 “server” 的Mesmessageration监视器实现这一点。
设备使用情况
观察不同场景下的设备指标（CPU、内存和系统使用率）非常有用。在大多数环境下，这通常是通过定期的SNMP轮询实现的。监视系统负载/利用率可以提供比 CPU 使用率更好的设备负载指标。
CPU和内存
打开Control Panel>View Status>System Information（memory和CPU usage）
图 5. 内存使用率
系统使用率
系统使用率使您能够大致了解设备上的负载情况，包括CPU、内存、处理队列中处于等待状态的消息（工作列表）、文件/连接句柄以及总负载指示器。
打开 Status>System>System Usage
图 6. 系统使用率
注意：与CPU使用率相比，系统使用率要更加重要、更加准确，因为CPU使用率展示的是瞬间的高峰使用情况，而系统使用率考虑了持续时间。
调优
对信息进行概要分析后，您可以创建自己的调优计划，下一小节将讨论并描述最重要的调优步骤，这些步骤将对性能产生直接影响。
缓存
缓存是最重要的性能调优选项，考虑一下用于网络通信、检索WSDL文档或编译XSLT文件的时间，可知缓存的重要性。
WebSphere DataPower提供了许多缓存选项，您可以缓存XSLT文件、文档（特别是远程文档）、WSRR WSDL检索、LDAP/TAM响应和其他内容，下面我将介绍缓存上述对象所需的步骤。
XSLTs和文档
XSLs在默认情况下将被缓存。通过在XML Manager中指定该选项，您可以设置将要被缓存的XSL的数量：
打开 Objects>XML Processing>XML Manager>Your XML Manager（或default）
将XSL cache size设置为一个理想的数值。
要缓存文档，打开XML Manager的Document Cache选项卡，并将Document Cache Count设置为一个合适的数字，将Document Cache Size设置为一个合适的正数。
要缓存远程文档，执行以下步骤：
打开Document Cache Policy选项卡
单击Add
输入URL Match expression，该URL可以表示设备内部，也可以表示设备外部（例如WSRR REST Calls）
完成表单的剩余内容
Apply并Save
图 7. 文档缓存策略
WSRR WSDL检索
如果使用的是WSRR WSDL订阅（subscription），那么默认将缓存WSDL Retrieval，确保您已经选择了合适的刷新间隔。
打开Control Panel>Web Service Proxy>Your Proxy
打开WSDL选项卡
展开WSDL subscription
为Refresh Interval输入一个合适的值（注意：如果没有其他任何优选参数的话，可以使用默认值）
图 8. WSDL刷新间隔
AAA缓存
在AAA对象中，身份验证和授权缓存被默认设置为3秒，除非您需要使用一个更低的值（增加缓存时间会导致更薄弱的安全性），从性能角度来看，增加这个值是有好处的。
打开Objects>XML Processing>AAA Policy>Your Policy
在Authenticate选项卡中，增大Cache Lifetime的值，在Authorize选项卡中，增大相同的值。
图 9. TAM Authorization Cache Lifetime
HTTP持久性连接
HTTP持久性连接意味着重用已打开的连接来发送多条消息，而不是针对每条消息打开/关闭连接。这个选项可以减少CPU周期、网络通信和延迟。有关更多信息，请查看参考资料小节中的HTTP Persistent Connections。
作为HTTP/1.1规范的一部分，WebSphere DataPower支持对入站/出站调用使用持久性连接，在与HTTP有关的服务中，比如HTTP前端处理器、Web Service Proxy和XML Firewall，持久性连接被默认启用，下面介绍了如何在Web Service Proxy中控制该选项。
从Control Panel中打开Web Service Proxy>Your Proxy
打开Advanced Proxy选项卡
可以设置Persistent Connections "On" 或 "Off" 并指定持久性超时
图 10. 持久性连接设置
处理规则
处理规则是指包含处理节点（Action节点）的流，这些节点将被应用到传入的消息。
PIPE和NULL上下文
在任何合适的情况下使用PIPE作为两个连续动作节点的Input和Output，这将防止额外的上下文处理并可以将内存保持在一个较低的使用水平。
如果一个动作不需要生成或使用前一个动作的结果（例如，Transform Action只被用于设置上下文变量），那么可以使用NULL作为该动作的Input或Output，这样做是有益的，因为您将不需要花时间去创建和解析上下文，并且动作变得更加易于理解，最终解决方案将会消耗更少的内存。
异步规则
需要限制异步规则的使用，因为您可以想象得到并行处理将增加CPU利用率（上下文切换）并将使用更多的内存，还需注意，这对于异步动作也是一样的。
可重用规则
可重用规则需要从父规则中多次调用，这可能会在动作节点执行中引入冗余，在使用可重用规则时，确保只包含了需要多次调用的动作，其他动作（比如用Transform Action设置变量）可能被移动到父流中，以避免产生冗余。
XSLT代码
从一开始产生的性能代码，下面是一些XSLT性能技巧。
避免使用"//"；使用绝对树路径指定所针对的节点。
不要两次检索相同的信息，如果在同一个文件中多次使用了dp:variable函数或从文档<xsl:value-of select="document(/path)"/>中多次使用了一个值，那么最好将其保存为一个变量并在稍后的引用中使用该变量。
WebSphere MQ Queue Manager
在连接到MQ时，使用“dpmq://”（使用了一个可配置的MQ Queue Manager对象）而不是直接的MQ连接 “mq://”，使用直接的MQ连接将在运行时创建一个队列管理器对象，并将对每个调用打开一个新的MQ连接，相反，如果使用MQ Queue Manager对象，您将具有连接池以及许多其他好的选项。
可以通过如下步骤创建 MQ Manager Object：
- 打开Objects>Network Settings>MQ Queue Manager
- 单击Add，完成表单并单击Apply
随后可以在“dpmq://” urls中使用该对象的名称
图 11. MQ Queue Manager
流线化
WebSphere DataPower 支持多种流线化（streaming），比如执行流线化（在执行XSLT时使用SAX）、连接（attachment）流线化、消息流线化以及上下文流线化（如处理规则小节中使用 PIPE 的情况）。
这些方法提供了许多优点，其中之一便是降低了内存的使用。
有关WebSphere DataPower流线化的更多信息，请访问参考资料小节中的“Optimizing through Streaming”文档。
性能测试
本节将指导您在WebSphere DataPower设备上构建性能测试。
先决条件
将日志级别设置为error，不要使用debug。
禁用任何Probe。
确保设备中没有发生任何其他活动（可能位于其他域中）。
在运行测试之前执行一些 “预（warm up）” 调用，这对于使用缓存的情况是有益的，并且确保调用得到了成功执行。
确保所使用的环境类似于您的客户的环境（特别是网络速度和设备类型）。
如果使用的是XML Threat protection，确保它不会妨碍您的测试（出现可疑的 XML-DOS 攻击）。
测试方法
使用渐进式的并发方法，这种方法从比较少的线程数（比如说10个）开始，然后逐渐增加到30、50、80个线程等等，当达到某个程度时，性能开始出现下降，通过这种方式就可以了解您在哪一个点可以获得最佳性能效果（解决方案的容量）。
如果在高并发性下进行测试，那么使用适当的线程延迟（等待时间），因为如果不这样做的话会加重设备的负担，并进而影响性能。
在测试中使用不同的场景和数据集，如果这些内容匹配真实的生产场景则更好。
尝试长时间重新运行测试（持久性测试），因为诸如内存泄漏等问题只会出现在此类测试中。
当生成巨大的负载时，确保选择了合适的测试工具和操作系统（比如Linux或Windows Server），因为某些测试工具和操作系统无法为设备生成足够的负载。
测试工具
下面列举了一些可用的测试工具：
- IBM Rational Performance Tester for SOA Quality
- JMeter
- SOAP UI
- Apache Bench
提示和技巧
固件更新/技术说明
经常通过IBM支持站点查找有关WebSphere DataPower的最新固件和技术说明，其中包含补丁以及内存泄漏等性能问题的解决方案。
设备处理队列
如果客户机应用程序向设备发送了大量的消息，并且这些消息进行了处理并以异步方式发送给服务器，而且服务器没有进行足够的调优，无法按照WebSphere DataPower处理和发送消息的速度来消费这些消息；这可能会导致类似内存泄漏的情形，因为设备将在内存中对消息进行排队，直到服务器有能力处理它们。
针对这种情况，解决方法就是对服务器进行调优，使它能够在任意给定的时刻接受更多的消息。
结束语
在本文中您了解了如何对WebSphere DataPower进行概要分析、调优并测试性能，如果您使用的是本文介绍的内容以外的特性和对象，您仍然可以使用本文提供的技巧和示例来实现您的调优目标。