内容


专家访谈

Stacy Joines 和 Gary Hunt 谈 WebSphere 性能

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 专家访谈

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

此内容是该系列的一部分:专家访谈

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

引言

在本文中,WebSphere® 性能专家将回答有关 WebSphere V5 与 V6、WebSphere Business Integration Server Foundation V5.1 以及 WebSphere InterChange Server 性能实践方面的问题。涉及的主题包括高性能拓扑、高性能应用程序的设计与实现策略、测试与容量计划,以及总体性能最佳实践。

本文中首先是给 Stacy 的问题,然后是给 Gary 的问题:

Stacy 谈 WebSphere V5 与 V6 的性能

问:WebSphere Application Server 的重要优化参数有哪些?

答: 这是人们经常问的问题,而对此的回答通常都是这样开始的:“在进行任何优化之前,将初始设置作为系统基线。”这样做有两个理由:

  • 初始优化设置非常不错,可以非常好地适应许多应用程序。
  • 如果以后进行优化调整,此基线将告诉您更改之后是有所改善还是有所退化?

假定设定了系统基线,但并不能满足您的要求或期望,那么接下来该怎么办呢?在开始调整 WebSphere Application Server(以下称为 Application Server)中的参数之前,需要花足够的时间找出系统运行状况不好的原因。

Application Server 提供了若干工具,可以用于帮助确定 Java™ Virtual Machine (JVM) 中到底发生了什么。Application Server 中免费提供的 Tivoli® Performance Viewer (TPV) 允许客户对关键资源(如 JVM、Web 容器和 EJB 容器以及远程连接池)进行监视。这款工具使用非常方便,可以用于确定应用程序使用可用资源的方式,还可以提供针对行为不正常的远程资源的信息。例如,如果数据库连接池显示为了获得连接进行了多次尝试,则可能表示远程数据过载,或者需要优化数据库,或者需要向不够大的池中添加更多的连接。与此类似,Application Server 还提供了 Runtime Performance Advisor 功能,可以就系统中的潜在优化问题向管理员提供反馈。

对于更为复杂的优化问题,可以使用监视工具,如 Tivoli 和其他供应商提供的工具。这些工具在运行时对系统进行更多的分析,可以支持深入的瓶颈分析。

WebSphere Application Server Information Center 包含了一个优化参数列表,取决于您的版本,还可能包括一个优化参数“热点列表”,其中描述最常用的经过调整的参数。这是一份不错的参考资料,有助于您了解在该产品内调整内存和资源的基本知识。

其他的不错的参考资料包括 IBM® 红皮书,如 WebSphere Application Server V6 Scalability and Performance Handbook。另外,也可以参考 IBM WebSphere: Deployment and Advanced Configuration,其中包含了一些性能优化建议。

最后,不要忽略应用程序对性能的影响。进行全面性能测试之前,请考虑使用代码分析工具对应用程序进行分析,以发现潜在的效率低下问题和瓶颈问题。IBM Rational® 和其他供应商提供的此类工具可以帮助您观察应用程序的行为,并发现潜在的问题所在。

问: 我们正在考虑选择最合适的平台,以与 WebSphere Application Server 一起部署一款 J2EE 应用程序。我们希望使用最合适的可用硬件模型。不知道有没有什么基准可以用于参考,以了解这些细节?

答: WebSphere Application Server 可以运行于各种平台之上。要为您的部署选择合适的平台,需要考虑很多因素,包括组织内可用的特定于平台的技术技能和长期发展计划。另外,在进行容量计划时,还要考虑所有故障转移或高可用性要求。

您的 IBM 客户团队可以访问 IBM Techline 服务来获得初始容量计划方面的帮助。客户要填写详细的问卷,在其中描述他们的需求(吞吐量、用户访问、特殊的应用程序功能等等)。Techline 团队将提供对硬件的大概估计,以满足这些要求。这是一项非常便利的服务,使得客户不必不断尝试将基准结构映射到其应用程序的特定需求。

当然,所有容量计划的质量都取决于向其提供的信息。例如,如果预计的高峰页面请求相对于问卷中指定的量显得过高或过低,将影响站点硬件需求。另外,容量估算不能替代部署前的性能测试。很多因素(应用程序代码、数据库和 LDAP 服务器等远程资源、网络本身等等)都会影响性能和容量。在部署前进行良好的性测试,并在其后进行生产监视,可以提供测定实际容量的最佳信息。

问: 在 WebSphere Application Server 中,对于使用 HttpSession 复制的站点,对集群成员有哪些实际限制(如集群中的应用服务器数量)?

答: WebSphere Application Server 对集群的大小没有硬性限制。另外,并不存在能够适合所有情况的理想拓扑。不过,下面我给出的这些问题在设计部署拓扑时非常实用。

对于较大的集群,请考虑对 WebSphere Application Server Data Replication Service (DRS) 等服务进行优化,以减少应用服务器实例之间生成的通信流量。如果您的应用程序使用这些服务,随着实例之间共享信息的增加,大型数据流或大量通信流将会使网络流量增加。不过这些服务都可高度优化,应用某些选项(如 Push/Pull)可以降低实例之间的总体数据流。这就允许更多的实例高效地进行信息共享了。

同样,对于共享 HttpSession 持久性数据的实例,HttpSession 服务包含了丰富的优化选项,可用于减少应用程序和持久性存储区间传递的数据量。基于时间进行写操作、仅保存更新的会话信息以及其他的选项都可以降低应用程序和持久性存储之间传递的数据量。另外,如果使用 DRS 的“内存到内存持久化”选项,则可以尝试使用 Push/Pull 和客户机/服务器确定哪个的性能最佳。当然,减少 HttpSession 对象的总体数量也是十分高效的优化技术。

除了数据共享和网络通信方面的考虑之外,还必须考虑集群设计的可管理性。站点是否太大(就节点、应用程序等而言),而让管理员觉得难以满足所有人的需求?是否制订了相关的计划,以安全地提升站点维护和应用新版本,而不会影响其他的应用程序?

问: 我应该在一个节点上放置多少应用服务器实例?

答: 如果希望应用程序正常执行,则不应该将应用服务器实例的 JVM 换出物理内存中。因此,如果计划每个节点启动多个应用服务器,节点的物理内存必须足够大,能够包含所有其承载的应用服务器实例、本机堆、其他应用程序以及操作系统的最大堆大小。

另外,还要考虑 CPU。如果两个 CPU 使用率都很高的应用程序部署到同一台计算机上,可能会导致问题的出现。为了正常的执行,请让重要应用程序获得 CPU。如果必须在多个应用程序间共享资源,请考虑使用 WebSphere Application Server Extended Deployment (XD) 帮助管理资源,以支持优先应用程序的性能需求。

问: 可以从何处获得有关 64 位 WAS 性能的更多信息?

答: 可以参考 WebSphere Application Server 性能团队最近推出的 WebSphere Application Server and x86-64 platforms: 64-bit performance overview

Gary 谈 WebSphere Business Integration Server Foundation V5.1

问: 以前可以很方便地找到带有解释和解决方法的 MQSeries 原因代码的列表,但我现在却找不到,请问可以在哪里找到它们?

答: 可以在以下文档或网站中找到它们:

问: 对于 WebSphere Business Integration Server Foundation,哪种业务流程实现可选方法对性能的影响最大?

答: 由于 WebSphere Business Integration Server Foundation(以下称为 Server Foundation)微流(不可间断的业务流程)的吞吐量要比宏流(长时间运行的业务流程)高得多,使用微流的实现比使用宏流的实现的吞吐能力更好一些。

很明显,会存在某些需要长时间运行的业务流程的情况。对于这种情况,如果可能,将所有的“子流程”均实现为微流。父级宏流应将“子流程”微流作为子流程进行调用。

问: 可以在哪里找到关于优化 WebSphere InterChange Server 的信息?

答: WebSphere Business Integration 性能团队在开发各个 WebSphere InterChange Server 版本时撰写了关于对性能影响最大的优化参数的文档。可以在 Introduction to WebSphere InterChange Server V4.2.2 Performance Tuning 中了解他们所写的内容。

问: WebSphere InterChange Server 最重要的优化参数有哪些?

答: 基于集成解决方案的 WebSphere InterChange Server 最重要的优化参数和解决方案特征包括轮询频率与轮询量、事件顺序、目标应用程序吞吐量、JVM 堆大小和磁盘子系统的速度。下面将一一对其进行描述:

  • 源适配器上的轮询频率与轮询量——轮询频率和轮询量控制事件从源端适配器传入 WebSphere InterChange Server(以下称为 InterChange Server)的服务器部分的速度。大多数适配器的这些缺省参数产生的吞吐量为 2.5 个事件/秒,这个值低于大部分高吞吐量集成接口的吞吐量要求。应该建立接口的吞吐量要求,测定接口的吞吐能力,并据此设置适当的轮询频率和轮询量,以与集成接口的能力和要求相匹配。
  • 事件顺序——事件顺序是 InterChange Server 中的一项功能,用以确保事件按照一定的顺序进行处理。不过,某些情况下事件顺序会给性能造成严重的限制。例如,如果启用时间顺序,而所有事件的 ID 完全一样或丢失了,会导致 InterChange Server 以单线程的方式一次只处理一个事件。如果希望得到最佳的性能,则一定要确认事件顺序的业务需求。如果事件顺序是必需的,请确保将提供事件 ID,以允许 InterChange Server 以适当的方式并行处理事件。
  • 目标应用程序响应时间和线程处理——在 InterChange Server 中,协作会等待来自目标应用程序的响应。因此,集成接口的吞吐能力与目标应用程序的吞吐能力紧密相关。事实上,大部分集成接口的吞吐量都受到目标应用程序的吞吐能力的限制。

    吞吐量受到两方面的影响:响应时间和并行处理能力(线程处理)。通常,集成接口向目标应用程序发出的请求相当复杂,可能需要数秒进行处理。如果目标应用程序处理一个请求的时间刚好为一秒,则其一次只能处理一个事务,那么相关集成接口的吞吐速率将会被限制为 1 个事件/秒。可以通过提高宿主系统的速度或执行代码重构以提高效率,从而改进响应时间。不过,此类活动通常对性能的改善不太大(约 10%)。目标应用程序的线程处理方面的改进可以数倍地提高吞吐量。例如,如果对以前的目标应用程序进行了增强,可以同时处理五个事件,则吞吐量将提高 5 倍,达到 5 个事件/秒。因此,与响应时间的改进相比,提高线程处理能力通常能够更大地提高吞吐量。

  • JVM 堆大小——Java 堆大小配置的第一个原则就是堆的使用率应小于或等于 50%。此配置在垃圾回收器运行的频率和垃圾回收器进行垃圾回收操作的时间长度之间进行了平衡。更具体地说,如果 Java 堆过小,垃圾回收器运行时间不会太长,但其运行会比合理的情况下更为频繁。如果 Java 堆过大,垃圾回收器将不会频繁运行,但运行时占用的时间会较长。

    您应该监视 Java 堆的大小和堆的使用率。应对控制堆大小的最小值和最大值的堆大小参数进行调整,使堆的利用率保持在 50% 左右。这样就能够在垃圾回收周期的频率和长度之间实现最佳的平衡。

  • 磁盘子系统的速度——InterChange Server 广泛使用 WebSphere MQ 和关系数据库。要获得最佳的可能性能,对这些组件进行优化非常重要。WebSphere MQ 和 DB2® 组件都推荐在高速磁盘子系统上运行,以获得最佳的性能。另外,解决方案中任何单线程执行并访问磁盘(直接访问或通过 WebSphere MQ 或数据库)的部分都将在很大程度上受到磁盘子系统的影响。例如,如果 InterChange Server 侦听器配置为单线程执行,而主机磁盘子系统不够快,InterChange Server 的这一部分就很容易成为性能瓶颈。主机磁盘子系统至少应该具有 RAID 功能,以提供所需的磁盘系统速度。

问: 解决 WebSphere InterChange Server 中的性能问题时,建议采用哪种方法?

答: InterChange Server 由一系列在事件上工作的组件组成,这些事件紧靠在组件前的位置排队。通常,通过监视这些队列发现事件“堆积”,可以发现基于 InterChange Server 的解决方案的瓶颈。发生事件堆积的队列后的组件就是瓶颈组件。

下面给出 InterChange Server 组件的列表以及修复发现的瓶颈的通用建议:

  • 源适配器代理——源适配器配置为对传入工作队列进行监视,并将传入的事件传递给服务器。如果源适配器代理为瓶颈,则事件会在该代理监视的工作队列中堆积。例如,对于 JDBC 适配器,此队列将为“事件表”,而对于 MQ 适配器,此队列将为一个 MQ 队列。

    如果发现了此类堆积情况,请对轮询量和轮询频率参数进行调整,以使代理以更高的速度向服务器传递事件。如果代理不能适合轮询频率和轮询量的设置,而又没有事件顺序要求,则请部署一个额外的源适配器。

  • 侦听器(源端)——侦听器监视传输队列,并将传入的事件传递给源端适配器控制器。如果使用 WebSphere MQ 作为源端传输,则传输队列将为 WebSphere MQ 队列。如果发现事件在传输队列中堆积,但在源端适配器控制器前的队列或协作线程池前的队列中并未发生堆积,则请增加侦听器线程的数量。如果侦听器是单线程的,而 InterChange Server 也并未在高速磁盘子系统上运行,则侦听器可能会成为瓶颈。
  • 源适配器控制器——源适配器控制器在内存中具有一个“邮箱”,它对此邮箱进行监视,以拾取事件,并将其传递到相应的协作中。可以使用基于 InterChange Server Web 的监视工具对此“队列”进行监视。如果事件在此队列中堆积,但并没有在协作线程池前面的队列中堆积,则请增加为源适配器控制器配置的线程数量。

    如果事件在传输队列(位于侦听器前)中堆积,则请同时增大侦听器和源适配器控制器的线程池的大小。

  • 协作——每个协作都在内存中具有一个“邮箱”,通过对此邮箱进行监视以拾取事件并处理。可以通过使用 InterChange Server System Manager 查看协作统计数据来监视此队列。如果事件在此队列中堆积,则请增加协作线程和目标应用程序线程的数量。

    注意: 由于协作会等待目标应用程序的响应,因此请勿将协作线程的数量设置得比目标应用程序线程的数量多。如果事件在协作的队列中堆积,而协作所配置的线程数量与目标应用程序的线程数量一样,则解决方案正以其最大的吞吐量运行。请调整轮询频率和轮询量,以限制事件传入端到端解决方案的速度。在这种情况下,请增大目标应用程序的吞吐量以增加解决方案的吞吐量。

问: 监视 JVM 中堆使用率的最佳方法是什么?

答: 监视 Java Virtual Machine (JVM) 中的堆使用率的最佳方法是启用 verbose 垃圾回收 (verbose gc) 输出并分析其结果。在 WebSphere Application Server 最新的版本中,管理员可以通过以下方法启动 verbose gc:即,在管理控制台中选中 verbose gc 复选框并重启 JVM。有关特定于您的版本的详细信息,请参阅 WebSphere Application Server Information Center

IBM JVM 还通过 -Xtgcn 选项支持 verbose 垃圾回收跟踪,其中 n 指定感兴趣的跟踪级别。通过在 WebSphere Application Server 管理控制台的 JVM Process 面板中将这些属性指定为命令行选项,可以启用跟踪参数。请注意,JVM 跟踪经常产生很多输出,通常不推荐将其作为正常的运行时设置,但此跟踪在确定问题时非常有用。

有关 IBM JVM 设置的详细信息,请参阅 IBM JVM Diagnostic Guides。这些有益的指南是每个涉及到 JVM 优化和诊断的人都必须阅读的材料。它们说明了各个可用的参数、讨论了如何查看和解释 verbose gc 输出,并提供了一些关于 JVM 工作原理的颇有帮助的观点。这些指南还描述了垃圾回收跟踪设置。如果想知道固定对象到底为何物以及注意它的原因所在,这些指南是很好的入门材料。

Verbose gc 输出会报告很多关键的垃圾回收统计数据,包括当前的堆大小、可用空间大小(垃圾回收时)、当前引用的对象的大小、垃圾回收循环期间释放的内存、垃圾回收所用的时间以及垃圾回收的频率。利用这些垃圾回收统计数据,通常可以检测各种内存问题,包括内存泄露、大对象问题、垃圾回收频率和堆碎片。

分析 verbose gc 的最佳办法就是从输出生成一个图表。WebSphere Application Server 通过 Tivoli Performance Viewer (TPV) 提供了一些基本的 JVM 构图功能。这些图表独立于 verbose gc 设置进行工作。另外还有很多工具可以根据 verbose gc 输出生成图表。在此,我们将提到 IBM Alphaworks 上可以使用的两个这样的工具,可以使用这些工具根据来自 IBM JVM 的 verbose gc 输出数据生成图表:

参考资料

关于专家访谈

专家访谈是 WSDD 上的一个很有特色的每月专栏。我们可以让您接触到有关 IBM WebSphere 的最好思想以及随时准备回答您问题的产品专家。您来提出问题,我们将公布对最受欢迎的问题的解答。


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=92533
ArticleTitle=专家访谈: Stacy Joines 和 Gary Hunt 谈 WebSphere 性能
publish-date=07062005