|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 > 负载压力测试实施 >
|
|
相关知识点：80个
|
|
|
|
|
|
|
测试环境直接影响测试效果，所有的测试结果都是在一定软硬件环境约束下的结果，测试环境不同，测试结果可能会有所不同，特别对于压力负载测试更是如此，因为压力负载测试结果往往是一组和时间有关的值，因此对负载压力测试环境的准备就显得特别的重要。
|
|
|
|
|
|
. 要满足软件运行的最低要求，不一定选择将要部署的环境；
|
|
|
|
|
|
|
|
|
|
|
|
负载压力测试环境准备过程中可以参考测试环境的基本准则，但是又要考虑负载压力测试的特殊性和负载压力测试目的。负载压力测试一般强调“真实”应用环境下的性能表现，从而实现性能评估、故障定位以及性能优化的目的，因此在负载压力测试环境的准备中要注意以下几点：
|
|
|
|
. 如果是完全真实的应用运行环境，要尽可能降低测试对现有业务的影响；
|
|
|
|
. 如果是建立近似的真实环境，要首先达到服务器、数据库以及中间件的真实，并且要具备一定的数据量，客户端可以次要考虑；
|
|
|
|
|
|
|
|
|
|
|
|
|
|
. 操作系统的版本（包括各种服务、安装及修改补丁）；
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
大多数情况下我们强调真实环境下检测系统性能，在实施过程中大家认为这样做会遇到很多阻力，比如真实环境下，不允许负载压力测试为系统带来大量的垃圾数据；测试数据与真实业务数据混在一起无法控制测试结果；负载压力测试如果使服务器宕机，会给系统带来巨大损失等。那么我们应该如何理解“真实环境下检测系统性能”呢？
|
|
|
|
在负载压力测试中我们强调的“真实环境”是指后台服务器与客户端应用要与实际真实应用环境保持一致，同时，这里也包括了与业务有关的软硬件配置环境和数据量环境等，可以看出我们将网络环境排除在外。原因是网络环境缓解了客户端对服务器所造成的并发负载压力，网络规模越大、网络类型越多、网络拓扑越复杂、网络流量越纷繁交织对客户端的并发负载压力缓解程度越大。
|
|
|
|
|
|
这里主要讨论选择测试工具的原则，介绍一些主流负载压力测试工具，同时也涉及到测试工具的缺陷等内容。
|
|
|
|
|
|
古人云“工欲善其事，必先利其器”，进行负载压力性能测试首先应该选择一个合适的测试工具，一个测试工具能否满足测试需求、能否达到令人满意的测试结果，是选择测试工具要考虑的最基本的问题。更进一步可以考虑一些细节问题，比如该工具对于处理扩展的交互（例如一个请求取决于上一个请求的结果）如何；对于处理cookies（cookies对于许多面向会话的J2EE系统是必不可少的）如何；如果J2EE应用程序客户机需要处理一些JavaScript，以进入下一次通信会如何处理；在收集了响应时间数据后，如何对它进行分析；对CPU时间、网络使用、堆大小、分页活动或者数据库活动如何监控等都是选择一个测试工具需要考虑的具体问题。一些高端工具与基本工具往往在一些细节、适用范围以及易用性方面存在差别。比如，顶级的负载测试工具可以模拟多个浏览器，与大多数应用服务器集成，收集多个服务器主机的性能数据（包括操作系统、JVM和数据库统计数字），生成可以在以后用高级的分析工具分析的数据集。
|
|
|
|
当然，测试工具的选择首先应该看是否能够满足基本测试需求，该工具必须可以模拟应用程序客户机，如果应用程序使用一些不常见的浏览器功能组合或者其他非标准客户机技术，那么就排除了相当一部分候选者。具备了基本功能后，可以考虑工具的生产率。一般来说，包含的分析工具越多，可以记录的性能数据类型越多，可以达到的生产率就越高，价格也就越高。不过有些低端负载测试程序是免费的，在预算有限的情况下，“免费”的意义是不言自明的。
|
|
|
|
|
|
|
|
首要要求一定是负载测试程序能够处理应用程序所使用的功能和协议。
|
|
|
|
|
|
这是负载测试程序最基本、且最重要的功能，它有助于确定哪些是负载测试程序以及哪些不是。
|
|
|
|
|
|
如果不能编辑客户机与服务器之间交互的脚本，那么就不能处理除最简单的客户机之外的任何东西。编辑脚本的能力是最基本的，且小的改变不应该要求重新生成脚本。
|
|
|
|
|
|
如果不支持会话或者cookies，就不算是真正的负载压力测试工具，并且不能对大多数J2EE应用程序进行负载测试。
|
|
|
|
|
|
测试程序应该可以让您指定每个脚本由多少个模拟用户运行，包括让您随时间改变模拟用户的数量，因为许多负载测试可以做到从小的用户数量开始，并慢慢增加到更多的用户数量。
|
|
|
|
|
|
每一个脚本都必须定义一个方法来识别成功的交互以及失败和错误模式（错误一般不会有页面返回，而失败可能在页面上得到错误的数据）。
|
|
|
|
|
|
如果测试工具可以检查一些发送给模拟用户的页面，这会很有用，这样可以做到心中有数，以确保测试工作是正确进行的。
|
|
|
|
|
|
可以用不同的工具来分析测试结果，这些工具包括电子表格和可以处理数据的自定义脚本。虽然许多负载测试工具包括大量的分析功能，但是导出数据的能力使您在以任意的方式分析和编辑数据方面具有更大的灵活性。
|
|
|
|
|
|
真实世界的用户不会在收到一页后立即请求另一页，一般在查看一页和下一页之间会有延迟。考虑时间这个标准术语表示在脚本中加入延迟以更真实地模拟用户行为。大多数负载测试程序支持根据统计分布随机生成考虑时间。
|
|
|
|
|
|
用户一般不会使用同样的一组数据，每位用户通常与服务器进行不同的交互。模拟用户应该也这样做，如果在交互的关键点，脚本可以从一组数据中选择数据，则可以更容易地让您的模拟用户表现出使用不同数据的行为。
|
|
|
|
|
|
相对于编写脚本，用浏览器手工运行会话并记录这个会话，然后再编辑会容易得多。
|
|
|
|
|
|
一些应用程序大量使用JavaScript并且需要模拟客户机支持它。不过，使用客户端JavaScript可能会增加对测试系统上系统资源的需求。
|
|
|
|
|
|
得到测试数据只是成功的一半，另一半是分析性能数据。因此测试工具提供的分析工具越多，就越有利于从不同的方面进行数据分析。
|
|
|
|
|
|
基本负载压力测试工具测量客户机/服务器交互中基于客户机的响应时间。如果同时收集其他统计数据（如CPU使用情况和页面错误率）就更好了，有了这些数据，就可以进一步做一些有用的工作，如查看服务器负载上下文中的客户机响应时间和吞吐量统计。
|
|
|
|
|
|
任何负载压力测试工具都不是完美无缺的，在我们的实际使用中经常碰到一些问题，概括起来主要有以下几点：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在实际压力测试过程中，我们通常使用多种工具达到测试目的，如何配合使用多种工具，是否能达到最好的“性能价格比”？测试工程师要发挥最大的主观能动性。
|
|
|
|
|
|
. QALoad——美国Compuware（康博）公司。
|
|
|
|
|
|
①测试接口。DB2，DCOM, ODBC, ORACLE, NETLoad, Corba, QARun, SAP, SQLServer, Sybase, Telnet, TUXEDO, UNIFACE, WinSock, WWW。
|
|
|
|
②预测系统性能。当应用升级或者新应用部署时，负载测试能帮助确定系统是否能按计划处理用户负载。QALoad并不需调用最终用户及其设备，它能够仿真数以千计的用户进行商业交易。通过QALoad，用户可以预知业务量接近投产后的真实水平时端对端的响应时间，以便满足投产后的服务水平要求。
|
|
|
|
③通过重复测试寻找瓶颈问题。QALoad录制/回放能力提供了一种可重复的方法来验证负载下的应用性能，可以很容易地模拟数千个用户，并执行和运行测试。利用QALoad反复测试可以充分地测试与容量相关的问题，快速确认性能瓶颈并进行优化和调整。
|
|
|
|
④从控制中心管理全局负载测试。QALoad Conductor工具为定义、管理和执行负载测试提供了一个中心控制点。Conductor通过执行测试脚本管理无数的虚拟用户。Conductor可以自动识别网络中可进行负载测试的机器，并在这些机器之间自动分布工作量以避免网段超载。从Conductor自动启动和配置远程用户，跨国机构可以进行全球负载测试。在测试过程中，Conductor还可以在负载测试期间收集有关性能和时间的统计数据。
|
|
|
|
⑤验证应用的可扩展性。出于高可扩展性的设计考虑，QALoad包括了远程存储虚拟用户响应时间，并在测试结束后或其他特定时间下载这些资料的功能。这种方法可以增加测试能力，减少进行大型负载测试时的网络资源耗费。QALoad采用轮询法采集响应时间，在无需影响测试或增加测试投资的条件下，就可了解测试中究竟出现了什么情况。
|
|
|
|
在利用QALoad进行测试时，可以有选择地改变硬件或软件的配置，并改变测试步调和负载量。QALoad系统的NetLoad模块帮助建立所需的额外网络流量来模拟真实的产品负载。借助于“NetLoad”，可以在大环境下分配虚拟用户，更好地规划在投产环境中如何让这些应用更好地工作。
|
|
|
|
QALoad引入了“flash”为电子商务应用软件作容量测试。flash测试允许在测试期间增加大量的虚拟用户，来确定压力对底层部件和基础结构的影响。flash测试也可以证明应用投产后其响应时间将不会降低至服务级以下。
|
|
|
|
⑥快速创建仿真的负载测试。准确仿真复杂业务的进行，对于预测电子商务应用软件的功能至关重要。运用QALoad，可以迅速创造出一些实际的安装测试方案，而不需要手工编写脚本或有关应用中间软件的详细知识和协议。
|
|
|
|
对结合了多种传输协议的应用软件进行负载测试是一个巨大的挑战。为了准确仿真这些应用软件产生的流量，QALoad可以捕获多种协议并在同一测试过程中执行它们。基于浏览器的应用经常打开与服务器的多个连接以缩短网页下载时间，导致服务器的额外流量。QALoad能准确地仿真出浏览器与服务器之间的交互，包括多重连接，使负载更加准确。
|
|
|
|
另外，这些应用软件常常包含一些在测试方案中必须申明的动态信息。运用QALoad的ActiveData特征，可以定义脚本参数，以帮助确保应用测试脚本的成功执行。
|
|
|
|
例如，对一些安全或非安全的Web应用软件，ActiveData自动转化为动态信息，如cookies，包括动态Active Serve Page cookies、动态URL名称、服务器导向、动态框架或者其他时期的特定信息。ActiveData for Web有助于保证测试脚本与Web应用在测试过程中保持同步。
|
|
|
|
ActiveData每次自动查找和提出需要的变更建议，使测试脚本正确执行。在脚本执行过程中，脚本中的信息可以被产生的正确信息自动替代。
|
|
|
|
|
|
这些特点应该是负载压力测试工具普遍具备的特点，在后面的负载压力工具介绍中就不再赘述，而是介绍一些除了这些之外的特点。
|
|
|
|
|
|
|
|
|
|
测试结果分析如下图所示，1—2—3表示业务组A，4-5-6表示业务组B，7—8—9表示业务组C，10—11—12表示业务组D，在各个业务组中序号从小到大表示不同的并发用户。
|
|
|
|
|
|
|
|
. LoadRunner——美国Mercury Interactive公司。
|
|
|
|
|
|
①测试接口：支持的协议多且个别协议支持的版本较高；
|
|
|
|
|
|
|
|
④报告可以导出到Word、Excel以及HTML格式。
|
|
|
|
|
|
|
|
. Benchmark Factory——美国Quest软件公司。
|
|
|
|
|
|
|
|
|
|
③可以生成高级脚本，例如脚本中数据池的生成可以采用随机数。
|
|
|
|
|
|
这是一个Microsoft提供的免费的Web负载压力测试工具，应用比较广泛，下面做一个较详细的介绍。
|
|
|
|
WAS可以通过一台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies，也能够模拟各种浏览器类型和Modem速度，它的功能和性能可以与数万美元的产品相媲美。
|
|
|
|
要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本：①通过记录浏览器的活动；②通过导入IIS日志；③通过把WAS指向Web网站的内容；④手工制作。
|
|
|
|
制作WAS脚本是相当简单的，不过要制作出模拟真实用户活动的脚本就有些复杂。如果你已经有一个运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。
|
|
|
|
|
|
①Number of hits：测试间隔内虚拟用户点击页面的总次数；
|
|
|
|
②Requests per second：每秒客户端的请求次数；
|
|
|
|
|
|
④TTFB Avg：从第一个请求发出到测试工具接收到服务器应答数据的第一个字节之间的平均时间；
|
|
|
|
⑤TTLB Avg：从第一个请求发出到测试工具接收到服务器应答数据的最后一个字节之间的平均时间。
|
|
|
|
准备好测试脚本之后，我们可以调整测试配置，以便观察不同条件下的应用性能。如下图所示是WAS的设置界面。
|
|
|
|
|
|
|
|
Stress Level和Stress Multiplier这两项决定了访问服务器的并发连接的数量。如果要模拟的并发连接数量超过100个，可以调整Stress multiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客户机协调。有关在测试中使用多个客户机的更多信息，参见http://webtool.rte.microsoft.com/kb/hkb13.htm。
|
|
|
|
如果网站提供个性化服务，要进行身份验证或使用Cookies，我们还要为WAS提供一个用户目录。WAS中的用户存储了发送给服务器的密码以及服务器发送给客户端的Cookies。增加用户数量并不增加Web服务器的负载。必须提供足够数量的用户以满足并发连接的要求（Stress Level乘以Stress Multiplier）。有关线程、用户和Cookies相互作用的更多信息请参见http://webtool.rte.microsoft.com/Threads/WASThreads.htm。
|
|
|
|
WAS允许设置warmup（热身）时间，一般可以设置为1分钟。在warmup期间WAS开始执行脚本，但不收集统计数据。warmup时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结果。
|
|
|
|
设置页面提供的另外一个有用的功能是限制带宽（throttle bandwidth）。带宽限制功能能够为测试模拟出Modem（14.4K, 28.8K, 56K）、ISDN（64K，128K）以及T1（1.54M）的速度。使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问Web服务器所感受的性能。
|
|
|
|
要理解这些不同的设置对应用的影响，有必要了解如何使用WAS收集性能数据。
|
|
|
|
使用WAS，从远程Windows NT和Windows 2000机器获取和分析性能计数器（Performance Counter）是很方便的。加入计数器要用到如下图所示的Perf Counters分支。
|
|
|
|
|
|
|
|
在测试中选择哪些计数器显然跟测试目的有关。虽然下面这个清单不可能精确地隔离出性能瓶颈所在，但对一般的Web服务器性能测试来说却是一个好的开始。
|
|
|
|
①处理器：CPU使用百分比（% CPU Utilization）；
|
|
|
|
②线程：每秒的上下文切换次数（Context Switches Per Second（Total））；
|
|
|
|
③ASP：每秒请求数量（Requests Per Second）；
|
|
|
|
④ASP：请求执行时间（Request Execution Time）；
|
|
|
|
⑤ASP：请求等待时间（Request Wait Time）；
|
|
|
|
⑥ASP：置入队列的请求数量（Requests Queued）。
|
|
|
|
CPU使用百分比反映了处理器开销。CPU使用百分比持续地超过75%是性能瓶颈存在于处理器的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。如果处理器陷于每秒数千次的上下文切换，说明它忙于切换线程而不是处理ASP脚本。
|
|
|
|
每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。每秒的请求数量表示每秒内服务器成功处理的ASP请求数量。执行时间和等待时间之和显示了反应时间，这是服务器用处理好的页面作应答所需要的时间。
|
|
|
|
可以绘出随测试中并发用户数量的增加，每秒请求数量和反应时间的变化图。增加并发用户数量时每秒请求数量也会增加。然而，我们最终会达到这样一个点，此时并发用户数量开始“压倒”服务器。如果继续增加并发用户数量，每秒请求数量开始下降，而反应时间则会增加。要搞清楚硬件和软件的能力，找出这个并发用户数量开始“压倒”服务器的临界点非常重要。
|
|
|
|
置入队列的ASP请求数量也是一个重要的指标。如果在测试中这个数量有波动，某个COM对象所接收到的请求数量超过了它的处理能力。这可能是因为在应用的中间层使用了一个低效率的组件，或者在ASP会话对象中存储了一个单线程的单元组件。
|
|
|
|
运行WAS的客户机CPU使用率也有必要监视。如果这些机器上的CPU使用率持续地超过75%，说明客户机没有足够的资源来正确地运行测试，此时应该认为测试结果不可信。在这种情况下，测试客户机的数量必须增加，或者减小测试的Stress Level。
|
|
|
|
每次测试运行结束后WAS会生成详细的报表，即使测试被提前停止也一样。WAS报表可以从View菜单选择Reports查看。下面介绍一下报表中几个重要的部分。
|
|
|
|
如果这是一个新创建的测试脚本，你应该检查一下报表的Result Codes部分。这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了404代码（页面没有找到），说明在脚本中有错误的页面请求。
|
|
|
|
页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（TTFB），接收到最后一个字节的平均时间（TTLB），以及测试脚本中各个页面的命中次数。TTFB和TTLB这两个值对于计算客户端所看到的服务器性能具有重要意义。TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以毫秒计），TTLB包含了TTFB，它是客户机接收到页面最后一个字节所需要的累计时间。
|
|
|
|
报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍的内容。为了给你一个有关报表所提供信息种类的印象，摘录了一个报表实例如下图所示。
|
|
|
|
|
|
|
|
. SILK PERFORMER V——美国Segue公司。
|
|
|
|
|
|
|
|
②脚本采用PASCAL，资源消耗较小，支持一些底层访问。
|
|
|
|
|
|
|
|
|
|
协议这个概念大家并不陌生，测试工具中的“协议”指的是工具提供给我们的测试接口，也可以理解为测试类型。LoadRunner提供的测试协议比较全面，例如：
|
|
|
|
|
|
. Client/Server：MS SQL, ODBC, Oracle（2-tier）, DB2 CLI, Sybase Ctlib, Sybase Dblib, Windows Sockets及DNS。
|
|
|
|
. 定制：C templates, Visual Basic templates, Java templates, JavaScript及VBScript。
|
|
|
|
. 分布式组件：COM/DCOM, Corba-Java及Rmi-Java。
|
|
|
|
. E-business: FTP, LDAP, Palm, SOAP, Web (HTTP/HTML)，及the dual Web/Winsocket。
|
|
|
|
. Enterprise Java Beans：EJB Testing及Rmi-Java。
|
|
|
|
. ERP/CRM：Baan, Oracle NCA, Peoplesoft-Tuxedo, Peoplesoft 8 Web multilingual, SAPGUI, SAP-Web, Siebel (Siebel-DB2CLI, Siebel-MSSQL, Siebel-Web及Siebel-Oracle)。
|
|
|
|
. Legacy：Terminal Emulation (RTE)。
|
|
|
|
. Mailing Services: Internet Messaging (IMAP), MS Exchange (MAPI), POP3及SMTP。
|
|
|
|
. Middleware: Jacada及Tuxedo (6, 7)。
|
|
|
|
. Streaming: MediaPlayer及RealPlayer。
|
|
|
|
. Wireless: i-Mode, VoiceXML及WAP。
|
|
|
|
这里我们要重点讨论的问题是选择测试协议的策略。一个原则性的观点是“客户端与直接压力承受的服务器之间的通信协议是选择测试协议的惟一标准”。例如，有的测试工程师问“我们的系统是B/S运行模式，应该选择什么样的测试协议来测”，我们说这是一个无效问题，为什么呢？从这个问题中我们不能获取任何与通信协议有关的信息，B/S运行模式可以采用http协议，也可以采用TCP/IP, SMTP、FTP等协议，C/S运行模式也是这个道理。选择不同的协议决定了测试的成功与失败。理论知识要适用于实践，必须活学活用。再例如，一个使用非常普遍的系统：B/S运行模式，前端IE浏览器，IE浏览器直接与Web服务器通信（可能多台），Web服务器与后台数据库服务器（可能多台）有数据交互操作，IE浏览器与Web服务器的通信协议采用http，那么，理所当然我们选择的测试协议是http；再灵活一些，如果IE浏览器与Web服务器的通信不仅采用了http协议，而且还有部分业务采用Winsocket，那么必须选择Web/Winsocket双协议；更进一步，有些系统客户端是C/S运行模式和B/S运行模式的混合，为了达到测试目的，就要选择更多的测试协议。可喜的是LoadRunner 7.8版本以后已经能够帮你实现这个愿望了。再来看一种情况：系统的架构是客户端应用程序+Tuxedo消息中间件（或者是其他中间件）+数据库服务器。遇到这种情况，我们一般会选择Tuxedo测试协议，能够有这样的定位选择，BEA公司的产品Tuxedo的市场占有率给测试工具厂商带来的压力显而易见。还要跟大家介绍一种普遍认为最“惨”，也最“酷”的方法，就是利用测试工具提供的编程语言自己编写测试脚本，测试工具提供的使用广泛的测试脚本是CScript、JavaScript及VBScript。但提醒大家的是，要做到真实模拟负载，和相关开发人员的交流至关重要。
|
|
|
|
|
|
|
|
实施负载压力测试时，需要运行系统相关业务，这时需要一些数据支持才可运行业务，这部分数据即为初始测试数据。例如ERP软件运行前财务账套的准备。
|
|
|
|
在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例。在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程领域时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。
|
|
|
|
对系统实施负载压力测试的时候，经常会需要准备大数据量、实施独立的测试，或者与并发负载压力相结合的性能测试，这部分数据为业务测试数据。例如飞机订票系统查询订票信息，就需要准备大量的订票记录。又比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量，以及数据的种类应能覆盖全部业务。
|
|
|
|
在负载压力测试过程中，为了模拟不同的虚拟用户的真实负载，需要将一部分业务数据参数化，这部分数据为参数化测试数据。例如模拟不同用户登录系统，就需要准备大量用户名及相应密码参数数据。
|
|
|
|
还需要考虑特殊系统需要的测试数据，模拟真实环境测试，有些软件特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。
|
|
|
|
|
|
|
|
|
|
|
|
. 初始数据提供了一个基线用来评估测试执行的结果；
|
|
|
|
|
|
|
|
|
|
在8.2.3小节，介绍了依靠工具准备测试数据的方法。
|
|
|
|
|
|
下面通过列举两个实例，来了解自己动手编写测试工具的思路。
|
|
|
|
|
|
这个系统不仅能够测试静态HTML页面的响应时间，而且能够模拟真实运行情况测试动态网页（包括ASP、PHP、JSP等）的响应时间，为服务器的性能优化和调整提供数据依据。
|
|
|
|
为了能够模拟大量用户同时访问Web动态页面的情况，必须要解决下面两个问题：
|
|
|
|
. 测试工具需要模拟出大量用户同时访问Web的情况；
|
|
|
|
. 测试工具需要模拟出单个用户访问Web时个性化的请求参数。
|
|
|
|
本性能测试系统主要由两部分构成：性能测试数据文件和性能测试程序。其中，性能测试数据文件包含着用户访问Web的URL请求格式和大量用户访问系统的请求数据（例如用户名和密码等）。实际测试中，性能测试程序将开设多个进程模拟大量用户对Web的访问，每个进程从性能测试数据文件中随机地读出一组访问数据，然后发起对Web服务器的访问，等待Web服务器应答。测试结束后，性能测试程序将给出对于所有请求的平均系统响应时间。由此，本性能测试工具能够真实地模拟大量用户同时访问Web的情况。
|
|
|
|
在实际运行的Web应用系统中，用户访问动态页面时传递的query字符串中的参数是互不相同的。为了逼真地模拟实际情况，性能测试系统应该在一段特定的时间内，对待测页面同时发送多个请求，每个请求的query参数互不相同，在发送的同时开始计时，直到收到系统的响应，计时停止，最后对所有请求的响应时间进行分析，就可以得到系统性能的定量估计。系统结构如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
模板文件为纯文本文件，包含单个用户访问Web发送的URL，每行格式如下：
|
|
|
|
GET（POST）http://host:port/path/filename?xxx=@1@&@2@
|
|
|
|
其中GET或者POST表示参数传递的方式，query字符串中的@是本系统特设字符，表示@及其后面的数字需要被数据文件中对应的参数数据所取代。两个@之间为参数序号，只能为数字，在整个模板文件中相同的参数序号代表相同的参数。
|
|
|
|
数据文件是用户访问动态页面时传递的query参数集合，为纯文本文件，参数数据与模板文件中@号及其后面的数字相对应，之间用空格隔开，每组一行。
|
|
|
|
测试Web应用系统时，性能测试程序将开设c个进程，每个进程可以串行地开设n个会话，每个会话模拟一个真实用户，按照模板文件中提供的访问Web系统的格式，从数据文件中读取一组query参数，然后对Web系统发起请求；与此同时，程序开始计时，直到收到系统的响应，计时停止，系统统计接收的字节数，将结果写入结果文件，本次会话结束，这个进程开始一个新的会话，如此循环n次。测试结束后，结果处理程序对结果文件中每个请求的响应时间进行统计分析，给出系统的综合性能评估。
|
|
|
|
从上面的分析可以看出，本系统发送请求的并发度是c，即在测试的时间段内，对Web应用系统同时发送的请求有c个；本系统发送请求的串行度为n，一共可以模拟c×n个用户对系统的访问。
|
|
|
|
|
|
如下图所示，性能测试程序fork出c个进程，每个进程都开设一个Socket，通过Socket向Web服务器发送请求。为了使测试程序能够快速地向服务器发送请求，程序一开始就将数据文件中的所有数据读入内存，数据使用一个二维数组存放。
|
|
|
|
|
|
|
|
模板文件中的请求格式在程序开始时读入模板数据结构中，模板数据结构定义如下：
|
|
|
|
|
|
测试程序运行结束后，生成的结果文件包含着Web服务器对每个请求的响应时间，还包含每个请求返回的字节数。结果文件由结果处理程序处理，计算出Web服务器对所有请求的平均响应时间。
|
|
|
|
|
|
大家知道LoadRunner通过运行脚本模拟的方法仍然与应用系统的实际处理逻辑存在一定的差异，因此其评测结果与应用系统实际使用过程中的性能指标之间仍然存在一定的差距。为了弥补这个缺陷，需要一种适用于特定应用的运行模拟和性能评测方法与支撑环境，来对应用系统的实际性能评测提供有效支持。这里提出的通用应用系统性能评测环境，是通过并行执行分布于不同客户机上的多种类型的实际应用程序代码，模拟一个应用系统在多个客户端并发访问情况下的实际运行情况，同时对应用程序代码的执行状态和结果等信息进行记录；在模拟执行完成之后，对执行记录进行分析，给出被测系统的性能指标。应用系统性能评测环境主要由应用逻辑运行模拟代理（PexpAgent）、模拟控制中心（PexpCmdCenter）、数据搜集器（Data Collector）和统计分析工具等部分组成，其系统结构如下图所示。其中，应用逻辑运行模拟代理负责驱动执行被测系统的应用逻辑代码，并记录每一次执行的状态和性能相关信息。模拟控制中心负责控制整个性能评测过程中的所有运行模拟代理。数据搜集器负责在测量完成之后，接收来自运行模拟代理的性能测量数据。统计分析工具负责对测量获得的性能相关数据进行分析，从而得出被测系统的相关性能数据。在评测过程中，运行模拟代理与控制中心之间通过基于对象传输的专用网络通信接口（Performance Network）进行通信；由于应用系统的实际运行环境各异，评测系统被设计成能够运行在多种操作系统平台上，所有其他组件的下层是操作系统相关调用抽象层，对于不同的操作系统平台，需要实现相应的实际处理对象。
|
|
|
|
|
|
|
|
由于我们的目的是通过模拟真实的并发环境来获取系统的实际性能，在设计与实现上需要充分考虑如下问题，并加以解决：
|
|
|
|
. 应用系统实际处理代码的嵌入方式和响应时间的测定；
|
|
|
|
|
|
|
|
|
|
|
|
做为第三方测试机构，在负载压力测试准备的过程中，经常需要与用户交流，那么交流哪些内容呢？概括如下。
|
|
|
|
|
|
. 系统运行的硬件环境和软件环境，包括客户端、中间件、Web服务器、应用服务器、数据库服务器等；
|
|
|
|
|
|
|
|
|
|
|
|
|
