6.测试数据的生成
    由于压力测试是要长时间的运行的,而且要测试很多次,包括不同的配置的情况下,所以真实的数据往往是不够用的,而上面的测试方法要求数据都是在数据库中真实存在的。针对这个问题,我们可以根据真实数据生成一些满足要求的数据。现在一般的DBMS都支持INSERT … SELECT 语句,通过下面的方法可以产生大量的可用数据。

假设某一个表的一条记录以RECORD_ID为主键,max(RECORD_ID) = M;通过下面的SQL语句:INSERT INTO table_name(RECORD_ID, …) SELECT RECORD_ID+M, … FROM table_name; 就可以使表中的记录数double。依此类推,可以使数据量指数级的增长,而这些数据除了一些标识性的ID不同,其他都是以真实数据为蓝本的,比纯粹由测试程序制造出的数据能更好的满足TUXEDO服务程序的要求,实际的测试也证明了这一点。而且通过该方法,结合对业务增长的预测,我们可以模拟系统运行了某一段时间之后的性能情况。

7.测试的延伸
以上主要是针对TUXEDO服务程序的测试,其实以上的测试方法可以用来进行其它方面的测试。这里列举两个主要的方面:

一是TUXEDO的一些负载均衡机制,通过大量clinet的并发操作,可以分析针对具体的硬软件配置情况下,那种配置是最合适的。

二是分析TUXEDO和数据库的连接方式。目前TUXEDO连数据库主要有XA和server直连两种方式。以上方法也可以对这两种方式的实际效果进行评估。

8.要注意的问题及可以改进的地方
为了使压力测试的结果能更接近真实的情况,有一些问题需要注意。

首先压力测试和真实的情况有一个很大的分别是所有的客户端都是在一台机器上,而不是真实环境下的分布在很多的PC上,这样对测试程序所在的机器的性能就有一定的要求。实际测试中我们采用了一台和主机性能接近的UNIX小型机,在模拟客户端数目较大时仍能满足要求。若没有高性能的测试机可用,可以分布在几台机器上,同时运行测试程序。

另外操作系统的一些核心参数也需要考虑并做相应调整,比如一般UNIX系统中队列的容量默认为16KB,不是很大,还有一些IPC的值对TUXEDO性能也有一定的影响,因为TUXEDO使用了Q、SEM、SHM等IPC通信机制,关于这个,TUXEDO官方文档中有详细的讲解。这些可以和系统管理员一起来进行调整。

上面提到的测试程序内部数据流也可以用其它的方式实现。数据库服务器的一些相关参数也可以做相应的调整,使得主要压力集中在TUXEDO服务器,便于观察其在不同负载下的表现,以及在负载非常重的情况下的稳定性和容错性,包括自我恢复的能力。

小结:笔者根据上面提到的思路和方法为所在的项目进行了长时间的压力测试,并给项目经理和系统管理员提交了正式的压力测试报告,使得大家对系统的一些整体性能有一个比较客观的认识和评估,为满足设计要求并顺利通过验收打下了基础,获得了比较好的效果。该测试程序通过简单的配置和修改又被用于报表等其它的服务模块。


相关内容