内容


解决 WebSphere 应用程序中的性能降低问题

Comments

引言

WebSphere Commerce 是一种优秀的电子商务产品,它在全世界范围内越来越受欢迎。WebSphere Commerce 是一个复杂的 Web 应用程序,它运行于 WebSphere Application Server 之中。作为 WebSphere Commerce 开发人员和 SVT 测试人员,对性能问题进行故障排除是最重要的任务之一。本文重点关注 WebSphere 应用程序吞吐量降低问题的分析,并提供了一些经过我们实际工作经验证实有效的、高效的指导原则。本文还描述了一种用于诊断在 SVT 中发现的 WebSphere 吞吐量降低问题的通用方法。本文还提供了关于如何解决这些问题以提高性能的一些建议。本文包含三个主要的部分:

  • 如何在 SVT 中识别吞吐量降低问题:这个部分介绍了在 SVT 中发现的吞吐量降低问题的主要指标。
  • 如何分析并解决吞吐量降低问题:这个部分介绍了如何处理吞吐量降低问题的通用方法,说明了分析吞吐量降低问题的详细工作流程,并提供了可能的解决方案。
  • 吞吐量降低问题的分析和解决方案示例:这个部分介绍了来自我们的实际工作的一个吞吐量降低问题的示例,以展示这种方法。

吞吐量问题的确定

在 SVT 测试中,测试人员可能会碰到吞吐量降低问题,该问题会严重地影响应用程序的性能。识别吞吐量降低问题,并对它们进行分析以提出相应的解决方案,这对于 WebSphere 应用程序开发人员和测试人员来说是一个非常重要的任务。在解决了这些吞吐量降低问题之后,WebSphere 应用程序的性能将得到显著改善。

在 SVT 中识别吞吐量降低问题

这个部分将介绍吞吐量降低问题的主要特征,这些特征可以帮助您尽可能快地在 SVT 中识别 WebSphere 应用程序的相关问题。吞吐量逐渐降低,这是您在 SVT 测试中可能碰到的一个系统问题。主要的问题是在测试间隔(例如,3 小时)期间,吞吐量逐渐降低,并且 WebSphere 应用程序的响应时间变得越来越长。在压力测试工具的报告中,您可以很容易地发现这一趋势。图 1 显示了事务的运行情况、吞吐量/并发性、以及响应时间曲线。

图 1. 压力测试工具报告中的吞吐量降低问题
图 1. 压力测试工具报告中的吞吐量降低问题
图 1. 压力测试工具报告中的吞吐量降低问题

分析和解决吞吐量降低问题

这个部分简要介绍了我们的吞吐量分析方法,然后给出了关于如何分析和解决吞吐量降低问题的详细工作流程。

吞吐量的分析方法

根据我们的经验,导致吞吐量降低的主要原因是代码问题、数据库问题、以及测试数据或者方法问题。使用我们的测试报告就可以很容易地识别吞吐量降低问题,但是要找出导致这一问题的根源,则需要进行彻底分析研究。

在本文中,我们根据在 WebSphere Commerce 方面的经验,简要介绍了一种吞吐量分析方法。您可以使用它来分析下面的两类问题:吞吐量低于目标情况,或者吞吐量逐渐降低。本文重点关注后一个问题。图 2 是我们的吞吐量分析方法的实施计划。

下面对我们的方法进行简要说明:

  • 这一方法并不能够解决所有的数据库问题。通常,数据库问题可能是指由数据库导致的任何瓶颈问题,包括 SQL 查询、数据库优化参数、索引问题和数据分布问题。
  • 这个流程图假定已经建立了以前的性能基准。要为测试用例设置吞吐量基准,如果在以前的发行版中已经对这一用例做过测试,我们常常使用以前的结果作为我们的基准。如果该用例是一个新的用例,我们常常在新的发行版中使用最后的实际测试结果,以便为以后的比较设置基准。
  • 在图 2 中,“Divide & conquer”表示运行于较小的场景中,如仅用于主页、登录、以及浏览等方面,而不是端到端的实际运行。
  • Cost/SQL 是 SQL 查询的执行成本与执行次数的比值。在执行成本中,没有记录获取时间。
  • 访问计划可以根据累积的数据进行更改。您可以使用 DB2® Explain 实用工具来查找更多的线索。
图 2. 吞吐量分析方法
图 2. 吞吐量分析方法
图 2. 吞吐量分析方法

要获取对每一个步骤的详细描述,请看下面的部分“吞吐量降低的分析和解决方案”。

吞吐量降低的分析和解决方案

当在 SVT 中碰到吞吐量问题时,可以遵循下列步骤来分析和解决这个问题。测试人员应该识别该问题是一个单纯的低吞吐量问题、还是一个吞吐量降低的问题。其主要的识别方法是,检查在测试期间,压力测试报告的吞吐量/并发性图表中是否存在下降的趋势。如果是这样的话,那么它就是一个吞吐量逐渐降低的问题,如图 1 所示。否则,它就是一个单纯的低吞吐量问题。

您可以通过以下详细过程来对这一问题进行分析:

  1. 与基准结果进行比较,检查是否所有的 WebSphere 应用程序命令执行效率都下降。您可以通过检查我们的测试报告中的所有命令的平均响应时间,来完成这一工作。如果仅仅某些命令的响应较慢,这通常意味着设计问题或者代码问题,并且您可以使用 Jinsight 或者等价的 Java™ 概要分析工具来确定代码中的错误。
  2. 检查是否在重新启动 WebSphere Application Server 之后,仍然存在吞吐量降低的问题。如果这一问题在服务器重新启动之后不复存在,那么它很可能与非数据库特定的问题有关。最有可能的类型是内存问题,如内存泄漏、堆碎片、或者大对象分配。在某些情况下,可能是 WebSphere Application Server 的潜在问题导致了这个问题,并且您需要联系其服务团队。但是,如果您不能通过重新启动服务器来解决这个问题,则跳转到步骤 3 以继续您的分析。
  3. 检查是否对数据库进行过优化。对于 DB2,检查是否在 DB 服务器上已经运行了 runstats。如果没有,则启动 runstats。在数据量很大,或者系统已经运行了很长时间的情况下,runstats 对于提高 DB2 的性能是很重要的。runstats 还可以帮助优化 DB2 的访问计划,这将使得 DB2 更有效率。对于 Oracle®,您可以使用下面的命令来优化数据库性能:execute dbms_utility.analyze_schema ('schema_name', 'COMPUTE')。本文主要使用 DB2 和 runstats 作为我们的示例。
  4. 检查是否完成了数据库的优化。如果没有完成,尝试优化 DB2 的相关参数。可以进行优化的对象包括缓冲池、排序堆和锁。如果该问题在进行了数据库优化之后依然存在,那么有两个可能的问题:
    • 如果吞吐量不是逐渐地降低,那么请检查 DB2 快照文件,以分析经常使用的 SQL 查询的状态(执行次数和每个查询的成本),并找出是哪个查询导致了这个问题。
    • 如果吞吐量是逐渐降低的(本文所关注的重点),则跳转到步骤 5 以继续分析。
  5. 检查数据是否是均匀分布的。如果不是,请修复数据的问题。在测试期间,不适当的初始化或者不均衡的操作都可能导致数据的不均匀分布。例如,测试人员使用某些固定用户在初始化工作中下了一张订单,这将在数据库中创建数千条与这些用户相关的订单。另一方面,如果测试人员仅仅使用某些固定用户在正式的测试中下订单,那么相应的数据将会累积。这使得 DB2 查询使用表扫描代替索引扫描,并降低了数据库的性能。更好的方法在从正式的测试中忽略初始化工作用户,并从更大的用户范围中选择随机的用户。例如,从 400 个用户中随机地选择 20 个用户,以完成初始化工作和正式测试。
  6. 对于分治处理,可以尝试使用最小场景来重现该问题。这可以隔离导致吞吐量降低的可能的原因的范围。要完成这一任务,将测试场景划分为不同的组,并单独地进行测试,找出导致吞吐量降低的组,然后再次对这些组进行划分,直到您能够确定导致该问题的最小的场景组。
  7. 对步骤 6 中经过证实的场景运行较长的时间,并在测试期间获取多个快照。例如,在第一天和第二天分别获取 10 小时的快照,然后比较这两个快照。
  8. 比较多个快照,以查看 Cost/SQL 和 SQL 查询的执行次数是否在增长。如果是,清除数据并在需要的情况下优化索引。通过比较这些文件,您可以确定成本增长最大的查询。这里所说的成本可能是下面的度量之一:每次查询执行的执行时间、每次查询执行的用户 CPU 时间、以及每次查询执行的系统 CPU 时间。请注意,快照所报告的执行时间中不包含其他成本,如“获取时间”。请注意,您必须在多个快照中搜索相同的 SQL 查询,以找出其中哪一个是“正在增长”的。
  9. 如果所有的 Cost/SQL 条目都是不变的,则可以比较快照以查看是否对于某些 SQL 查询,读取/执行的行数在增长。如果是这样的话,尝试优化相应的索引以提高性能。如果不是这样,可以分析访问计划(例如,使用 DB2 Explain 实用工具)以了解可以修改其中的哪些内容。

在步骤 8 和步骤 9 中,您可以确定那些 Cost/SQL 或每次执行所读取的行数发生增长的、最常用的查询。通常对于所确定的查询,这两个特征是性能降低的主要指标。要解决这些问题,可以删除无关的索引,添加一个新的索引,或者在某些表中周期性地清除大量过期的数据。如果在快照中没有成本增加的 SQL 查询,可以分析访问计划,以查看可以根据累积的数据进行哪些修改。图 3 是一个示例,它反映了比较快照中每个 SQL 语句读取/执行的行数的统计。通过比较这两个在为期 4 天的测试中获得的快照,我们制作了这个图表。其中一个是在测试的第二天所获得的十小时的快照,另一个是在测试的第四天获得的十小时的快照。红色的数字表示成本增长的查询,并且需要对其进行修改。

图 3. 确定成本增长的 SQL 查询的示例
图 3. 确定成本增长的 SQL 查询的示例
图 3. 确定成本增长的 SQL 查询的示例

WebSphere Commerce SVT 中吞吐量降低的分析示例

这个部分介绍了我们在 WebSphere Commerce SVT 中实际碰到过的一个吞吐量降低的示例。该测试运行于 AIX 平台上的一层测试环境中。在相同的计算机上还安装了 DB2、IBM HTTP 服务器和 WebSphere Application Server。

这个吞吐量降低问题发生在一次为期 3 小时的压力比较测试中。根据来自以前的发行版的测试结果,我们将吞吐量基准设置为每小时 11580 个事务,并估计在新的发行版中性能会有 10% 的提高。所以,将这个用例的测试目标设置为每小时 12738 个事务。

发现吞吐量降低

在第一次运行过程中,我们检查了我们的压力测试工具报告。吞吐量曲线看上去相当的直,而且在一开始,吞吐量的降低并不明显。降低速度在每小时 5% 左右。然而,如果存在这样的降低速度,几天以后该应用程序将不能以合理的响应时间处理任何负载。图 4 显示了压力测试报告中的吞吐量图表。

图 4. 在压力测试工具报告中发现吞吐量降低
图 4. 在压力测试工具报告中发现吞吐量降低
图 4. 在压力测试工具报告中发现吞吐量降低

分析并解决吞吐量降低问题

这是一个吞吐量逐渐降低的问题。我们按照步骤 1 到步骤 3 分析该问题,并得到下面的结果:

  • 所有的 WebSphere Commerce 命令执行效率降低,特别是与订单相关的命令。
  • 在分析 native_stderr.log 时,我们发现垃圾收集周期没有问题,并且不存在内存问题,如内存泄漏、堆碎片和大对象分配。
  • 在重新启动服务器之后,这个吞吐量降低的问题仍然存在。
  • 完成 runstats 和一般的 DB2 优化。

在步骤 4 中,我们使 SORTHEAP 加倍到 2048 以避免排序溢出,因为某些查询需要创建临时表。

在步骤 5 中,当检查数据库时,我们发现一些数据问题。例如,在运行查询 select member_id, count(*) from orders group by member_id having count(*) > 50 之后,我们得到如图 5 所示的结果。

图 5. 在数据库中发现的数据问题
图 5. 在数据库中发现的数据问题

图 6 中的数据表示,其中四个用户比其他用户拥有更多的订单。在检查我们的测试步骤之后,我们发现导致这一问题的原因有如下几点:

  • 在初始化工作中,我们常常使用 4 个固定的用户来运行相关场景。
  • 这个数据库中有 200 个用户,但是在正式的测试中,仅仅选择了 20 个用户来运行相关场景。

以上两个因素使得数据库中的数据出现不均匀分布,所以我们的解决方案分为两个部分:

  • 将用户数量从 200 增长到 400。
  • 在初始化工作和正式的测试中,从 20 个非重复的用户中随机地选择每个虚拟用户。在完成这些更改以后,这个数据问题就不再出现了。

在步骤 6 中,我们将场景限制为订购流程。

在步骤 7 中,我们的测试持续运行四天,并分别在第二天和第四天获取两个十小时的快照。

在步骤 8 中,比较了这两个快照之后,我们没有发现任何成本/执行增长的查询。

在步骤 9 中,比较了这两个快照之后,我们确定了每次执行读取行数增加的、最常用的 SQL 查询,如图 6 中的红色部分所示。

图 6. 每次执行读取行数增加的、最常用的 SQL
图 6. 每次执行读取行数增加的、最常用的 SQL
图 6. 每次执行读取行数增加的、最常用的 SQL

确定这些“增加”的 SQL,为我们提供了相应的线索,以制定关于这个吞吐量降低问题的解决方案。在进行了下面的操作之后,吞吐量得到了提高:

  • 我们删除了 ORDERS 表中无关的索引 MEMBER_ID+TYPE+STOREENT_ID,所以查询将使用正确的索引 MEMBER_ID+STATUS+STOREENT_ID。
  • 我们为 BUSEVENT 表创建了 CHECKED 索引。
  • 在测试中,我们定时地清理 CTXMGMT/BUSEVENT 表。

图 7 显示了在我们应用前面的修改之后,相同的 SQL 的执行状态。大部分每次执行读取行数增加的情况已经得到了解决。

图 7. 已经解决了每次执行读取行数的增加
图 7. 已经解决了每次执行读取行数的增加
图 7. 已经解决了每次执行读取行数的增加

在修复了 SQL 成本增长之后,其吞吐量在开始的 3 个小时中似乎稳定下来,如图 8 所示。

图 8. 在开始的 3 小时中吞吐量是稳定的
图 8. 在开始的 3 小时中吞吐量是稳定的
图 8. 在开始的 3 小时中吞吐量是稳定的

然而,在长时间运行中仍然存在吞吐量降低问题,如图 9 所示。

图 9. 在长时间运行中存在吞吐量降低问题
图 9. 在长时间运行中存在吞吐量降低问题
图 9. 在长时间运行中存在吞吐量降低问题

然后,我们分析访问计划,并决定在长时间的测试运行期间,运行 runstats 并重新绑定数据库。图 10 和图 11 显示了 runstats 如何帮助优化访问计划。在这一示例中,访问计划的整体成本并不包括实际的获取时间。

图 10. 在运行 runstats 之前的访问计划
图 10. 在运行 runstats 之前的访问计划
图 10. 在运行 runstats 之前的访问计划
图 11. 在运行 runstats 之后的访问计划
图 11. 在运行 runstats 之后的访问计划
图 11. 在运行 runstats 之后的访问计划

在长时间的测试运行过程中,我们运行 runstats 并重新绑定数据库之后,整体吞吐量再次稳定下来,并且成功地解决了吞吐量降低的问题。因此,需要有规律地运行 runstats 并重新绑定数据库,以确保数据库索引不会过期。

结束语

本文简要介绍了我们在 WebSphere Commerce SVT 中分析和解决吞吐量降低问题的一些经验。本文还介绍了当碰到吞吐量降低问题时应该采取哪些措施、以及如何使用时间成本和每次 SQL 语句执行读取行数来分析 DB2 快照。吞吐量降低是一个复杂的问题,它与 DB2 和 SQL 性能优化、WebSphere Application Server 性能诊断、程序设计和代码编写都有关系。这涉及到测试人员和开发人员的合作,以便有效地和高效地分析和解决这些问题,并提高性能。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=280516
ArticleTitle=解决 WebSphere 应用程序中的性能降低问题
publish-date=01072008