Web 服务最佳实践,第 10 部分

Web 服务性能方面需要考虑的问题,第2部分

其他影响性能的需要考虑的问题

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Web 服务最佳实践,第 10 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:Web 服务最佳实践,第 10 部分

敬请期待该系列的后续内容。

在 Web 服务最佳实践专栏的上一期中(查阅参考资料),我解释了像 SOAP 消息解析、XML 和对象之间的编组和解组、以及 WS-Security 特征的处理这些服务相关的问题可能如何影响任何特定的 Web 服务的整体性能。在本期中,我将讨论其他一些可能对有效的 Web 服务交互造成类似阻碍的问题。

其他影响性能的需要考虑的问题

您的解决方案将需要处理三个主要的瓶颈(第 1 部分所涉及的),它们能够潜在地占用您的 Web 服务调用处理时间的 50% 到 75%。可能受到这种程度影响的服务的一个示例就是对具有良好索引的关系数据库进行简单的查询,在这里服务实现做了最小的处理。当执行您的服务的业务逻辑更加复杂并且与后台系统相连接时,由于这三个主要的瓶颈,对于您的服务响应时间的总体影响在某些情况下可以忽略不计。现在,让我们评估其他几个次要的需要考虑的问题,它们同样也会提高您的解决方案的性能。

JavaBean 与 EJB 组件

现在您必须为您的 Web 服务提供者选择是使用 JavaBean 还是使用 EJB 组件。这个决定与您设计其他的 J2EE 应用程序时所做的决定没有什么区别。如果您的解决方案不需要 J2EE 运行环境对于事务、安全性和管理的支持(这些是通过使用 EJB 组件和 EJB 容器来启用的),那么 JavaBean 就足够了,并且可能提供更好的性能。如果您正在使用 EJB 组件,并且将它们作为 SOAP 引擎部署在相同的 JVM 中本地部署它们,请确保部署它们,这样就可以通过引用传递(pass by reference) 来调用它们。通过引用传递,方法的参数没有被复制到每个远程调用的堆栈中,而这个复制过程可能是代价高的。当 SOAP 引擎(EJB 客户端)和 Web 服务提供者(EJB 服务器)安装在同一个应用程序服务器实例中并且使用远程接口时,启用引用传递能够将性能提高 50%。

解析器对于消息的验证

很多解析器能够验证 SOAP 消息的结构来确保它们是结构良好的并且遵守特定的 XML Schema。这使 Web 服务的实现代码能够朝着业务逻辑的方向得到最优化,而且只能通过有效的请求才能被调用。不幸的是,在大部分的时间里,由于它对于性能方面的影响,解析器的消息验证函数不能被启用。

如果您正在使用 Apache Xerces 解析器,您能够同时启用对 DOM 和 SAX 的解析。然而,记住启动验证将不会使 Xerces 报告任何显示出来的错误。您将不得不实现 org.xml.sax.ErrorHandler 接口,并且使用 setErrorHandler 方法同解析器一起注册您的实现。

如果性能具有很高的优先级,推荐您不通过解析器启用消息验证,而是作为好的标准编程实践,用处理参数的代码来验证它们的值。

使用高速缓存最优化性能

对于支持 HTTP 的 Web 服务(XML Web 服务和 Internet Web 服务),实际上您可以高速缓存它们的处理结果以用于将来的请求。运行时间可以节省 Web 服务的响应,并且自动地为普遍的请求提供它们,显著地加速处理器密集型的服务请求。当然,实际上高速缓存仅适用于只读型服务,这些服务执行对于数据库的查询或者提供对相对静态内容的访问(例如,产品目录、销售信息、历史财务数据以及定价数据)。SOAP 消息的不同部分能够被用来惟一地验证对于高速缓存的请求。

高速缓存的能力是根据下列因素定义高速缓存策略和构造 cache-id 来提供的:

  • SOAP 动作
  • SOAP 封套
  • Port 组件
  • SOAP 操作
  • SOAP 操作参数。

策略包括规则和到期间隔来确保存储信息的有效性。不需要对 SOAP Envelope 解析的组件将提供最佳的性能收益。例如,在 SOAP 规范中定义了请求中的 SOAPAction HTTP 信息头,HTTP 代理服务器使用它来向特定的 HTTP 服务器分发请求。可以在高速缓冲存储器策略中使用这个信息头来构建 ID,而不必解析 SOAP 消息。然后,可以使用 cache-id 从高速缓冲存储器中检索服务响应信息来使性能最优化。

从 UDDI 注册中心检索服务绑定

UDDI 注册中心被用来为动态发现发布 Web 服务信息。服务访问点的延迟绑定(late binding)是目前 UDDI 注册中心的常见用途之一。在客户端的服务调用期间,查询 UDDI 注册中心来获得服务的访问点(URL)。通常使用这种方法启用执行故障排除支持的备份服务器(backup server)的使用来改善服务的可用性。同样地,为了在维护的同时又不干扰对现有的服务请求的处理,它向服务提供者提供了从一个系统迁移到另一个系统的能力。然而,UDDI 查询可能向请求中添加很长的路径,如果对每个请求都这样做,那么就可能降低客户端的性能。一种方法就是前置本地的服务代理,它是由服务提供者的 WSDL 和一个通用代理一起创建的。这个通用的代理查询 UDDI 注册中心,并且将访问点保存在高速缓冲存储器里一段特定的时间内。客户端应用程序调用通用代理(由它调用服务代理)来调用服务提供者。

图 1 ―― 最优化 UDDI 查询
最优化 UDDI 查询
最优化 UDDI 查询

如果由于状态代码为 200 的非 HTTP 而导致调用服务代理产生故障,那么通用代理会重新查询 UDDI 注册中心,看是否有可用的替代处理方法用于对服务代理的后续调用。这可以使客户端应用程序代码更简单、将 UDDI 注册中心的查询减少到最少、并且动态地将客户端绑定到服务以便确保最佳性能具有更高的可用性。

Web 解决方案的性能调整

除了已经讨论过的瓶颈和需要考虑的问题之外,大部分其他的运行性能问题和 Web 服务解决方案的这样的问题的决定与其他的应用程序之间没有什么区别。这是因为 Web 服务提供业务函数的通用接口。如何描述接口(WSDL)、如何发布和发现接口(UDDI 或者 WSIL)以及如何调用它(SOAP)的定义是 Web 服务所特有的,但是执行业务逻辑的服务的实际实现通常是基于现有的基础架构(例如,J2EE、.NET、CICS、IMS)。

当在 J2EE 环境中使用 JavaBean、Enterprise JavaBean、或 Message Driven Bean 来实现 Web 服务时,需要以相同的方式调整应用程序服务器,而不管这些组件是否被作为 Web 服务来部署。例如,每个 WebSphere Application Server 进程都有几个影响应用程序(请考虑 Web 服务)性能的参数。您可以调整应用程序、Web 容器、EJB 容器以及应用程序服务器。

看一看下面所列出的,被视为基于 WebSphere 的解决方案中的调整参数热点列表(Tuning Parameter Hot List),您能够了解对于大多数其他的 Web 解决方案所需要评估的问题:

  • 硬件和能力设置
  • Java 虚拟机的堆的大小
  • 应用程序装配性能清单
  • 数据源连接池和事先声明的高速缓存
  • Solaris 操作系统 TCP_TIME_WAIT_INTERVAL
  • 值传递/引用传递
  • IBM HTTP Server 访问日志
  • HTTP 持续(keep alive)连接
  • 事务日志
  • 对象请求代理片段大小(Object Request Broker FragmentSize)。

一旦您的解决方案开始实施,您将需要对上面的大部分进行评估,您可以捕获测量的结果,以便使您能够理解您的解决方案的行为中的改变――作为应用的改变的结果。您可以在 WebSphere 信息中心中查看这些主题的详细资料(请参见参考资料)。

总结

成功地最优化 Web 服务的性能,部分是经验,部分是您用于度量标准、分析信息以及合理调整的方法的系统训练。首先,正如前面所描述的,您必须在您的体系结构和设计阶段作出合适的决定。然而,一旦您拥有了可操作的解决方案,您就必需从模拟负载中获取度量标准、作出调整、再次度量以理解它们的影响,从而精确地调整您的解决方案,这是一个反反复复的过程。

IBM 已经在最优化 SOAP 的解析方面取得了重大的进步。与 Apache 和 WebSphere Application Server V5.0 所交付的 Web 服务实现的 Tech Preview 相比,WebSphere Application Server V5.02 通过一组原始工作负载提供了两到三倍的性能改善。同样地,WebSphere 对具有文档/文字消息传递类型的 JSR 109 和 101 的支持也包括序列化器和反序列化器例程,它们是基于 XML Schema 数据类型的,因而可以通过 SOAP 编码来提供增强的性能。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=55145
ArticleTitle=Web 服务最佳实践,第 10 部分: Web 服务性能方面需要考虑的问题,第2部分
publish-date=03012004