在大规模 SOA 应用的性能测试中，一个很重要的事就是准备铺底数据。所谓铺底数据，即在性能测试之前人工的向数据库里面存入用来模拟历史的或无用的大量数据。那么，为什么要准备铺底数据呢？通常情况下，准备大概每个表 1 G 的数据，数据量大概是每张表大于 5000 万条数据，如何快捷真实的准备铺底数据呢？本文还将简单介绍一下在性能测试的时候为什么需要搭建 WebSphere Process Sever (WPS) Cluster，以及如何搭建 WPS Cluster。最后，通过 Rational Performance Tester (RPT) 7 结合 WPS 集群进行性能测试，并分析比较在 WPS 服务器下的有无铺底数据支持的性能。
本文假设对某大型 SOA 系统进行的性能测试。其中主要的测试场景是案例的申请，保证所有在线用户同时在线录入档案。测试场景包括了创建成员的信息、收入及支出信息和提交救援案例的申请。共有 10 个 web services。
在这个系统中，性能测试需要模拟很多人同时在线的情景，通过性能测试工具能模拟任意多的人同时在线，而且要保证系统性能稳定，不论任何时候都要保证系统的请求和响应时间基本保持稳定，不会随着数据库的数据的增加而变慢。基于这些问题，就需要找到一种有效的方式来对系统进行性能测试。
在上面的场景中，需要一个长时间稳定的环境，那我们就可以增大数据库里面的数据量，并用一些负载平衡的应用服务器环境。综上所述，可以在数据库里面存入铺底数据，在服务器端搭建集群服务器。
那么如何制作铺底数据呢？以下的几段我们将详细阐述。
铺底数据就是我们在做性能测试之前，在数据库里面除数据库字典表外按照业务逻辑存入的大量的数据。这些数据可以视为垃圾数据，因为它们对系统的业务逻辑没有实际的影响，但对系统的性能却有着很大的影响。
- 铺底数据需要按照实际的情况去生成，要符合实际的生产情况的表的数据比例。譬如：有一张表的数据量和另外一张表的倍数关系是
5:1，那么准备数据的时候不论准备的数据是多少条，也需要保证这两个表的数据量的倍数是5:1。 - 铺底数据虽然是垃圾数据，但同样需要遵守数据库中数据的依赖关系。比如一对一，一对多的关系。
如下是我们在性能测试中准备的数据：
在性能测试之前在 DB2 里面准备的铺底数据，总量是：10.5 GB。
| Table Name | Data size(KB) | Data Count |
| Interested_party | 3,630,594 | 7,730,000 |
| Address | 178,600 | 1,230,000 |
| Interested_party_type_association | 760,719 | 7,720,000 |
| Household_member | 546,328 | 4,487,000 |
| Household | 28,840 | 1,239,000 |
| Document | 610,632 | 5,251,000 |
| Interested_party_association | 542,390 | 4,958,000 |
| Interested_party_address | 99,602 | 1,232,000 |
| Contact_phone | 143,581 | 1,232,000 |
| Address_contact_phone | 109,356 | 1,232,000 |
| Case | 269,039 | 2,479,000 |
| Case_document_association | 22,731 | 1,235,000 |
| Case_party_association | 537,562 | 4,958,000 |
| Evidence | 2,793,073 | 43,295,000 |
| evidence_party_association | 796,680 | 43,295,000 |
或许你会问，为什么要准备这些铺底数据？这些数据不是我们的实际生产环境的数据，那为什么要花时间去准备如此大量的数据呢？
答案是，系统在有铺底数据和没有铺底数据的情况下，性能会有很大的差异。那为什么会这样呢?
- 首先，如果没有那些铺底数据，那么本来为一张表建立了一个索引，当系统的数据量很小的时候，数据库就有可能造成全表扫描，而不走索引扫描，这样就会造成系统的性能降低。
- 如果数据量很小的话，我们不知道进行一次查询时候的 SQL 语句究竟是哪种执行路径方案。（数据库有自动根据 SQL 语句算出一条自认为最优化的路径的功能。譬如 DB2 的 ACCESS PATH。ACCESS PATH 会随着数据量的多少的变化而变化的。一旦系统比较庞大，在日积月累中，数据量会越来越大的。所以要准备一定数量的数据，让 ACCESS PATH 保持相对稳定。
如果数据量少，数据库为了优化有的时候就不用 INDEX 扫描，而采用全表扫描，这样造成整表被锁，导致死锁，而数据量大了以后数据库会进行 INDEX 扫描，所以不会琐住整个表。所以在有些情况下在系统上线时准备一些无用的数据放在表中，让数据库不会导致全表扫描！虽然有的时候可以通过改变锁的策略去解决这个问题，但是如果存在风险，在上线系统中就要避免。
1.4 铺底数据使得系统性能更加真实 , 更符合生产环境的真实情况
在数据库里面存入铺底数据，系统从一开始上线的时候，就已有了一个比较稳定的环境。如果没有铺底数据，那系统的环境可能随时面临着不稳定的因素：如性能陡变，数据库异常 ( 资源池不够用，数据库死锁，数据库全表扫描等等 )，响应时间突然下降。所以准备铺底数据，不但对性能测试意味深远，而且对即将上线的生产环境也是至关重要的。试想在银行系统中，如果不准备铺底数据，一旦系统上线的时候发生了问题，那么银行会损失多少客户！
准备铺底数据主要有以下几点原则：
- 准备的数据量大小：数据库中的数据量只要比内存大上若干倍，结果就差不多了。
- 数据在准备的时候，要保持原表的约束关系。
- 每张表的数据量要符合真实情况（对此点要求可能比较高 , 通常的做法是估算一下实际的情况）。
介绍了这些的原则，如何在实际操作中创建铺底数据呢？后面的第 2 章将结合上述的三条原则，具体讲述如何高性能地准备铺地数据。
文章来源于领测软件测试网 https://www.ltesting.net/
