性能测试工具.docx

性能测试工具之研究王玉亭性能测试的意义追求更高的质量和更高的性能是人类的天性。“更高，更快，更强”的奥运 会是对人类自身运动能力的测试。同样，人类也在追求我们工作生活中不可或缺 的IT系统能够提供更快更强的服务。目前IT系统已经称为各个企业运转业务时 最重要的系统之一。对IT历史稍微有所了解的人都知道，IT系统经过早年的一 个人使用的单机系统时代，几十个人使用的局域网中的客户机服务器系统时代， 到现在服务成千上万用户的跨广域网的庞大系统时代。IT系统发展中的最明显 的特征之一就是所谓的“数据大集中”，即数据越来越集中到后台的服务器中， 系统同时为成百上千，乃至上万的用户提供服务。这样的例子在银行、保险、电 信公司中随处可见。随着企业业务量的加大，其IT系统承载的负荷越来越重， 系统性能的好坏严重影响了企业对外提供服务的质量。对IT系统的性能进行测 试和调优越来越引起企业的重视。目前，典型的企业IT系统的架构如下所示：inLvrnci/inLrcineL这样的系统由客户端、网络、防火墙、负载均衡器、Web服务器、应用服 务器（中间件）、数据库等等环节组成，根据木桶原理，即木桶所能装的水的量取 决于最短的那块木板，整个系统的性能要得到提高，每个环节的性能都需要优化。 在这样的IT系统中，每个环节的都是一个很复杂的子系统，对其调优都是一门 专门的技能。Oracle数据库的调优就需要专门的技能和多年的经验。对于整个IT 系统的调优，其复杂程度更是急剧增加。因此IT系统性能测试调优是一个复杂 的项目，需要拥有各种专门技能的专家组成小组来完成。这些专家包括操作系统 专家、网络专家、数据库专家、应用服务器专家、应用软件和业务专家等等。虽然性能测试是一项很复杂和专业的工作，但是由于企业IT系统的重要性， 保证其性能的稳定对于企业对外提供优质服务越来越得到企业的重视。性能测试 服务的市场正在快速发育中。研究系统性能测试越来越有意义。要保证性能测试项目的高质量，必需依赖两个重要的因素：人和工具。具 有多年经验的高素质的专家小组是保证性能测试的最重要的因素。另一方面，功 能全面、使用灵活的性能测试工具对于加速性能测试，提高测试质量和效果也是 必不可少的。现在有很多种性能测试工具，从功能简单单一的开放源码的软件到昂贵的 商业性能测试工具。本文论述了性能测试工具的一般体系架构和技术要点，并探 讨了利用已经存在的开放源码的软件整合出一套开源的优质的性能测试工具的 可行性。性能测试工具综述性能测试的主要手段是通过产生模拟真实业务的压力对被测系统进行加 压，研究被测系统在不同压力情况下的表现，找出其潜在的瓶颈。因此，一个良 好的性能测试工具必需能做到以下几点：1. 提供产生压力的手段2. 能够对后台系统进行监控3. 对压力数据能够进行分析，快速找出被测系统的瓶颈。产生压力的手段，主要是通过编写压力脚本，这些脚本以多个进程或者线 程的形式在客户端进行运行，来模拟多用户对被测系统的并发访问，以此达到产 生压力的目的。由于一台普通的PC机可以轻易产生几百乃至上千个进程或线程， 通过使用若干台PC机，就可以轻易模拟出成千上万个并发用户。压力脚本执行 的功能和被测系统客户端软件执行的功能应该一样，从而产生真正的业务压力。 编写压力脚本的工作实际上就是重新编写客户端软件。为了快速达到编写脚本的 目的，采用的最有效的方式是通过性能测试工具录制客户端软件和服务器之间的 通讯包，自动产生脚本，然后在自动生成的脚本的基础上进行少量修改，如：关 联动态内容，指定批量测试数据等。根据经验，压力脚本的准备工作往往占据整 个性能测试项目的50%的时间和工作量。因此，能否提供录制和自动产生脚本 的功能是性能测试工具最主要的评价指标之一。压力脚本的方式给我们提供了模拟各种压力状况的有力手段，通过人为制 造各种类型的压力，我们可以观察被测系统在各种压力状况下的表现，从而定位 系统瓶颈，作为系统调优的基础。因此，提供丰富的对后台系统进行监控的手段 是性能测试工具第二个最主要的评价指标。监控应该不在被测系统上安装任何软 件，否则的话，为了监控而引入的“代理”之类的小软件将给被测系统引入新的 可变因素，一方面造成了测试结果的不准确，另一方面会给用户的系统的稳定性 可能造成影响，从而导致用户的反感和拒绝。目前，各种监控手段大都采用所谓 “无代理”的方式，即不在被测系统上安装任何软件，仅仅通过改变被测系统的 配置，就可以对被测系统进行监控。需要监控的部件多种多样，包括操作系统、 数据库、中间件、应用系统、安全模块、网络、防火墙等等。一组压力测试运行完毕后，我们会得到详尽的性能数据。这些数据包括最终用户的响应时间，后台系统各个部件的运行数据。这些数据的量非常大，往往 包括几千个变量的运行曲线，大小可能达到上G的规模。靠人工去分析这些数 据几乎是不可能的，性能测试工具必需提供数据分析工具，帮助性能测试人员去 阅读、解读和分析数据，辅助测试人员定位系统的瓶颈。数据分析工具是保证最 终测试成果的手段，因此它是性能测试工具中最重要的部分之一。目前已经存在的性能测试工具林林总总，数量不下一百种，从单一的开放 源码的免费小工具如Aapache自带的web性能测试工具ab到大而全的商业性能 测试软件如Mercury的LoadRunner等等。任何性能测试工具都有其优缺点，我 们可以根据实际情况挑选用最合适的工具。前面已经指出，性能测试是一项复杂的工作，一个性能测试项目的质量如 何，测试人员的素质、能力和经验是最关键的因素。拥有世界上最先进的CT扫 描仪并不能让你成为一个优秀的医生。不过，“工欲善其事，必先利其器”，拥 有一套自己非常熟悉，功能全面、质量可靠的性能测试工具对于从事性能测试的 人员非常有吸引力。在商业性能测试软件中，Mercury公司出品的LoadRunner 是一套功能全面的测试工具软件，口碑非常好，但是其价格非常昂贵。由于 LoadRunner是按照并发用户数收取费用，因此要获得大的并发量的价格是很高 的。虽然存在很多免费的性能测试工具，但其功能不足，彼此不成系统，不能灵 活搭配使用。一套功能全面的性能测试工具的开发工作量是非常大的，这也是为什么商 业性能测试软件价格昂贵的主要因素之一。由于互联网和开放源码运动的发展， 性能测试工具的各种功能都以各种形式的开源软件存在了。如果我们设计出一套 合理的架构，在统一的架构下整合各种缺乏系统性的开源工具软件，使之能够 彼此配套，搭配出一套功能全面、质量可靠，而且是开放源码的性能测试工具 是完全有可能的。有了这套开放源码的性能测试工具，我们可以提供高质量的性 能测试服务，利用服务来赚钱。“通过免费提供开源软件，通过服务赚钱”的自 由软件运动或许能够在性能测试领域找到理想的实践环境。本文的下面部分具体论述性能测试工具的基本框架和技术要点，希望热爱 编程，希望对开放源码运动有所贡献的读者能从本文的论述中获得一些启发，沿 着作者的思路继续往前行。性能测试工具的体系架构作者对性能测试工具LoadRunner比较熟悉，通过对LoadRunner的了解和 评估，作者设计的性能测试工具体系架构如下图所示：性能测试工具的组成部分有如下几个： 虚拟用户脚本产生器 Vugen(Virtual User Generator)压力调度和监控系统Conductor 压力产生器Player压力结果分析工具Analysis通常，进行性能测试项目的一般步骤如下:1. 用户确定需要录制的交易，通过用户操作和Vugen的录制，记录并 生成自动化脚本。2. 修改脚本，确定脚本能够回放成功。3. Conductor是一个集中控制平台，它和压力产生器player互连，指定 脚本在player上的分配，并控制player向被测系统的加压方式和行 为。4. Conductor同时负责搜集被测系统的各个环节的性能数据。各个 Playe会录最终用户响应时间和脚本执行的日志。5. 压力运行结束以后，Player将数据传送到Conductor中，Conductor 负责将数据汇总。6. 数据分析工具Analysis读取压力测试数据，进行分析工作，确定瓶 颈和调优方法。7. 针对性地进行系统调优，重复进行压力测试，确定性能是否得到提 高。8. 重复以上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 bufBUF_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。Proxy二次捕获的问题Vugen的Proxy方式需要解决的一个问题是二次捕获数据包的问题。早期的网络服务器程序对外提供一个固定端口，客户端仅仅和这个端口通 讯就可以了。这对于proxy录制非常容易。但是现在很多服务器程序为了提高对 客户端并发量的支持，采用两个端口通讯的方式。如下图所示：Process1Process?Process3Process4Proxy二次捕获的问ISPoit=4188The Server MachineClient整个通讯的过程如下： 第一步：客户端将请求发往Proxy录制器。 第二步：Proxy录制器将请求发往真正的服务器的指定端口，即图中的 3200 端口。 第三步：服务器机器的3200端口返回数据包给Proxy录制器。该数据 包中包含了下一次通讯的目的地址，形式为IP:Port。很显然，这里的 IP数据为真正服务器的IP地址。 第四步，Proxy录制器把请求返回给客户端。第五步，客户端根据提供的IP：Port信息直接把请求发往真正的服务器， 不再经过Proxy录制器。 第六步：以后的通讯只是客户端和服务器之间的通讯了，Proxy录制器 是无法捕获这些通讯包了。因此一般的Proxy录制器只能捕获头两个收发的数据包。这个问题更一般 的情形的例子是HTTP的redirection功能。第二次通讯可能发往另外一台机器了。 Proxy录制器必需解决这个问题。关联的问题客户端和服务器之间的通讯，有一部分是数据是动态的，每次通讯都不一 样。Proxy录制器在录制的时候是无法区分哪些是静态的信息，哪些是动态的信 息，所有的信息都以hard-coded的方式记录下来。但是在回放的时候，如果有些信息不改变，那么脚本是不能执行成功的。考虑如下情形:VuGen Script1. Log inUser Name jojo Password bean2. Your sessionid123453. Request for product info4. Product info foundLogin.(User Name jojoPassword bean)二 Response”(SessionlD12345 )Request for product infoWeb(SessionlD12345 )>Server< Response Product infoDynamic data is hard-coded in the script如上图所示，用户jojo以jojo/bean的账号/口令登录某一 web服务器，查询 某产品的信息，由Vugen录制交易的全部通讯包。web服务器返回给jojo 一个动 态的会话ID: SessionID12345，作为这次登录的会话标识。由于Vugen无法知 道哪些信息是动态的，它会照单全收的方式，把所有的数据就记录下来。接着jojo 根据Web服务器告诉他的SessionID去查询产品列表，交易可以正常执行下去。我们会观察到，当Vugen根据捕获的通讯包生成http脚本的时候，SessionID 是Hard-coded的，即“写死”在程序里面的。当我们不加修改的回放该脚本的 时候，会出现什么问题呢？如下图所示：ERROR SessionID 12345 has expired Login again to get product infoVuGen Script1.Login User Name jojo Password bean2.Your sessionid123453.Request for product info4.Product info foundRequest for product info(SessionID 12345 )Login(User Name jojo Password bean)Response(SessionID23456 )WebServer按照录制时候的脚本，jojo以jojo/bean登录后，Web服务器返回给jojo 一 个动态会话ID: SessionID23456，这个值已经不是录制时候产生的 SessionID12345 了，而是新的值：SessionID23456。那么脚本根据记录的 SessionlD的值，仍然会使用SessionID12345去执行下面的查询交易。由于会 话ID是有时效性的，用户退出系统后，其SessionlD会失效，那么，服务器会 给出一个“SessionlD失效”的错误，从而导致脚本无法正常执行下去。对于上面的问题的通用解决方法如下图所示：Request for product infoHere is the requested product infoRecorded dynamic data must be correlated using parametersWebServer2.Your <session id>34,.Correlated VuGen Script> (SessionlD回回由23456>)ResponseResponse (SessionlD23456 )Login(User Name jojo Password bean)在第一次从服务器得到SessionlD的时候把其放在一个变量session_id里 面，在后面脚本访问服务器的语句里面，把所有的”SessionID12345”替换为变 量session_id就可以圆满解决这个问题。这种问题在任何系统都是非常常见对外问题。其通用的模式是：“服务器返 回给客户端一些动态变化的值，客户端使用这些值去访问服务器的时候，不能把 这些值写死在脚本里面，而应该存放在一个变量里面。”这就是关联的概念。关联的工作往往占据开发脚本的大部分时间，因为我们必需针对每一个具 体的系统进行细致的分析，确定其需要关联的动态信息。为了快速开发脚本， Vugen必需提供帮助我们关联的手段，最好做到自动关联。自动关联的方法有三 种：在录制之前设定辨别规则，录制完毕，产生脚本的时候根据规则识别出 需要关联的动态内容，从而产生正确的脚本。录制完毕回放一遍，把回放结果与录制结果进行自动对比，确定动态信 息，进行自动关联。录制两个一模一样的脚本，对比其中的差异来确定需要关联的动态信 息，然后进行关联。自动关联的功能是否完整可靠，关系到我们能否借助Vugen快速开发出符 合要求的脚本，因此关联也是Vugen中非常重要的功能。脚本的问题Vugen产生的最终结果是以源程序方式存在的脚本。为了编译该脚本，用 户可以选用对应的编译器，这不是Vugen的功能。建议Vugen产生脚本的时候 应该生成对应的Makefile和build.xml，允许用户以流行的make和ant命令来编 译C和Java的脚本。关于make和ant，读者可以在互联网上查询相应的内容。Vugen自动产生的脚本应该支持两种语言，C / Java。很显然，Vugen不可 能产生一个脚本运行的全部的代码，它需要额外的函数库的支持。譬如，通过录 制Tuxedo协议产生的脚本应该是以Tuxedo-API的形式出现的。为了能够编译运 行脚本，必需把Tuxedo的函数库连接到脚本里面。目前动态库的技术应用非常 广泛，因此为了运行Tuxedo脚本，必需在Vugen和Player机器上安装相应的 Tuxedo客户端软件，因为它包含相应操作。其它网络协议也存在这个问题。对 于http协议，已经有很多函数库。Vugen产生的http脚本应该支持主流的函数库。 这样带来的好处是我们不需要自己开发http函数库，可以直接引用已经经过实践 证明了的质量可靠的函数库。选择支持何种函数库，需要慎重选择，我们应该选 择应用最广泛的函数库。例如：关于http函数库，可以采用www.w3c.org提供 的libwww，该函数库是开源的，质量可靠，远胜于我们自己开发。Conductor 和 Player 部分Conductor，我们称为“指挥家”，它是整个压力测试的核心。Player是产生 压力的负载产生器，它们以进程或者线程的方式运行由Vugen生成脚本。Player 如何运行脚本，由Conductor来决定。这好比一个交响乐队在演奏。Player就是 各种管弦乐演奏者，Conductor是指挥者。Conductor和Player实际上是一套框架程序。具体执行什么功能，是由脚本 来完成的。Conductor和Player的体系结构如下图所示：如上图所示，Conductor上面有若干进程/线程。每种进程的作用如下： Center进程是整个调度的核心进程，它负责联系和用户界面打交道的工 作。 Agent进程负责和远端的Player机器中对应的Agent进程通讯。负责把 编译好的脚本传送到Player机器上。在脚本运行的时候，定期从Player 机器上获取Player的运行状态，每个虚拟用户运行的日志。 Monitor进程负责对被测试系统的各个环节进行监控，并把监控的内容 一方面写入Conductor机器的本地磁盘，另外一方面把监控的内容传送 给Center进程，实时地显示在用户界面上。Player的进程有两种，一个是Agent进程，一个是Player进程。Agent负责 和Conductor机器通讯，它根据Conductor的指示，在本机器上派生出指定数目 的Player进程，这些Player进程负责具体执行相应的脚本。Player进程个数就是 虚拟用户的个数。Player需要解决的一个问题是IP问题。为了防止黑客的攻击，某些后台的 负载均衡设备一旦发现来自某一个IP的请求特别频繁时，就会拒绝为该IP提供 服务。这样的功能造成的结果是Player无法把真正的压力加到后台系统中。解决 方法就是在Player机器上伪装多个IP地址发送请求。这项技术称为IP欺骗(IP Spoofling)。Conductor和Player必需实现该项功能。Conductor和Player的技术要点关于Conductor和Player的技术要点有哪些，目前我还没有做深入的研究工 作，但是我认为其技术要点主要涉及多进程/线程的编程，网络编程技术。可能 这里面最大的难点是监控问题。当把被测系统的各个环节都监控起来，需要监控 的参数会有成百上千个。如果采用集中式监控的方式，采集数据本身就对系统造 成很大的影响，所以必需支持分布式监控方式。由于采集的数据是来自不同机器 上的，由于各种的延迟，数据之间的时间同步将是一个重大的问题。关于监控，还需要进一步的研究。由于Player是没有界面的，以后台运行的程序，为了保持其可移植性，建 议采用Java语言开发。Player和Conductor之间的网络协议不一定重新开发，可以使用成熟的Http 1.1，方便在性能测试时调试Player和Conductor之间可能出现的通讯问题。数据分析工具Analysis该工具是一个纯数学工具软件，目前市场上已经存在了大量负责数据处理 的软件，如Matlab等。可以将压力产生的数据直接导入其中进行处理。所以只 要提供开放的数据接口就可以了，无需自己开发独立的性能数据分析软件。即使Analysis需要开发，应该开发一些知识分析的功能。譬如，我们搜集 了很多Oracle的数据信息，这些数据之间往往有固定的联系。如果将这些联系 的知识融入到Analysis当中，将会更好。但是这有点类似人工智能的意味，比较 难。结束语本文是对性能测试工具的一般性论述，讨论了性能测试工具的基本功能和 可能出现的技术要点。由于性能测试工具涉及的内容太多，作者只是大致论述。 其中涉及细节当中仍然会有很多技术要点没有论述。只是希望本文对希望了解性 能测试工具的读者有一个入门的帮助。一套功能全面的性能测试工具就象水管工经常携带的工具箱，里面充满各 种工具，这些工具经过组合可以完成任何复杂的机械工作。完全从头开发这套工 具箱，工程浩大，靠业余的编程爱好者是很难完成的。但是我们应该吸取Unix “小而灵活”的哲学思想，在一个大的框架下面开发或者利用已经存在的开源工 具软件制造出一个个灵活的部件。当把这些部件组合起来以后，就是一个功能完 整、质量可靠的性能测试工具箱。而每个工具的制造是几个人完全可以完成的。 作者打算利用业余时间完成Vugen的设计工作，打算作为开源软件贡献出来。性能测试作为一种专业服务，其市场前景是有目共睹的，熟悉开源性能测 试工具的朋友完全可以利用自己对工具的熟悉，从事性能测试专业服务赚钱。单 纯卖性能测试工具赚钱很难，靠服务赚钱起步是非常容易的。也许，性能测试服 务是开源软件和赚钱结合的比较好的领域吧。希望事实如此。