通过一个进行实际性能测试的样例，通过对有铺底数据和没有铺底数据两种情况的测试结果所进行的分析，我们发现，使用铺底数据进行性能测试，不仅可以帮助测试人员更好地发现应用系统存在的问题，同时也能够使测试结果更加接近真实生产环境下的结果。

　　本文假设对某大型 SOA 系统进行性能测试，要保证所有在线用户能同时在线录入档案。测试场景包括创建成员信息、收入及支出信息和提交救援案例的申请等。

　　在这个系统中，性能测试需要模拟很多人同时在线的情景。通过性能测试工具能模拟任意多的人同时在线，而且要保证系统性能稳定，不论任何时候都要保证系统的请求和响应时间基本保持稳定，不会随着数据库数据的增加而变慢。基于这些问题，我们需要找到一种有效的方式来对系统进行性能测试。在上面的场景中，需要一个长时间稳定的环境，这样才可以增大数据库里面的数据量，并构建负载平衡的应用服务器环境。

　　综上所述，可以在数据库里面存入铺底数据，在服务器端搭建集群服务器。

　　为什么要准备铺底数据

　　那么，我们该如何制作铺底数据呢？下面我们将详细地阐述这些问题。

　　铺底数据就是我们在做性能测试之前，在数据库里除数据库字典表外按照业务逻辑存入的大量的数据。这些数据可以被视为垃圾数据，因为它们对系统的业务逻辑没有实际影响，但对系统的性能却有着很大的影响。

　　我们需要按照实际的情况去生成铺底数据，而且这一过程要符合实际的生产情况表的数据比例。譬如：有一张表的数据量和另外一张表的倍数关系是 5∶1，那么准备数据的时候不论准备的数据是多少条，也需要保证这两个表的数据量的倍数是 5∶1。

　　虽然铺底数据是垃圾数据，但是它们同样需要遵守数据库中数据的依赖关系。比如一对一、一对多的关系等。

　　我们在性能测试中准备的数据如“性能测试之前在 DB2 里面准备的铺底数据表”所示。

　　在性能测试开始之前，我们在 DB2 数据库里面准备的铺底数据的总量是10.5 GB。

　　或许你会问，为什么要准备这些铺底数据？这些数据不是我们实际生产环境中出现的数据，那为什么要花时间去准备如此大量的数据呢？答案是，系统在有铺底数据和没有铺底数据的情况下，性能会有很大的差异。那么，为什么会出现这种情况呢?

　　首先，如果没有那些铺底数据，那么，本来为一张表建立了一个索引，当系统的数据量很小的时候，数据库就有可能进行全表扫描，而不是索引扫描，因此，如果没有铺底数据的话，有可能会造成系统发生数据库的死锁。

　　如果数据量比较少，数据库为了优化，有的时候就不用索引扫描，而采用全表扫描，这样造成整表被锁，导致死锁。而数据量大了以后数据库会进行索引扫描，不会锁住整个表。

　　所以，在有些情况下，系统上线时必须要准备一些无用的数据放在表中，让数据库不会采用全表扫描。虽然有的时候可以通过改变锁的策略去解决这个问题，但是如果存在风险，在上线系统中就要避免。

　　其次，如果数据量很小的话，我们不知道进行一次查询的时候， SQL 语句究竟是哪种执行路径方案。数据库有自动根据 SQL 语句算出一条自认为最优化的路径的功能，譬如 DB2 的 ACCESS PATH。ACCESS PATH 会随着数据量多少的变化而变化。一旦系统的体系结构比较庞大，那么，在日积月累中数据量会越来越大。所以要准备一定数量的数据，让 ACCESS PATH 保持相对稳定。

　　因为，铺底数据使得系统性能更加真实，更符合生产环境的真实情况。在数据库里面存入铺底数据，系统从一开始上线的时候，就有了一个比较稳定的环境。

　　如果没有铺底数据，那么系统的环境可能随时都会面临着不稳定的因素，如性能陡变、数据库异常、响应时间突然下降等。所以准备铺底数据，不但对性能测试意义深远，而且对即将上线的生产环境也是至关重要的。试想在银行系统中，如果不准备铺底数据，一旦系统上线的时候发生了问题，那么银行会损失多少客户。

　　准备铺底数据主要有以下几个原则：1．数据库中的数据量只要比内存大上若干倍，结果就差不多了；2．数据在准备的时候，要保持原表的约束关系；3．每张表的数据量要符合真实情况。

　　准备高性能铺底数据

　　以上介绍了铺底数据的重要性。要知道，准备的每张铺底数据表要上亿条。那么，我们如何快速而真实地准备铺底数据呢？

　　如果用简单的 JDBC 程序插入铺底数据，性能会很差。而用 JDBC 写一个程序往数据库里面插入数据的话，速度会很慢，大概是10万条一张表，大约需要 20 分钟。

　　假设我们需要准备 1 亿条数据一张表，就是 10000/10×20/60＝333 小时。如果业务逻辑需要准备 20 张表，那我们准备这些数据将需要 333×20＝6660 小时＝277.5 天。这样的速度慢得惊人，所以通过 JDBC 准备铺底数据不行。

　　显然，我们需要更高效地产生铺底数据的方法。笔者所在团队选择了如下的方法：找出数据库之间的表结构关系，并据此把数据翻倍，利用 CPU 的运算能力高效率地生成的数据，并导入数据库，从而产生出所需的铺底数据。

　　如果要准备铺底数据，那么我们首先就要找到表与表之间的关联关系。也就是说，我们要清楚数据库里面主表和附表之间的关系是一对多或多对多，还要知道实际情况中，一张主表的一条记录大概对应附表的几条数据。只需要一个大概的规律就可以了，或者取一个中间值。我们可以通过 Rational Data Architect 生成的表结构图找到表与表之间的关系：准备原始的第一套数据（每张表大概 1000 条数据）。

　　我们在测试前，应该首先用 Rational Performance Tester 7.0 录制一个脚本。脚本里面包括要测试的主要用例。譬如：笔者所做的脚本一共包括１０个请求，要全部按照顺序录入到 RPT 中。

　　然后，我们应该重新建立数据库，使数据库里面不存在数据。接下来，我们就可以利用上文叙述中录制好的 Rational Performance Tester 脚本，并循环 1000 次。这样我们的数据库里面的一些表里就会有 1000 条数据了。然后，我们在数据库里面查看哪些表中的数据增加了，然后把这些表里面的数据导出到文本文件里。

　　性能测试环境准备

　　在本文中，我们采用的测试环境是：用IBM WebSphere Process Sever 集群做应用服务器，用IBM DB2 做数据库，用Rational Performance Tester 7.0 做性能测试工具，用IBM HTTP Server 做 HTTP Server（如图１）。

　　一组相互独立的服务器在网络中表现为单一的系统，并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。在大多数模式下，集群中所有的计算机都拥有一个共同的名称，集群内任意系统上运行的服务可被所有的网络客户所使用。Cluster 必须可以协调管理各分离组件的错误和失败，并可透明地向 Cluster 中加入组件。

　　一个 Cluster 包含多台（至少两台）拥有共享数据存储空间的服务器。任何一台服务器运行一个应用时，应用数据被存储在共享的数据空间内。每台服务器的操作系统和应用程序文件存储在其各自的本地储存空间上。Cluster 内各节点服务器通过内部局域网相互通信。当一台节点服务器发生故障时，这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。当一个应用服务发生故障时，应用服务将被重新启动或被另一台服务器接管。当以上的任一故障发生时，客户都将能很快连接到新的应用服务上。

　　利用集群我们可以解决 JVM 紧张的问题，可以分摊 I/O 的负载量，还可以有效地降低系统的故障率。假如一台 Server 的稳定性是 99%，那么系统宕机的几率就是 0.01。如果我们两个 Server 在一起的集群环境的不稳定性将降低到 0.0001，也就是有两个 Server 的集群环境的稳定性可提高到0.9999。这样我们就可以根据实际生产环境的要求来降低系统的风险性。

　　本测试环境中我们就采用了 WPS 集群（WPS Cluster）。Cluster（集群）是多个 WPS 的集群，它可以集中管理所有 WPS，并参与管理所有 WPS 的负载。WPS 6.0.1 及以上版本支持搭建 Cluster，可以做到负载均衡（Workload Balance）和高可用性（High Availability），从而使 WPS 更加稳定，性能更为卓越。况且，在一般的真实生产环境中，WPS 集群也是经常要被用到的。本测试环境 的拓扑结构如图2所示。

　　Cluster 分两种，水平 Cluster 和垂直 Cluster。水平 Cluster 的成员在不同物理机器上，垂直Cluster 的成员在同一台物理机器上。

　　在这里由于测试环境的限制，我们采用的是竖直 Cluster，有三个 Cluster 成员。其中有 Deployment Manager 类型的 Profile，它可以管理整个单元内部所有的 WPS。Deployment Manager 通过和 Node Agent 的交互信息来管理节点。而 Node Agent 用来管理三个 Cluster 成员。我们还需要在 WPS Cluster 和应用中间加入一个 HTTP Server，使应用通过 HTTP 协议访问 WPS Cluster 的时候随机地分摊到不同的 Cluster 上面。

　　在理想的情况下，性能测试的环境最好能够完全模拟真实应用部署的环境，以便于通过性能测试得到应用在真实生产环境下的性能结果。然而，由于真实应用部署环境的规模比较大，上述思路是不实际的。因此，为了能够得到更具真实性的性能结果以及更好地发现应用存在的性能问题，我们在测试中采用可控制的测试环境来尽量模拟真实环境，其中也包括对历史数据的准备。在我们的测试环境中，为了更好地分析数据库和应用本身的性能问题，如 I/O 问题，将 WPS 和数据库将分别安装在不同的物理机上。

　　首先通过 HTTP 请求到 HTTP Server ，再进入 UI 层，然后通过 UI 调用 Web Service，Web Servive 再通过 HTTP Server 调用 BPEL 和 WSDL 文件，再通过 JDBC 连接 Database，并用 Content Manager 存入一些文件（如 PDF、Word）到 Database 上。

　　用 IBM HTTP Server 做 HTTP Server，并在WebSphere Application Server 上搭建 UI 层，将 BPEL WSDL 搭建到 WebSphere Process Server 上，然后用 DB2 做 Database。现在，我们所需要的整个测试环境就基本搭建完成了。

　　分析测试结果

　　通过分别对没有铺底数据和有铺底数据的情况进行相同的性能测试，我们发现测试结果有很大的区别，主要表现在页面平均响应时间方面。

　　经过测试，在没有铺底数据的情况下，页面平均响应时间是 58.552ms；而在有铺底数据的情况下，则是 608.344ms。从Rational Performance Tester 生成的测试报告中，我们可以清楚地看到每个页面的平均响应时间。

　　从两类页面平均响应时间的对比，可以看出在有铺底数据的情况下，平均响应时间高于没有铺底数据的测试结果。经过查找问题根源，发现在这两个页面中，由于在数据库中进行了大量视图的创建和 select 语句的操作，导致了响应时间比较长。

　　因此，从上述比较结果中我们可以看出，在有铺底数据的情况下进行性能测试，能够帮助测试人员更好地发现被测应用系统存在的问题。

　　另外，一般应用在真实情况下的生产系统中运行时，都会存在大量的历史数据。因此，我们在测试时就需要加入铺底数据，这样不仅能够得到更加真实的测试结果，而且能够及早发现应用系统中存在的隐患，从而避免在系统正式运行后才发现问题给后续工作带来很大麻烦。

　　通过一个进行实际性能测试的样例，通过对基于 WebSphere Process Sever 的应用程序性能的测试，通过对有铺底数据和没有铺底数据两种情况的测试结果所进行的对比与分析，我们发现，使用铺底数据进行性能测试不仅可以帮助测试人员更好地发现应用系统存在的问题，同时也能够使测试结果更加接近真实生产环境下的结果。

　　图１ ＷＰＳ Ｃｌｕｓｔｅｒ 的拓扑图

　　图２ 性能测试环境的拓扑图