准备高性能铺底数据以上介绍了铺底数据的重要性。要知道，准备的每张铺底数据表要上亿条。那么，我们如何快速而真实地准备铺底数据呢？
如果用简单的 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。这样我们就可以根据实际生产环境的要求来降低系统的风险性。
|
服 务 CIO 推 进 信 息 化 
