基于 SOA 应用程序的性能测试方法

第 6 页，共 10 页 文档选项 对本教程的评价 帮助我们改进这些内容

性能测试的执行

本文将介绍的 SOA 性能测试是采用 IBM 的性能测试工具 - Rational Performance Tester Extension for SOA Quality 进行测试。进行性能测试的三大步骤是：部署测试环境，录制以及执行测试脚本，分析测试结果。部署测试环境通常包括应用程序环境服务器的搭建（包括服务器集群的搭建）、数据库服务器的搭建、铺底数据的准备，这些都是性能测试必不可少的内容。本文在第五章重点介绍了这些内容，在这里也就不占用篇幅了。文本将以一个模拟 project 为例，在下面两个小节详细介绍如何进行 SOA 应用程序的性能，如何录制测试脚本，并对得到的测试结果进行性能分析。

录制测试的脚本和执行测试

录制测试脚本是性能测试不同于其他测试的区别之一，因为性能测试要同时执行多个脚本，并模拟多人访问网页，故无法手工执行测试脚本，只能依靠工具去模拟。通常情况下我们录制脚本是通过 bs 结构的 url 来录制脚本的。但是我们现在将要结合我的例子来介绍如何利用 Rational Performance Tester Extension for SOA Quality 录制 SOA 的 WSDL 组成的业务流程（BPEL）的方法。

• 性能测试脚本的录制

首先要选择一套系统主要的测试用例作为执行脚本进行录制。这套测试用例要能覆盖 Non Functional Requirement 的所有 testpoint。录制一套由各种各样的 WSDL 组成的 BPEL 需要 Rational 的 Rational Performance Tester Extension for SOA Quality

录制 soa 的性能测试脚本因为不像 web 可以从 url 去录制 , 而需要首先录制 wsdl，利用 Rational Performance Tester Extension for SOA Quality 把 wsdl 录制成 services。

导入 wsdl

创建一个用 Web Service Explorer 的 Web Service 记录的工程。导入项目中用到的 wsdl 以及（xsd）。如下图所示：

服务的创建及录制

创建一个 test 记录

添加 wsdl 到测试脚本里

如下是创建好的 wsdl 里面的一些操作已经被 Rational Performance Tester Extension for SOA Quality 分析出来并把操作列到 Web Services Explorer

或者手工建立一个 wsdl，并加入到 case 里面。手工加入 wsdl 要执行的 create 操作到 source 里面

到此测试脚本录制完成。

• 性能测试脚本的执行

首先创建一个 performance schedule

将上一步录制得到的测试脚本添加到新创建的 performance schedule 中

按照本文第四部分介绍的负载模型的设计，首先采用 Ramp-up Run 的方式得到在一定测试环境下的最大用户负载量，然后用 Flat- Run 方式进行基准测试。在这里，需要对 performance schedule 中 think time, delay time 和 number of uses 设置不同参数。

设置完成后，执行 performance schedule

在 performance schedule 执行前，需要启动 nmon 来捕获测试用例在整个执行过程中系统各项性能的数据并形成图形报告。首先启动 nmon，然后运行命令：

# nmon -f -s second -c count

这里 second 表示每两个捕获点之间的时间间隔，count 表示捕获次数。这样需要估计测试用例大致的总运行时间，并保证总运行时间不能小于 second * count。这样在测试执行结束后即可得到一份完整的系统性能数据报告。

同时在测试用例执行过程中 , 也可以使用 nmon 进行实时监控，运行 L，显示实时动态 CPU 变化；运行 M，显示 memory 变化情况；运行 N，则显示网络实时运行情况。

如上图所示，可以在测试执行过程中实时监控到系统性能情况，如 CPU，内存，网络等。这样可以知道当前情况下是否运行正常，CPU 或内存是否已经到满负荷，从而决定是否停止增加负载量或者停止当前测试执行。

回页首

测试结果的分析

• 数据库服务器的 I/O 满了，成为系统瓶颈。

当执行性能测试脚本的时候，发现数据库服务器的 I/O 满了。

以下是数据库服务器的 I/O 监控图：

在性能测试运行中，监控数据库的 SQL 执行路径，发现有一个 SQL 的执行路径图如下：

下面是监控执行此 SQL 时的数据。

Number of executions = 7438
 Number of compilations             = 0
 Worst preparation time (ms)        = 0
 Best preparation time (ms)         = 0
 Internal rows deleted              = 0
 Internal rows inserted             = 0
 Rows read                          = 7438
 Internal rows updated              = 0
 Rows written                       = 0
 Statement sorts                    = 7438
 Statement sort overflows           = 0
 Total sort time                    = 0
 Buffer pool data logical reads     = 7438
 Buffer pool data physical reads    = 3224
 Buffer pool temporary data logical reads   = 0
 Buffer pool temporary data physical reads  = 0
 Buffer pool index logical reads    = 3645023
 Buffer pool index physical reads   = 2224709
 Buffer pool temporary index logical reads  = 0
 Buffer pool temporary index physical reads = 0
 Total executio = 
 select * from DB2ADMIN.PARTY_ROLE_RELATIONSHIP where
 (PARTY_ROLE_ID = ? and RELATED_PARTY_ROLE_ID= ? and PARTY_REL_CATALOG_CODE= ?)

通过观察我们会发现

Buffer pool index logical reads = 3645023

Buffer pool index physical reads = 2224709

读取了很多的 index，虽然不是表扫描，但是却造成 index 扫描，里面两个 index 里面分别包含着两个字段，造成 SQL 执行的时候找它们两个的交集，数据会翻倍，所以造成 I/O 满了。

解决这个问题的办法是建立一个 index 在 PARTY_ROLE_RELATIONSHIP 里面，包裹两个字段（PARTY_ROLE_ID , PARTY_REL_CATALOG_CODE）这样再执行以下性能测试脚本，并进行监控。

同样记录数据库服务器的 I/O 情况和监控数据库的执行路径，如下两图所示：

Number of executions = 6856
Number of compilations = 0
Worst preparation time (ms) = 2
Best preparation time (ms) = 2
Internal rows deleted = 0
Internal rows inserted = 0
Rows read = 2235
Internal rows updated = 0
Rows written = 0
Statement sorts = 6856
Statement sort overflows = 0
Total sort time = 0
Buffer pool data logical reads = 2235
Buffer pool data physical reads = 0
Buffer pool temporary data logical reads = 0
Buffer pool temporary data physical reads = 0
Buffer pool index logical reads = 29508
Buffer pool index physical reads = 1
Buffer pool temporary index logical reads = 0
Buffer pool temporary index physical reads = 0
Total execution time (sec.ms) = 0.000000
Total user cpu time (sec.ms) = 0.750000
Total system cpu time (sec.ms) = 0.046875
Statement text = 
select * from DB2ADMIN.PARTY_ROLE_RELATIONSHIP where
 (PARTY_ROLE_ID = ? and RELATED_PARTY_ROLE_ID= ? and PARTY_REL_CATALOG_CODE= ?)

读取索引的数据比起以前的

Buffer pool index logical reads = 3645023

Buffer pool index physical reads = 2224709

降低到

Buffer pool index logical reads = 29508

Buffer pool index physical reads = 1

• JVM 的大小如何设置，性能调优。

此场景是一个 WPS 下面有 3 个 cluster member，我们找到一种三个 cluster member 用多大的 JVM 比较合适。

Case8.3 起一个 cluster member，cluster member 的 JVM 设置为 512MB。

Case8.4 起一个 cluster member，cluster member 的 JVM 设置为 2048MB。

Case8.5 起一个 cluster member，cluster member 的 JVM 设置为 1024MB。

Case8.6 三个 cluster member 都起来，每一个 cluster member 的 JVM 设置为 1024MB。

通过测试结果发现，平均相应时间最快的是 Case 8.6。Case 8.3，8.4，8.5 里面最好的是 Case 8.5。所以运用 JVM 的时候最好的是 JVM 1024。

回页首

	第 6 页，共 10 页