性能测试工具之研究

    · 性能测试的意义

    追求更高的质量和更高的性能是人类的天性。 “ 更高，更快，更强 ” 的奥运会是对人类自身运动能力的测试。同样，人类也在追求我们工作生活中不可或缺的 IT 系统能够提供更快更强的服务。目前 IT 系统已经称为各个企业运转业务时最重要的系统之一。对 IT 历史稍微有所了解的人都知道， IT 系统经过早年的一个人使用的单机系统时代，几十个人使用的局域网中的客户机服务器系统时代，到现在服务成千上万用户的跨广域网的庞大系统时代。 IT 系统发展中的最明显的特征之一就是所谓的 “ 数据大集中 ” ，即数据越来越集中到后台的服务器中，系统同时为成百上千，乃至上万的用户提供服务。这样的例子在银行、保险、电信公司中随处可见。随着企业业务量的加大，其 IT 系统承载的负荷越来越重，系统性能的好坏严重影响了企业对外提供服务的质量。对 IT 系统的性能进行测试和调优越来越引起企业的重视。

    目前，典型的企业 IT 系统的架构如下所示：

    这样的系统由客户端、网络、防火墙、负载均衡器、 Web 服务器、应用服务器 ( 中间件 ) 、数据库等等环节组成，根据木桶原理，即木桶所能装的水的量取决于最短的那块木板，整个系统的性能要得到提高，每个环节的性能都需要优化。在这样的 IT 系统中，每个环节的都是一个很复杂的子系统，对其调优都是一门专门的技能。 Oracle 数据库的调优就需要专门的技能和多年的经验。对于整个 IT 系统的调优，其复杂程度更是急剧增加。因此 IT 系统性能测试调优是一个复杂的项目，需要拥有各种专门技能的专家组成小组来完成。这些专家包括操作系统专家、网络专家、数据库专家、应用服务器专家、应用软件和业务专家等等。

    虽然性能测试是一项很复杂和专业的工作，但是由于企业 IT 系统的重要性，保证其性能的稳定对于企业对外提供优质服务越来越得到企业的重视。性能测试服务的市场正在快速发育中。研究系统性能测试越来越有意义。

    要保证性能测试项目的高质量，必需依赖两个重要的因素：人和工具。具有多年经验的高素质的专家小组是保证性能测试的最重要的因素。另一方面，功能全面、使用灵活的性能测试工具对于加速性能测试，提高测试质量和效果也是必不可少的。

    现在有很多种性能测试工具，从功能简单单一的开放源码的软件到昂贵的商业性能测试工具。本文论述了性能测试工具的一般体系架构和技术要点，并探讨了利用已经存在的开放源码的软件整合出一套开源的优质的性能测试工具的可行性。

    · 性能测试工具综述

    性能测试的主要手段是通过产生模拟真实业务的压力对被测系统进行加压，研究被测系统在不同压力情况下的表现，找出其潜在的瓶颈。因此，一个良好的性能测试工具必需能做到以下几点：

    · 提供产生压力的手段

    · 能够对后台系统进行监控

    · 对压力数据能够进行分析，快速找出被测系统的瓶颈。

    产生压力的手段，主要是通过编写压力脚本，这些脚本以多个进程或者线程的形式在客户端进行运行，来模拟多用户对被测系统的并发访问，以此达到产生压力的目的。由于一台普通的 PC 机可以轻易产生几百乃至上千个进程或线程，通过使用若干台 PC 机，就可以轻易模拟出成千上万个并发用户。压力脚本执行的功能和被测系统客户端软件执行的功能应该一样，从而产生真正的业务压力。 编写压力脚本的工作实际上就是重新编写客户端软件。为了快速达到编写脚本的目的，采用的最有效的方式是通过性能测试工具录制客户端软件和服务器之间的通讯包，自动产生脚本，然后在自动生成的脚本的基础上进行少量修改，如：关联动态内容，指定批量测试数据等。根据经验，压力脚本的准备工作往往占据整个性能测试项目的 50% 的时间和工作量。 因此，能否提供录制和自动产生脚本的功能是性能测试工具最主要的评价指标之一。

    压力脚本的方式给我们提供了模拟各种压力状况的有力手段，通过人为制造各种类型的压力，我们可以观察被测系统在各种压力状况下的表现，从而定位系统瓶颈，作为系统调优的基础。因此，提供丰富的对后台系统进行监控的手段是性能测试工具第二个最主要的评价指标。监控应该不在被测系统上安装任何软件，否则的话，为了监控而引入的 “ 代理 ” 之类的小软件将给被测系统引入新的可变因素，一方面造成了测试结果的不准确，另一方面会给用户的系统的稳定性可能造成影响，从而导致用户的反感和拒绝。目前，各种监控手段大都采用所谓 “ 无代理 ” 的方式，即不在被测系统上安装任何软件，仅仅通过改变被测系统的配置，就可以对被测系统进行监控。需要监控的部件多种多样，包括操作系统、数据库、中间件、应用系统、安全模块、网络、防火墙等等。

    一组压力测试运行完毕后，我们会得到详尽的性能数据。这些数据包括最终用户的响应时间，后台系统各个部件的运行数据。这些数据的量非常大，往往包括几千个变量的运行曲线，大小可能达到上 G 的规模。靠人工去分析这些数据几乎是不可能的，性能测试工具必需提供数据分析工具，帮助性能测试人员去阅读、解读和分析数据，辅助测试人员定位系统的瓶颈。数据分析工具是保证最终测试成果的手段，因此它是性能测试工具中最重要的部分之一。

    目前已经存在的性能测试工具林林总总，数量不下一百种，从单一的开放源码的免费小工具如 Aapache 自带的 web 性能测试工具 ab 到大而全的商业性能测试软件如 Mercury 的 LoadRunner 等等。任何性能测试工具都有其优缺点，我们可以根据实际情况挑选用最合适的工具。

    前面已经指出，性能测试是一项复杂的工作，一个性能测试项目的质量如何，测试人员的素质、能力和经验是最关键的因素。拥有世界上最先进的 CT 扫描仪并不能让你成为一个优秀的医生。不过， “ 工欲善其事，必先利其器 ” ， 拥有一套自己非常熟悉，功能全面、质量可靠的性能测试工具对于从事性能测试的人员非常有吸引力。在商业性能测试软件中，大多价格非常昂贵。由于大多数性能测试工具是按照并发用户数收取费用，因此要获得大的并发量的价格是很高的。虽然存在很多免费的性能测试工具，但其功能不足，彼此不成系统，不能灵活搭配使用。

    一套功能全面的性能测试工具的开发工作量是非常大的，这也是为什么商业性能测试软件价格昂贵的主要因素之一。由于互联网和开放源码运动的发展，性能测试工具的各种功能都以各种形式的开源软件存在了。 如果我们设计出一套合理的架构，在统一的架构下整合各种缺乏系统性的开源工具软件，使之能够彼此配套，搭配出一套功能全面、质量可靠，而且是开放源码的性能测试工具是完全有可能的。

    本文的下面部分具体论述性能测试工具的基本框架和技术要点，希望热爱编程，希望对开放源码运动有所贡献的读者能从本文的论述中获得一些启发，沿着作者的思路继续往前行。

    · 性能测试工具的体系架构

    作者对性能测试工具 LoadRunner 比较熟悉，通过对 LoadRunner 的了解和评估，作者设计的性能测试工具体系架构如下图所示：

    性能测试工具的组成部分有如下几个：

    · 虚拟用户脚本产生器 Vugen(Virtual User Generator)

    · 压力调度和监控系统 Conductor

    · 压力产生器 Player

    · 压力结果分析工具 Analysis

    通常，进行性能测试项目的一般步骤如下：

    · 用户确定需要录制的交易，通过用户操作和 Vugen 的录制，记录并生成自动化脚本。

    · 修改脚本，确定脚本能够回放成功。

    · Conductor 是一个集中控制平台，它和压力产生器 player 互连，指定脚本在 player 上的分配，并控制 player 向被测系统的加压方式和行为。

    · Conductor 同时负责搜集被测系统的各个环节的性能数据。各个 Player 会记录最终用户响应时间和脚本执行的日志。

    · 压力运行结束以后， Player 将数据传送到 Conductor 中， Conductor 负责将数据汇总。

    · 数据分析工具 Analysis 读取压力测试数据，进行分析工作，确定瓶颈和调优方法。

    · 针对性地进行系统调优，重复进行压力测试，确定性能是否得到提高。

    · 重复以上 3-7 步，逐步提高系统的性能。

    鲁制脚本的工具虚拟用户产生器 Vugen 实际上是一套开发调试工具。 Conductor 是一个框架程序和监控程序，它负责将 Vugen 开发的脚本以多进程 / 多线程的方式在 Player 机器上运行。为了产生更大的压力， Conductor 必需支持集群功能，理论上 Conductor 可以和任意多台 Player 机器互连，以便产生足够大的负载压力。 Conductor 同时实现无代理方式的监控功能，可以监控各种主流的软件，并且提供对不支持的软件进行监控的二次开发的手段。 Analysis 实际上是一个数据分析工具，用于事后的数据分析，它可以安装在任何 Windows 平台的机器上。下面我们论述每个部件的技术要点。

    · 虚拟用户产生器 Vugen

    虚拟用户产生器通过录制客户端和后台服务器之间的通讯包，分析其中的协议，自动产生脚本。用户在自动产生的脚本的基础上进行修改，从而快速开发出一个逻辑功能和客户端软件完全一样的压力脚本程序。

    录制的技术主要是通过 proxy 的方式来实现的，如下图所示：

    Vugen 根据对捕获的数据的分析，将其还原成对应协议的 API 组成的脚本。由于 Proxy 源程序的获得非常容易， Vugen 的主要的技术要点是 如何根据捕获的数据包来反解析成对应的网络协议 。通常捕获的数据包为 TCP 数据流，我们可以很容易的生成 socket 层次的脚本，类似如下示例：

    int main( int argc, char** argv)

    {

    char buf[BUF_MAX_LEN];

    int socket = 0;

    socket = connect(“IP=192.168.52.65”, “Port=3200”, TCP);

    getbuffer(buf, “trace.dat”, 1, SEND);

    send(socket, buf);

    receive(socket, buf);

    getbuffer(buf, “trace.dat”, 3, SEND);

    send(socket, buf);

    receive(socket, buf);

    ……

    close(socket);

    }

    其中 trace.dat 包含着录制时捕获的数据包，按照 “ 发 - 收 - 发 - 收 - 发 - 收 ” 的顺序排放。

    毫无疑问，这样的脚本按照记录的收发过程来回放，但是它的最大的缺点是处于太底层。要分析和修改 socket API 的脚本以及数据包的具体内容将是一个繁重而且烦人的工作，进行关联的工作的难度也将大大提高。客户端程序往往是利用更高层的应用协议 API 编写的，客户端软件的编写者也不一定对 socket-API 组成脚本进行修改。因此， Vugen 应该尽可能地产生更高层网络协议的脚本 ，方便用户的阅读和修改工作。

    以 Tuxedo 应用为例，对于 Tuxedo 应用，一次典型的 Tuxedo 业务调用的序列为：

    tpinit(….) // 和后台建立连接

    tpcall(….) // 向后台发起交易请求

    tpterm(…) // 断开和后台的连接

    这三次 api 调用将产生 TCP 层的 7 次收发动作， Vugen 必需根据这 7 次的收发，还原产生 Tuxedo-API 的调用序列。

    由于对于不同的应用层协议，只能分别开发，因此， Vugen 支持的网络协议的多少是衡量性能测试工具的主要指标之一。

    当然， socket 方式是一切应用层协议的基础， socket 脚本是一种通用的方式。对于 Vugen 不支持的应用层协议只能通过 socket 层次来录制。因此 Vugen 能生成 socket-API 脚本是其最基本的功能。

    VuGen 产生的脚本应该应该是跨平台的，因此它应该提供 C/Java 两种语言的方式，支持各种平台的 C/Java 编译器。脚本可以在 Windows/Unix/Linux 上运行， Player 运行的机器既可以是 Windows 平台，也可以是 Linux, FreeBSD, Solaris, AIX 和 HP-UX 等平台，这样会方便用户选择机器作为 Player 。这一点非常重要。

    由于 Vugen 支持的每种应用层协议必需单独开发，在设计 VuGen 的软件体系架构时，应该采用插件的方式来设计网络协议的解析器。这部分的设计借鉴了 Apache 的 module 设计思想，可以让任何对开发协议解析器感兴趣的开发者在一个统一的框架下开发。

    VuGen 的体系结构如下图所示：

    Vugen 的体系结构分为三部分：

    · 第一部分为底层 proxy 录制器 , 负责捕获客户端和服务器之间通讯的数据包，这样的软件在开放源码的世界里面随处可见，而且非常成熟。 我们只要移植过来就可以使用。

    · 第二部分是界面部分，提供脚本编辑、调试和运行功能，这部分可以用 Visual C++/MFC 实现 Windows 平台版本和 Java/AWT 实现 Unix 版本。

    · 第三部分是以插件的形式提供的分析各种网络协议的解析器。开发这类插件的强有力的开发工具为 lex 和 yacc 。