为了测试整个系统的性能，需要预先针对各个组成部分进行内部性能测试，如后台主机的压力测试、SNA gateway的压力测试、大前置系统的压力测试、前端系统的压力测试、外系统接入的压力测试等等。

        在本次进行的内部压力测试中，为了排除系统其它部分的影响，均需要隔离各自的部分，驱动和桩都使用软件测试工具或自行编制程序来代替。在每个部分的内部压力测试中，又均可以根据具体情况使用上一节说明的各种性能测试类型进行性能测量。

2. CS/CSS系统架构中的性能测试的度量项计算模型

    2.1 定义度量标准项 

        进行性能测试的模型分析时，首先要确定关键性能目标。它应该是通过与客户沟通获得的，这些目标应该是解决客户关注的性能问题，也就是说，客户的性能测试需求体现为关键性能目标。性能目标应该是明确的、可度量的。例如：支持2000个并发用户；连续运行30天不停机等。

        在明确了关键性能目标和性能测试的通过/失败准则后，需要定义如何度量关键性能目标和性能测试的通过/失败准则。度量的标准项会影响测试方法和测试工具的选择。举例来说，如果要度量100个用户并发的响应时间，就必须明确要度量以下哪一个标准项：

    *每个并发用户的响应时间

    *在有99个用户已经接入的情况下，第100个用户的响应时间

    *两个指标都要度量

    2.2 性能基准及测试强度估算

        实际上，关键性能目标并不总是很容易明确的。客户往往只有一些历史数据和业务增长的一些预期比例等等。但是这些数据对于我们也是很有用的，它们可以作为我们设计和测试使用的性能基准。

        对于性能测试，在设计时就要首先提出设计的性能基准。所谓性能基准，就是要思考：多少人使用这个系统？使用时最大的用户数是多少？用户高峰期使用时间间隔多少，在多大数量级别上系统响应时间分别是什么？数据增长量有多大？数据增长到什么数量级和时间长短对硬件而言难于承受？网络实现条件是什么？在处理时CPU和内存增长如何控制？种种这些，然后设计时根据性能基准有条件的在编码实现和硬件配置方面进行优化，测试只不过验证系统是否达到预期设计目标。

        但是现在的情况却往往是：设计出来后要求性能测试，测试什么然后是什么，好比考试没有标准答案却要求大家及格一样。或者是，客户虽然已经明确的提出了关键性能指标，但是设计的时候没有考虑，依赖于性能测试给出实际性能数据，然后再对比优化。性能测试在基于性能基准上，特别是基于经过计算和转换得到的关键性能目标，才能得出预期结果。这一点，需要测试工程师向设计人员反复灌输这种观念，否则，性能测试研究包括工具研究总是停留在讨论阶段。不要在编码完成以后才考虑优化问题，如果等项目实施了，优化还没有完成，就很难保证客户满意。

        没有目标的设计，如同城市间的交通问题一样，我们抱怨建设者们缺乏远见，而软件设计人员同样缺乏想象力。对于性能基准向关键性能目标的转化，用以下例子来说明。

        有200个用户使用客户端软件进行业务处理（并发度至少要达到200并发），每年通过软件进行处理的总业务量为：2000万笔业务/年。

        测试强度估算时采用如下假设前提：

    *全年的业务量集中在10个月完成，每个月20个工作日，每个工作日8个小时；

    *采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；

    测试压力的估算结果：

        去年全年处理业务约2000万笔，其中15%的业务处理每笔业务需对应用服务器提交3次请求；70%的业务处理每笔业务需对应用服务器提交2次请求；其余15%的业务每笔业务向应用服务器提交1次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务发展的需要，测试需按现有业务量的2倍进行。

    每年总的请求数量为：（2000*15%*3+2000*70%*2+2000*15%*1）*2="8000万次/年。

    每天的请求数量为：8000/200="40万次/天。

    每秒的请求数量为：（400000*80%）/（8*20%*3600）=55.6次/秒。

    正常情况下，应用服务器处理请求的能力至少应达到：56次/秒。

    或者，忽略提交的请求数，以业务交易数为准，定义每秒钟的交易数，及“吞吐量”。

    如果再考虑未来几年的交易量的增加（每年增长15％），则可以归纳为：

    ? 吞吐量：(T4*80%) /(1.6*3600)

    –T4 = T0 * (1 + 15%) ^ 4

    –T0：当前日均交易量2000万

    –T4：未来4年日均交易量

        另外，有时关键性能指标的确定和具体应用相关。如金融行业应用中的核心业务系统中会有日结、月结等批处理，往往使用一次批处理小于多少小时来表征性能指标。

    2.3 度量标准项和可采集的测量数据项转换

        只有使用明确的可采集到的数据才能真正反映系统的性能状况。例如：

    *每秒钟运行成功的交易数量

    *单一客户端的响应时间(使用时间戳的差值，发出请求的时间和收到回应的时间)

    *CPU的占用率

    *网络流量占用率

    *内存的占用率

    *硬盘使用率

    2.4 压力的分解

        对于一个由很多环节组成的复杂系统来说，如果想要模拟实际环境进行整体的联合性能测试的话，就需要针对整体压力进行各个层次的分解。

        如：下图是一个实际系统进行的联合性能测试。后台主机系统最多的吞吐量是480笔/秒。。由于通信网关和主机在此环境中是1对1的关系，所以通信网关的压力要达到480笔/秒。而一个通信网关对应着三个前置机，所以每个前置机要达到160笔/秒送达主机的吞吐量，才可能使整个系统满负荷运转。考虑到其它层次类推。由于主机以外还存在其它服务系统，所以在前置机的压力上面加了一个“X”代表其它服务系统要求的压力。当某个层次的设备短缺，无法实际上达到其分解下来的压力时，往往需要使用软件手段，在上一层次上直接加压力解决。