基于系统真实数据的TUXEDO应用服务器压力测试的研究与实现

    4．测试系统的示意图
    通过以上几个方面的讨论，我们对压力测试程序的主体和数据的流程有了认识。以上也是该压力测试方案不同于一般的压力测试工具的地方。下面我们通过一个示意图来给获得一个感性的认识。

    5．TUXEDO参数的调整
    为配合压力测试，TUXEDO服务器的一些参数需要进行相应的调整。涉及的主要参数是以下几个：

    MAXACCESSERS

    最大访问者的数目，这个包含多种类客户端，大于P_NUM * 1.2(参考值)。

    MAXWSCLIENTS

    最大workstation client的数目，要求大于P_NUM。

    WSL -m 2 -M 30 -x 10

    WSH的数目和每个的并发处理能力。m为WSH的初始数目，M为WSH的最大数目，x为每个WSH可以接受的WS client的连接数。要求M * x > P_NUM。

    以上是几个主要的参数，由于连接数要受到license的限制，一般正式license中USERS不会很大，所以进一步的测试可以找一个USERS数目较大的试用license。关于TUXEDO的配置可以参考相应的文档，这里不详细说明。

    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服务器，便于观察其在不同负载下的表现，以及在负载非常重的情况下的稳定性和容错性，包括自我恢复的能力。

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

    本文是笔者根据上述实践总结归纳出的一些方法和思路，并指出了需要注意的问题，希望能给其他系统的设计和开发人员在面对相关问题的时候提供一些参考。