发布新日志

  • 摘录:播布客-loadrunner教学视频汇总

    2009-01-07 10:10:04

    小歪作品:

    LoadRunner关联函数---http://www.boobooke.com/v/bbk1586

    LoadRunner参数化之研究---http://www.boobooke.com/v/bbk1617

     

     

    雪鹰作品:

    LoadRunnerWeb检查点两个函数剖析(1/2)---  http://www.boobooke.com/v/bbk1333

    LoadRunnerWeb检查点两个函数剖析(2/2)--- http://www.boobooke.com/v/bbk1334

    LoadRunner中编写ftp测试脚本---  http://www.boobooke.com/v/bbk1349

     

    小强作品:

    1 性能测试常见用语

    http://www.boobooke.com/v/bbk1577/

    2 lr常用术语

    http://www.boobooke.com/v/bbk1620

    3 lr目录分析

    http://www.boobooke.com/v/bbk1574

    3.1——3.3lr界面分析

    http://www.boobooke.com/v/bbk1735  VuGen

    http://www.boobooke.com/v/bbk1736  Controller

    http://www.boobooke.com/v/bbk1737  Analysis

    5 hp web tours网站分析

    http://www.boobooke.com/v/bbk1762

    6 lr录制测试脚本

    http://www.boobooke.com/v/bbk1763/

    7 lr回放测试脚本

    http://www.boobooke.com/v/bbk1764/

    8 htmlurl比较

    http://www.boobooke.com/v/bbk1771

    9 lr自动关联

    http://www.boobooke.com/v/bbk1778

    10 java虚拟用户

    http://www.boobooke.com/v/bbk1901

    11 初识lr动态链接库

    http://www.boobooke.com/v/bbk1900/

    12 lr录制sql脚本

    http://www.boobooke.com/v/bbk1526/

    13 性能分析基础知识

    14.LoadRunner脚本编写规范---http://www.boobooke.com/v/bbk1781/

    15.LoadRunner运行时刻设置---http://www.boobooke.com/v/bbk1782/

    16.LoadRunner之错误处理---http://www.boobooke.com/v/bbk1776  lr_continue_on_error

    17. LoadRunner之脚本调试---http://www.boobooke.com/v/bbk1777

    18. LoadRunner测试脚本的增强方法---http://www.boobooke.com/v/bbk1772

  • LoadRunner监控Windows/Unix系统资源的配置

    2008-12-22 11:16:12

    LoadRunner监控Windows/Unix系统资源的配置

    2008-12-22 11:12:46

    LoadRunner监控Windows/Unix系统资源需要做两件事情:

      1、配置被监视的服务器,以便于LoadRunner能够获取系统资源使用情况的数据

      2、在LoadRunner的Controller中添加计数器

      添加计数器比较简单,这里主要讲如何配置Windows/Unix服务器。

      一、配置UNIX系统:

      1、 修改/etc/xinetd.d/下的三个conf文件 rlogin , rsh ,rexec 这三个配置文件,把这三个文件里的disable =yes都改成 disable = no ( disabled 用在默认的 {} 中 禁止服务),或是把# default: off都设置成 on 这个的意思就是在xinetd启动的时候默认都启动上面的三个服务。

      2、 执行: rpc.rstatd

      3、 检查是否启动rstatd,输入命令: rpcinfo –p。如果能看到:

      程序 版本 协议 端口

      *** **** udp 741 rstatd

      那就说明rstatd服务启动了

      4、 LR中添加计算器

      如果系统没有安装rstatd的话,上面的操作将会不成功,需要先安装rstatd,安装rstatd过程很简单:

      1、从安装光盘或网上找到安装文件(一般是rstatd***.tar.gz)

      2、解压缩安装包:

      tar xzvf rstatd***.tar.gz

      3、进入源文件目录运行配置文件和编译:

      $ ./configure

      $ make

      $ make install

      安装好之后,就按上面的步骤启动rstatd即可。

      (说明:以上的操作需要root用户权限)

      二、配置windows系统

      1、 保证被监视的windows系统开启以下二个服务:Remote Procedure Call(RPC) 和Remote Registry Service

      2、 获得对远程计算机的管理权限,请在命令提示符(运行cmd命令)下执行以下命令:

      net use \\<计算机名>/用户:[<域>\<远程计算机名>]

      提示输入密码时,输入远程计算机的密码。

      例如:

      net use \\192.168.18.67 administrator

      net use \\192.168.18.67 /user:administrator

      如果提示错误,则不加用户名:

      net use \\192.168.18.67

      需要用户名和密码的话,系统会提示输入用户名和密码,按提示做即可。

      如果看到“命令成功完成”的提示,则说明配置成功了。

  • LR中监控ORACLE数据库常用计数器(如何自定义Oracle计数器)(转自jzl2004 )

    2008-12-22 11:12:46

    一、添加自定义计数器的方法

          要创建自定义查询,请执行以下操作:
    1.        在安装路径的Mercury LoadRunner\dat\monitors找到vmon.cfg文件,打开。
    2.        在vmon.cfg文件的第三行中,CustomCounters=指出要创建的自定义计数器个数。
    3.        在vmon.cfg文件中为新计数器新建一节,每节都有以下格式:
         [Custom0]
         Name=Five Hundred
    Descrīption=This counter always returns 500.
    Query=SELECT 500 FROM DUAL
    IsRate=0
    4.        在[Custom#]行,将计数器顺序中的下一个数字分配给新的自定义计数器。
    注意:自定义计数器必须是以数字0开始的联系顺序。
    5.        在Name行,输入新计数器的名称(可以输入中文)。
    6.        在Descrīption行,输入对该计数器的描述或解释(可以输入中文)。
    7.        在Query行,输入恰好返回数据库一行的SQL查询的文本,该行必须包含一列数值。
    注意:自定义查询文本不能够超过512字符。
    8.        在IsRate行,如果希望数据库将计数器报告为一个绝对值,请输入0;如果希望数
    据库报告每单位时间计数器的更改,请输入1。
    注意:自定义查询无法返回负值。
      
    例:
    [Custom0]
    ;Name must be unique
    Name=库快存命中率
    Descrīption=该计数器返回当前库快存命中率
    Query=SELECT 100*((sum(pins-reloads))/sum(pins)) from v$librarycache
    IsRate=0


    3        配置文件示例对象
    安装路径的Mercury LoadRunner\dat\monitors找到vmon.cfg文件:

    V$ Monitor]
    Counters=150
    CustomCounters=12
    ;How many seconds for each data sample?
    SamplingRate=10

    [Custom0]
    ;Name must be unique
    Name=库快存命中率
    Descrīption=该计数器返回当前库快存命中率
    Query=SELECT 100*((sum(pins-reloads))/sum(pins)) from v$librarycache
    IsRate=0

    [Custom1]
    ;Name must be unique
    Name=高速缓存区命中率
    Descrīption=oracle database shoot straight
    Query=SELECT round(1-SUM(PHYSICAL_READS)/(SUM(DB_BLOCK_GETS) + SUM(CONSISTENT_GETS)), 4) * 100 FROM (SELECT CASE WHEN NAME='physical reads' THEN VALUE END PHYSICAL_READS,CASE WHEN NAME = 'db block gets' THEN VALUE END  DB_BLOCK_GETS,CASE WHEN NAME = 'consistent gets' THEN VALUE END  CONSISTENT_GETS FROM V$SYSSTAT WHERE Name IN ('physical reads','db block gets','consistent gets'))
    IsRate=0

    [Custom2]
    ;Name must be unique
    Name=共享区库缓存区命中率
    Descrīption=命中率应大于0.99
    Query=Select round(sum(pins-reloads)/sum(pins) * 100, 2) from v$librarycache
    IsRate=0

    [Custom3]
    ;Name must be unique
    Name=共享区字典缓存区命中率
    Descrīption=命中率应大于0.85
    Query=Select round(sum(gets-getmisses-usage-fixed)/sum(gets) * 100, 2) from v$rowcache
    IsRate=0

    [Custom4]
    ;Name must be unique
    Name=检测回滚段的争用
    Descrīption=应该小于1%
    Query=select round(sum(waits)/sum(gets) * 100, 2) from v$rollstat
    IsRate=0

    [Custom5]
    ;Name must be unique
    Name=检测回滚段收缩次数
    Descrīption=应该小于1%
    Query=select sum(shrinks) from v$rollstat, v$rollname where v$rollstat.usn = v$rollname.usn
    IsRate=0

    [Custom6]
    ;Name must be unique
    Name=监控表空间的I/O读总数
    Descrīption=监控表空间的I/O
    Query=select sum(f.phyrds) pyr from v$filestat f, dba_data_files df where f.file# = df.file_id
    IsRate=0

    [Custom7]
    ;Name must be unique
    Name=监控表空间的I/O块读总数
    Descrīption=监控表空间的I/O
    Query=select sum(f.phyblkrd) pbr from v$filestat f, dba_data_files df where f.file# = df.file_id
    IsRate=0

    [Custom8]
    ;Name must be unique
    Name=监控表空间的I/O写总数
    Descrīption=监控表空间的I/O
    Query=select sum(f.phywrts) pyw from v$filestat f, dba_data_files df where f.file# = df.file_id
    IsRate=0
    .
    .
    .
    .
    .
    (以上为12个自定义的计数器,以下为LR工具自带的计数器)

    [0]
    Name=CPU used by this session
    Descrīption=This is the amount of CPU time (in 10s of milliseconds) used by a session between when a user call started and ended. Some user calls can complete within 10 milliseconds and as a result, the start and end user-call time can be the same. In this case, 0 milliseconds are added to the statistic. A similar problem can exist in the reporting by the operating system, especially on systems that suffer from many context switches.
    IsRate=0

    [1]
    Name=CPU used when call started
    Descrīption=The CPU time used when the call is started.
    IsRate=0
    .
    .
    .
    .


    二、常用自定义计数器列表

    序号        监控名称        SQL算法        说明
    1、   数据高速缓存区命中率        SELECT round(1-SUM(PHYSICAL_READS)/(SUM(DB_BLOCK_GETS) + SUM(CONSISTENT_GETS)), 4) * 100 FROM (SELECT CASE WHEN NAME='physical reads' THEN VALUE END PHYSICAL_READS,CASE WHEN NAME = 'db block gets' THEN VALUE END  DB_BLOCK_GETS,CASE WHEN NAME = 'consistent gets' THEN VALUE END  CONSISTENT_GETS FROM V$SYSSTAT WHERE Name IN ('physical reads','db block gets','consistent gets'))        (监控 SGA 的命中率)命中率应大于0.90最好

    2、   库快存命中率        SELECT 100*((sum(pins-reloads))/sum(pins)) from v$librarycache        该计数器返回当前库快存命中率

    3 、  共享区库缓存区命中率        Select round(sum(pins-reloads)/sum(pins) * 100, 2) from v$librarycache        (监控 SGA 中共享缓存区的命中率)命中率应大于0.99

    4、   监控 SGA 中字典缓冲区的命中率        Select round(sum(gets-getmisses-usage-fixed)/sum(gets) * 100, 2) from v$rowcache        (共享区字典缓存区命中率)命中率应大于0.85

    5、   检测回滚段的争用        select round(sum(waits)/sum(gets) * 100, 2) from v$rollstat        小于1%

    6、   检测回滚段收缩次数        select sum(shrinks) from v$rollstat, v$rollname where v$rollstat.usn = v$rollname.usn       

    7、   监控表空间的 I/O读总数        select sum(f.phyrds) pyr from v$filestat f, dba_data_files df where f.file# = df.file_id        监控表空间的 I/O

    8、    监控表空间的 I/O块读总数        select sum(f.phyblkrd) pbr from v$filestat f, dba_data_files df where f.file# = df.file_id        监控表空间的 I/O

    9、    监控表空间的 I/O写总数        select sum(f.phywrts) pyw from v$filestat f, dba_data_files df where f.file# = df.file_id        监控表空间的 I/O

    10、  监控表空间的 I/O块写总数        select sum(f.phyblkwrt) pbw  from v$filestat f, dba_data_files df where f.file# = df.file_id        监控表空间的 I/O

    11、   监控 SGA 中重做日志缓存区的命中率        SELECT Decode(immediate_gets+immediate_misses,0,0,immediate_misses/(immediate_gets+immediate_misses)*100) ratio2 FROM v$latch WHERE name IN ('redo copy')        应该小于1%

    12、   监控内存和硬盘的排序比率        select round(sum(case when name='sorts (disk)' then value else 0 end) / sum(case when name='sorts (memory)' then value else 0 end)*100,2) from (SELECT  name, value FROM v$sysstatWHERE name IN ('sorts (memory)', 'sorts (disk)'))        最好使它小于 10%
  • 性能测试

    2008-12-22 11:12:46

    性能测试


          性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。 

    一、概述

          性能测试在软件的质量保证中起着重要的作用,它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面:应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下,三方面有效、合理的结合,可以达到对系统性能全面的分析和瓶颈的预测。

        ·应用在客户端性能的测试

      应用在客户端性能测试的目的是考察客户端应用的性能,测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等,其中并发性能测试是重点。

          并发性能测试是重点

      并发性能测试的过程是一个负载测试和压力测试的过程,即逐渐增加负载,直到系统的瓶颈或者不能接收的性能点,通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试(Load Testing)是确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统组成部分的相应输出项,例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用,从而来确定能够接收的性能过程。压力测试(Stress Testing)是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。

      并发性能测试的目的主要体现在三个方面:以真实的业务为依据,选择有代表性的、关键的业务操作设计测试案例,以评价系统的当前性能;当扩展应用程序的功能或者新的应用程序将要被部署时,负载测试会帮助确定系统是否还能够处理期望的用户负载,以预测系统的未来性能;通过模拟成百上千个用户,重复执行和运行测试,可以确认性能瓶颈并优化和调整应用,目的在于寻找到瓶颈问题。

      当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来,用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。

          举例说明:电信计费软件

      众所周知,每月20日左右是市话交费的高峰期,全市几千个收费网点同时启动。收费过程一般分为两步,首先要根据用户提出的电话号码来查询出其当月产生费用,然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤,但当成百上千的终端,同时执行这样的操作时,情况就大不一样了,如此众多的交易同时发生,对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力, 预见软件的并发承受力, 这是在软件测试阶段就应该解决的问题。

      目前,大多数公司企业需要支持成百上千名用户,各类应用环境以及由不同供应商提供的元件组装起来的复杂产品,难以预知的用户负载和愈来愈复杂的应用程序,使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。

      如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作,然后拿秒表记录下反应时间? 这样的手工作坊式的测试方法不切实际,且无法捕捉程序内部变化情况,这样就需要压力测试工具的辅助。

      测试的基本策略是自动负载测试,通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景,对应用程序进行测试,同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能,确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。

          并发性能测试前的准备工作

      测试环境:配置测试环境是测试实施的一个重要阶段,测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境,硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境;软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

      一个充分准备好的测试环境有三个优点:一个稳定、可重复的测试环境,能够保证测试结果的正确;保证达到测试执行的技术需求;保证得到正确的、可重复的以及易理解的测试结果。

      测试工具:并发性能测试是在客户端执行的黑盒测试,一般不采用手工方式,而是利用工具采用自动化方式进行。目前,成熟的并发性能测试工具有很多,选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具,通过可重复的、真实的测试,能够彻底地度量应用的可扩展性和性能,可以在整个开发生命周期、跨越多种平台、自动执行测试任务,可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。

      测试数据:在初始的测试环境中需要输入一些适当的测试数据,目的是识别数据状态并且验证用于测试的测试案例,在正式的测试开始以前对测试案例进行调试,将正式测试开始时的错误降到最低。在测试进行到关键过程环节时,非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来,需要的时候恢复它,初始数据提供了一个基线用来评估测试执行的结果。

      在测试正式执行时,还需要准备业务测试数据,比如测试并发查询业务,那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。

      模拟真实环境测试,有些软件,特别是面向大众的商品化软件,在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时,硬盘上布置的不同类型文件的比例要尽量接近真实环境,这样测试出来的数据才有实际意义。

          并发性能测试的种类与指标

      并发性能测试的种类取决于并发性能测试工具监控的对象,以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java scrīpt等不同的监控对象,支持Windows和UNIX测试环境。

      最关键的仍然是测试过程中对监控对象的灵活应用,例如目前三层结构的运行模式广泛使用,对中间件的并发性能测试作为问题被提到议事日程上来,许多系统都采用了国产中间件,选择Java scrīpt监控对象,手工编写脚本,可以达到测试目的。

      采用自动化负载测试工具执行的并发性能测试,基本遵循的测试过程有:测试需求与测试内容,测试案例制定,测试环境准备,测试脚本录制、编写与调试,脚本分配、回放配置与加载策略,测试执行跟踪,结果分析与定位问题所在,测试报告与测试评估。

      并发性能测试监控的对象不同,测试的主要指标也不相同,主要的测试指标包括交易处理性能指标和 UNIX资源监控。其中,交易处理性能指标包括交易结果、每分钟交易数、交易响应时间(Min:最小服务器响应时间;Mean:平均服务器响应时间;Max:最大服务器响应时间;StdDev:事务处理服务器响应的偏差,值越大,偏差越大;Median:中值响应时间;90%:90%事务处理的服务器响应时间)、虚拟并发用户数。

          应用实例:“新华社多媒体数据库 V1.0”性能测试

      中国软件评测中心(CSTC)根据新华社技术局提出的《多媒体数据库(一期)性能测试需求》和GB/T 17544《软件包质量要求和测试》的国家标准,使用工业标准级负载测试工具对新华社使用的“新华社多媒体数据库 V1.0”进行了性能测试。

      性能测试的目的是模拟多用户并发访问新华社多媒体数据库,执行关键检索业务,分析系统性能。

      性能测试的重点是针对系统并发压力负载较大的主要检索业务,进行并发测试和疲劳测试,系统采用B/S运行模式。并发测试设计了特定时间段内分别在中文库、英文库、图片库中进行单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中文库中并发用户数200,进行测试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时,监测的测试指标包括交易处理性能以及 UNIX(Linux)、Oracle、Apache资源等。

      测试结论:在新华社机房测试环境和内网测试环境中,100M带宽情况下,针对规定的各并发测试案例,系统能够承受并发用户数为200的负载压力,最大交易数/分钟达到78.73,运行基本稳定,但随着负载压力增大,系统性能有所衰减。

      系统能够承受200并发用户数持续周期约8小时的疲劳压力,基本能够稳定运行。

      通过对系统UNIX(Linux)、Oracle和Apache资源的监控,系统资源能够满足上述并发和疲劳性能需求,且系统硬件资源尚有较大利用余地。

      当并发用户数超过200时,监控到HTTP 500、connect和超时错误,且Web服务器报内存溢出错误,系统应进一步提高性能,以支持更大并发用户数。

      建议进一步优化软件系统,充分利用硬件资源,缩短交易响应时间。

          疲劳强度与大数据量测试

      疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数,持续执行一段时间业务,通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

      疲劳强度测试可以采用工具自动化的方式进行测试,也可以手工编写程序测试,其中后者占的比例较大。

      一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试,获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行,则及时调整测试指标,例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估,用系统正常业务情况下并发用户数为基础,进行一定时间的疲劳测试。

      大数据量测试可以分为两种类型:针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试;与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备,可以依靠工具准备测试数据。

      速度测试目前主要是针对关键有速度要求的业务进行手工测速度,可以在多次测试的基础上求平均值,可以和工具测得的响应时间等指标做对比分析。

          ·应用在网络上性能的测试

      应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

          网络应用性能分析

      网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具,例如Application Expert,能够发现应用的瓶颈,我们可知应用在网络上运行时在每个阶段发生的应用行为,在应用线程级分析应用的问题。可以解决多种问题:客户端是否对数据库服务器运行了不必要的请求?当服务器从客户端接受了一个查询,应用服务器是否花费了不可接受的时间联系数据库服务器?在投产前预测应用的响应时间;利用Application Expert调整应用在广域网上的性能;Application Expert能够让你快速、容易地仿真应用性能,根据最终用户在不同网络配置环境下的响应时间,用户可以根据自己的条件决定应用投产的网络环境。

          网络应用性能监控

      在系统试运行之后,需要及时准确地了解网络上正在发生什么事情;什么应用在运行,如何运行;多少PC正在访问LAN或WAN;哪些应用程序导致系统瓶颈或资源竞争,这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具,可以达到事半功倍的效果,在这方面我们可以提供的工具是Network Vantage。通俗地讲,它主要用来分析关键应用程序的性能,定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽,哪些用户产生了最大的网络流量,这个工具同样能满足要求。

          网络预测

      考虑到系统未来发展的扩展性,预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到:设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。

      从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息(若没有这类软件可人工生成流量数据),这样可以得到现有网络的基本结构。在基本结构的基础上,可根据网络结构的变化、网络流量的变化生成报告和图表,说明这些变化是如何影响网络性能的。 PREDICTOR提供如下信息:根据预测的结果帮助用户及时升级网络,避免因关键设备超过利用阀值导致系统性能下降;哪个网络设备需要升级,这样可减少网络延迟、避免网络瓶颈;根据预测的结果避免不必要的网络升级。

          ·应用在服务器上性能的测试

      对于应用在服务器上性能的测试,可以采用工具监控,也可以使用系统本身的监控命令,例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控,测试原理如下图。

    UNIX资源监控指标和描述

      监控指标 描述
      平均负载 系统正常状态下,最后60秒同步进程的平均个数
      冲突率 在以太网上监测到的每秒冲突数
      进程/线程交换率 进程和线程之间每秒交换次数
      CPU利用率 CPU占用率(%)
      磁盘交换率 磁盘交换速率
      接收包错误率 接收以太网数据包时每秒错误数
      包输入率 每秒输入的以太网数据包数目
      中断速率 CPU每秒处理的中断数
      输出包错误率 发送以太网数据包时每秒错误数
      包输入率 每秒输出的以太网数据包数目
      读入内存页速率 物理内存中每秒读入内存页的数目
      写出内存页速率 每秒从物理内存中写到页文件中的内存页数
       目或者从物理内存中删掉的内存页数目
      内存页交换速率 每秒写入内存页和从物理内存中读出页的个数
      进程入交换率 交换区输入的进程数目
      进程出交换率 交换区输出的进程数目
      系统CPU利用率 系统的CPU占用率(%)
      用户CPU利用率 用户模式下的CPU占用率(%)
      磁盘阻塞 磁盘每秒阻塞的字节数

    二、为什么进行性能测试?

          目的是验证软件系统是否能够达到用户提出的性能指标,同时发现软件系统中存在的性能瓶颈,优化软件,最后起到优化系统的目的。

          包括以下几个方面

    1.评估系统的能力,测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力,并帮助作出决策。
    2.识别体系中的弱点:受控的负荷可以被增加到一个极端的水平,并突破它,从而修复体系的瓶颈或薄弱的地方。
    3.系统调优:重复运行测试,验证调整系统的活动得到了预期的结果,从而改进性能。
    检测软件中的问题:长时间的测试执行可导致程序发生由于内存泄露引起的失败,揭示程序中的隐含的问题或冲突。
    4.验证稳定性(resilience)可靠性(reliability):在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

          性能测试类型包括负载测试,强度测试,容量测试等

          负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。

          强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。

          容量测试:确定系统可处理同时在线的最大用户数  

          观察指标:

          性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。

          在实际中作中我们经常会对两种类型软件进行测试:bs和cs,这两方面的性能指标一般需要哪些内容呢?

    Bs结构程序一般会关注的通用指标如下(简):

    Web服务器指标指标:

    * Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数;

    * Avg time to last byte per terstion (mstes):平均每秒业务角本的迭代次数 ,有人会把这两者混淆;

    * Successful Rounds:成功的请求;

    * Failed Rounds :失败的请求;

    * Successful Hits :成功的点击次数;

    * Failed Hits :失败的点击次数;

    * Hits Per Second :每秒点击次数;

    * Successful Hits Per Second :每秒成功的点击次数;

    * Failed Hits Per Second :每秒失败的点击次数;

    * Attempted Connections :尝试链接数;

    CS结构程序,由于一般软件后台通常为数据库,所以我们更注重数据库的测试指标:

    * User 0 Connections :用户连接数,也就是数据库的连接数量;

    * Number of deadlocks:数据库死锁;

    * Butter Cache hit :数据库Cache的命中情况

          当然,在实际中我们还会察看多用户测试情况下的内存,CPU,系统资源调用情况。这些指标其实是引申出来性能测试中的一种:竞争测试。什么是竞争测试,软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。

          我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。一般软件可以按照系统架构分成几种类型:

    c/s

    client/Server 客户端/服务器架构

    基于客户端/服务器的三层架构

    基于客户端/服务器的分布式架构

    b/s

    基于浏览器/Web服务器的三层架构

    基于中间件应用服务器的三层架构l

    基于Web服务器和中间件的多层架构l


     
    三、性能测试的步骤

          在每种不同的系统架构的实施中,开发人员可能选择不同的实现方式,造成实际情况纷繁复杂。我们不可能对每种技术都详细解说,这里只是介绍一种方法提供给你如何选择测试策略,从而帮助分析软件不同部分的性能指标,进而分析出整体架构的性能指标和性能瓶颈。

          由于工程和项目的不同,所选用的度量,评估方法也有不同之处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。步骤如下

    1.  制定目标和分析系统
    2.  选择测试度量的方法
    3.  学习的相关技术和工具
    4.  制定评估标准
    5.  设计测试用例
    6.  运行测试用例
    7.  分析测试结果

    ·制定目标和分析系统

        每一个性能测试计划中第一步都会制定目标和分析系统构成。只有明确目标和了解系统构成才会澄清测试范围,知道在测试中要掌握什么样的技术。   

    目标:

    1.  确定客户需求和期望

    2.  实际业务需求

    3.  系统需求

    系统组成

        系统组成这里包含几方面含义:系统类别,系统构成,系统功能等。了解这些内容的本质其实是帮助我们明确测试的范围,选者适当的测试方法来进行测试。

        系统类别:分清系统类别是我们掌握什么样的技术的前提,掌握相应技术做性能测试才可能成功。例如:系统类别是bs结构,需要掌握 http协议,java,html等技术 。或者是cs结构,可能要了解操作系统,winsock,com等。所以甄别系统类别对于我们来说很重要。

        系统构成:硬件设置,操作系统设置是性能测试的制约条件,一般性能测试都是利用测试工具模仿大量的实际用户操作,系统在超负荷情形下运作。不同的系统构成性能测试就会得到不同的结果。

        系统功能:系统功能指系统提供的不同子系统,办公管理系统中的公文子系统,会议子系统等,系统工能是性能测试中要模拟的环节,了解这些是必要的。

    ·选择测试度量的方法

    经过第一步,将会对系统有清醒的认识。接下来我们将把精力放在软件度量上,收集系统相关的数据。

    度量的相关方面:

    * 制定规范

    * 制定相关流程, 角色,职责

    * 制定改进策略

    * 制定结果对比标准

    ·学习的相关技术和工具

         性能测试是通过工具,模拟大量用户操作,对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过 winsock,http等协议纪录用户操作。而协议选择是基于软件的系统架构实现(web一般选择http协议,cs选择winsock协议),不同的性能测试工具,脚本语言也不同,比如rational robot中vu脚本用类c语言实现。

          开展性能测试需要对各种性能测试工具进行评估,因为每一种性能测试工具都有自身的特点,只有经过工具评估,才能选择符合现有软件架构的性能测试工具。确定测试工具后,需要组织测试人员进行工具的学习,培训相关技术。

    ·制定评估标准

             任何测试的目的都是确保软件符合预先规定的目标和要求。性能测试也不例外。所以必须制定一套标准。

          通常性能测试有四种模型技术可用于评估:

             *线性投射:用大量的过去的,扩展的或者将来可能发生的数据组成散布图,利用这个图表不断和系统的当前状况对比。

             *分析模型:用排队论公式和算法预测响应时间,利用描述工作量的数据和系统本质关联起来

             *模仿:模仿实际用户的使用方法测试你的系统

             *基准:定义测试和你最初的测试作为标准,利用它和所有后来进行的测试结果进行对比

    ·设计测试用例

        设计测试用例是在了解软件业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息,设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的,不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例,尽可能把性能测试用例设计的复杂,才有可能发现软件的性能瓶颈。

    ·运行测试用例

        通过性能测试工具运行测试用例。同一环境下作的性能测试得到的测试结果是不准确的,所以在运行这些测试用例的时候,需要用不同的测试环境,不同的机器配置上运行。

    ·分析测试结果

          运行测试用例后,收集相关信息,进行数据统计分析,找到性能瓶颈。通过排除误差和其他因素,让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同,bs结构我们会分析网络带宽,流量对用户操作响应的影响,而cs结构我们可能更关心会系统整体配置对用户操作的影响。

    四、性能测试方法

      对于企业应用程序,有许多进行性能测试的方法,其中一些方法实行起来要比其他方法困难。所要进行的性能测试的类型取决于想要达到的结果。例如,对于可再现性,基准测试是最好的方法。而要从当前用户负载的角度测试系统的上限,则应该使用容量规划测试。本文将介绍几种设置和运行性能测试的方法,并讨论这些方法的区别。

      如果不进行合理的规划,对J2EE应用程序进行性能测试将会是一项令人望而生畏且有些混乱的任务。因为对于任何的软件开发流程,都必须收集需求、理解业务需要,并在进行实际测试之前设计出正式的进度表。性能测试的需求由业务需要驱动,并由一组用例阐明。这些用例可以基于历史数据(例如,服务器一周的负载模式)或预测的近似值。弄清楚需要测试的内容之后,就需要知道如何进行测试了。

      在开发阶段前期,应该使用基准测试来确定应用程序中是否出现性能倒退。基准测试可以在一个相对短的时间内收集可重复的结果。进行基准测试的最好方法是,每次测试改变一个且只改变一个参数。例如,如果想知道增加JVM内存是否会影响应用程序的性能,就逐次递增JVM内存(例如,从1024 MB增至1224 MB,然后是1524 MB,最后是2024 MB),在每个阶段收集结果和环境数据,记录信息,然后转到下一阶段。这样在分析测试结果时就有迹可循。下一小节我将介绍什么是基准测试,以及运行基准测试的最佳参数。

      开发阶段后期,在应用程序中的bug已经被解决,应用程序达到一种稳定状态之后,可以运行更为复杂的测试,确定系统在不同的负载模式下的表现。这些测试被称为容量规划测试、渗入测试(soak test)、峰谷测试(peak-rest test),它们旨在通过测试应用程序的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。对于下面的描述应该从抽象的意义上理解,因为每个应用程序的使用模式都是不同的。例如,容量规划测试通常都使用较缓慢的ramp-up(下文有定义),但是如果应用程序在一天之中的某个时段中有快速突发的流量,那么自然应该修改测试以反映这种情况。但是,要记住,因为更改了测试参数(比如ramp-up周期或用户的考虑时间(think-time)),测试的结果肯定也会改变。一个不错的方法是,运行一系列的基准测试,确立一个已知的可控环境,然后再对变化进行比较。

    基准测试

      基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处:减少重新运行测试的次数;对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量,它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响:同时与服务器通信的连接(或虚拟用户)的数目,以及每个虚拟用户请求之间的考虑时间的长短。很明显,与服务器通信的用户越多,负载就越大。同样,请求之间的考虑时间越短,负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住,随着服务器上负载的增加,吞吐量会不断攀升,直到到达一个点。


    图1.随着负载的增加,系统吞吐量的曲线(单位:页面/秒)

      注意,吞吐量以稳定的速度增长,然后在某一个点上稳定下来。

      在某一点上,执行队列开始增长,因为服务器上所有的线程都已投入使用,传入的请求不再被立即处理,而是放入队列中,当线程空闲时再处理。


    图2. 随着负载的增加,系统执行队列长度的曲线

      注意,最初的一段时间,执行队列的长度为零,然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长,虽然最初系统有足够的空闲线程去处理增加的负载,最终它还是不能承受,而必须将其排入队列。

      当系统达到饱和点,服务器吞吐量保持稳定后,就达到了给定条件下的系统上限。但是,随着服务器负载的继续增长,系统的响应时间也随之延长,虽然吞吐量保持稳定。


    图3. 随着负载的增加,系统中两个事务的响应时间曲线

      注意,在执行队列(图2)开始增长的同时,响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。

      为了获得真正可再现的结果,应该将系统置于相同的高负载下。为此,与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载,并开始构建执行队列。如果请求(虚拟用户)数保持一致,基准测试的结果应该会非常精确,完全可以再现。

      您可能要问的一个问题是:“如何度量结果?”对于一次给定的测试,应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户,然后在预定的时间段内持续运行。这称为“flat”测试。


    图4. flat测试的情况(所有的用户都是同时加载的)

      与此相对应的是“ramp-up”测试。


    图5. ramp-up测试的情况(在测试期间,用户以稳定速度(每秒x个)增加)

      ramp-up测试中的用户是交错上升的(每几秒增加一些新用户)。ramp-up测试不能产生精确和可重现的平均值,这是因为由于用户的增加是每次一部分,系统的负载在不断地变化。因此,flat运行是获得基准测试数据的理想模式。

      这不是在贬低ramp-up测试的价值。实际上,ramp-up测试对找出以后要运行的flat测试的范围非常有用。ramp-up测试的优点是,可以看出随着系统负载的改变,测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。

      Flat测试的问题是系统会遇到“波动”效果。


    图6. 一次flat测试中所测得的系统吞吐量的曲线(单位:页面/秒)

      注意波动的出现,吞吐量不再是平滑的。

      这在系统的各个方面都有所体现,包括CPU的使用量。


    图7. 一次flat测试中所测得的系统CPU使用量随时间变化的曲线

      注意,每隔一段时间就会出现一个波形。CPU使用量不再是平滑的,而是有了像吞吐量图那样的尖峰。

      此外,执行队列也承受着不稳定的负载,因此可以看到,随着系统负载的增加和减少,执行队列也在增长和缩减。


    图8. 一次flat测试中所测得的系统执行队列的曲线

      注意,每隔一段时间就会出现一个波形。执行队列曲线与上面的CPU使用量图非常相似。

      最后,系统中事务的响应时间也遵循着这个波动模式。


    图9. 一次flat测试中所测得的系统事务的响应时间

      注意,每隔一段时间就会出现一个波形。事务的响应时间也与上面的图类似,只不过其效果随着时间的推移逐渐减弱。

      当测试中所有的用户都同时执行几乎相同的操作时,就会发生这种现象。这将会产生非常不可靠和不精确的结果,所以必须采取一些措施防止这种情况的出现。有两种方法可以从这种类型的结果中获得精确的测量值。如果测试可以运行相当长的时间(有时是几个小时,取决于用户的操作持续的时间),最后由于随机事件的本性使然,服务器的吞吐量会被“拉平”。或者,可以只选取波形中两个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常短。

    性能规划测试

      对于性能规划类型的测试来说,其目标是找出,在特定的环境下,给定应用程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了,因为测试中通常都会有随机因子。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常,具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。例如,您可能想知道:如果要以5秒或更少的响应时间支持8,000个当前用户,需要多少个服务器?要回答这个问题,需要知道系统的更多信息。

      要确定系统的容量,需要考虑几个因素。通常,服务器的用户总数非常大(以十万计),但是实际上,这个数字并不能说明什么。真正需要知道的是,这些用户中有多少是并发与服务器通信的。其次要知道的是,每个用户的“考虑时间”即请求间时间是多少。这非常重要,因为考虑时间越短,系统所能支持的并发用户越少。例如,如果用户的考虑时间是1秒,那么系统可能只能支持数百个这样的并发用户。但是,如果用户的考虑时间是30秒,那么系统则可能支持数万个这样的并发用户(假定硬件和应用程序都是相同的)。在现实世界中,通常难以确定用户的确切考虑时间。还要注意,在现实世界中,用户不会精确地按照间隔时间发出请求。

      于是就引入了随机性。如果知道普通用户的考虑时间是5秒,误差为20%,那么在设计负载测试时,就要确保请求间的时间为5×(1 +/- 20%)秒。此外,可以利用“调步”的理念向负载场景中引入更多的随机性。它是这样的:在一个虚拟用户完成一整套的请求后,该用户暂停一个设定的时间段,或者一个小的随机时间段(例如,2×(1 +/- 25%)秒),然后再继续执行下一套请求。将这两种随机化方法运用到测试中,可以提供更接近于现实世界的场景。

      现在该进行实际的容量规划测试了。接下来的问题是:如何加载用户以模拟负载状态?最好的方法是模拟高峰时间用户与服务器通信的状况。这种用户负载状态是在一段时间内逐步达到的吗?如果是,应该使用ramp-up类型的测试,每隔几秒增加x个用户。或者,所有用户是在一个非常短的时间内同时与系统通信?如果是这样,就应该使用flat类型的测试,将所有的用户同时加载到服务器。两种不同类型的测试会产生没有可比性的不同测试。例如,如果进行ramp-up类型的测试,系统可以以4秒或更短的响应时间支持5,000个用户。而执行flat测试,您会发现,对于5,000个用户,系统的平均响应时间要大于4秒。这是由于ramp-up测试固有的不准确性使其不能显示系统可以支持的并发用户的精确数字。以门户应用程序为例,随着门户规模的扩大和集群规模的扩大,这种不确定性就会随之显现。

      这不是说不应该使用ramp-up测试。对于系统负载在一段比较长的时间内缓慢增加的情况,ramp-up测试效果还是不错的。这是因为系统能够随着时间不断调整。如果使用快速ramp-up测试,系统就会滞后,从而报告一个较相同用户负载的flat测试低的响应时间。那么,什么是确定容量的最好方法?结合两种负载类型的优点,并运行一系列的测试,就会产生最好的结果。例如,首先使用ramp-up测试确定系统可以支持的用户范围。确定了范围之后,以该范围内不同的并发用户负载进行一系列的flat测试,更精确地确定系统的容量。

    渗入测试

      渗入测试是一种比较简单的性能测试。渗入测试所需时间较长,它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集(GC)或系统的其他问题,显示因长时间运行而出现的任何性能降低。测试运行的时间越久,您对系统就越了解。运行两次测试是一个好主意——一次使用较低的用户负载(要在系统容量之下,以便不会出现执行队列),一次使用较高的负载(以便出现积极的执行队列)。

      测试应该运行几天的时间,以便真正了解应用程序的长期健康状况。要确保测试的应用程序尽可能接近现实世界的情况,用户场景也要逼真(虚拟用户通过应用程序导航的方式要与现实世界一致),从而测试应用程序的全部特性。确保运行了所有必需的监控工具,以便精确地监测并跟踪问题。

    峰谷测试

      峰谷测试兼有容量规划ramp-up类型测试和渗入测试的特征。其目标是确定从高负载(例如系统高峰时间的负载)恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。

      实现这种测试的最好方法就是,进行一系列的快速ramp-up测试,继之以一段时间的平稳状态(取决于业务需求),然后急剧降低负载,此时可以令系统平息一下,然后再进行快速的ramp-up;反复重复这个过程。这样可以确定以下事项:第二次高峰是否重现第一次的峰值?其后的每次高峰是等于还是大于第一次的峰值?在测试过程中,系统是否显示了内存或GC性能降低的有关迹象?测试运行(不停地重复“峰值/空闲”周期)的时间越长,您对系统的长期健康状况就越了解。

    结束语

      本文介绍了进行性能测试的几种方法。取决于业务需求、开发周期和应用程序的生命周期,对于特定的企业,某些测试会比其他的更适合。但是,对于任何情况,在决定进行某一种测试前,都应该问自己一些基本问题。这些问题的答案将会决定哪种测试方法是最好的。

      这些问题包括:

    结果的可重复性需要有多高?
    测试需要运行和重新运行几次?
    您处于开放周期的哪个阶段?
    您的业务需求是什么?
    您的用户需求是什么?
    您希望生产中的系统在维护停机时间中可以持续多久?
    在一个正常的业务日,预期的用户负载是多少?
      将这些问题的答案与上述性能测试类型相对照,应该就可以制定出测试应用程序的总体性能的完美计划。

  • 性能测试(并发负载压力)测试分析-简要篇

    2007-6-05

    分析原则:

    • 具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
    • 查找瓶颈时按以下顺序,由易到难。
      服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
      注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

    分析的信息来源:

    • 1 根据场景运行过程中的错误提示信息
    • 2 根据测试结果收集到的监控指标数据

    一.错误提示分析

     分析实例:

    • Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
    • Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

    分析:

    • A、应用服务死掉。
      (小用户时:程序上的问题。程序上处理数据库的问题)
    • B、应用服务没有死
      (应用服务参数设置问题)
      例:在许多客户端连接Weblogic应用服务器被拒绝,而在服务器端没有错误显示,则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息,说明应提高该值,每次增加25%
    • C、数据库的连接
     (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数(跟硬件的内存有关))
       2 Error: Page download timeout (120 seconds) has expired

    分析:可能是以下原因造成

    • A、应用服务参数设置太大导致服务器的瓶颈
    • B、页面中图片太多
    • C、在程序处理表的时候检查字段太大多

    二.监控指标数据分析

     1.最大并发用户数:

     应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置))下能承受的最大并发用户数。

     在方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

     如果测得的最大并发用户数到达了性能要求,且各服务器资源情况良好,业务操作响应时间也达到了用户要求,那么OK。否则,再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

    2.业务操作响应时间:

    • 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图,可以确定在方案执行期间响应时间过长的事务。
    • 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的?问题是否与网络或服务器有关?
    • 如果服务器耗时过长,请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长,请使用“网络监视器”图确定导致性能瓶颈的网络问?/li>
     3.服务器资源监控指标:

     内存:
     1 UNIX资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中,如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高,同时Memory\Available bytes计数器的值持续降低,则很可能存在内存泄漏。

    内存资源成为系统性能的瓶颈的征兆:
     很高的换页率(high pageout rate);
     进程进入不活动状态;
     交换区所有磁盘的活动次数可高;
     可高的全局系统CPU利用率;
     内存不够出错(out of memory errors)

    处理器:
     1 UNIX资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 合理使用的范围在60%至70%。
     2 Windows资源监控中,如果System\Processor Queue Length大于2,而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。

    CPU资源成为系统性能的瓶颈的征兆:
     很慢的响应时间(slow response time)
     CPU空闲时间为零(zero percent idle CPU)
     过高的用户占用CPU时间(high percent user CPU)
     过高的系统占用CPU时间(high percent system CPU)
     长时间的有很长的运行进程队列(large run queue size sustained over time)

    磁盘I/O:
     1 UNIX资源监控(Windows操作系统同理)中指标磁盘交换率(Disk rate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。
     2 Windows资源监控中,如果 Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。

    I/O资源成为系统性能的瓶颈的征兆 :
     过高的磁盘利用率(high disk utilization)
     太长的磁盘等待队列(large disk queue length)
     等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
     太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
     过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
     太长的运行进程队列,但CPU却空闲(large run queue with idle CPU)

    4.数据库服务器:
     SQL Server数据库:
     1 SQLServer资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。如果持续低于80%,应考虑增加内存。
     2 如果Full Scans/sec(全表扫描/秒)计数器显示的值比1或2高,则应分析你的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。
     3 Number of Deadlocks/sec(死锁的数量/秒):死锁对应用程序的可伸缩性非常有害,并且会导致恶劣的用户体验。该计数器的值必须为0。
     4 Lock Requests/sec(锁请求/秒),通过优化查询来减少读取次数,可以减少该计数器的值。

    Oracle数据库:
     1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90,那么需要增加SHARED_POOL_SIZE的大小。
    快存(共享SQL区)和数据字典快存的命中率:

     select(sum(pins-reloads))/sum(pins) from v$librarycache;
     select(sum(gets-getmisses))/sum(gets) from v$rowcache;
     自由内存: select * from v$sgastat where name=’free memory’;

    2 如果数据的缓存命中率小于0.90,那么需要加大DB_BLOCK_BUFFERS参数的值(单位:块)。
     缓冲区高速缓存命中率:

     select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ; Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

    3 如果日志缓冲区申请的值较大,则应加大LOG_BUFFER参数的值。
     日志缓冲区的申请情况 :

    select name,value from v$sysstat where name = 'redo log space requests' ;

    4 如果内存排序命中率小于0.95,则应加大SORT_AREA_SIZE以避免磁盘排序 。
     内存排序命中率 :

    select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where  a.name='sorts (disk)' and b.name='sorts (memory)'

     

    UNIX资源监控指标和描述

      监控指标 描述

      平均负载 系统正常状态下,最后60秒同步进程的

      平均个数

      冲突率 在以太网上监测到的每秒冲突数

      进程/线程交换率 进程和线程之间每秒交换次数

      CPU利用率 CPU占用率(%)

      磁盘交换率 磁盘交换速率

      接收包错误率 接收以太网数据包时每秒错误数

      包输入率 每秒输入的以太网数据包数目

      中断速率 CPU每秒处理的中断数

      输出包错误率 发送以太网数据包时每秒错误数

      包输入率 每秒输出的以太网数据包数目

      读入内存页速率 物理内存中每秒读入内存页的数目

      写出内存页速率 每秒从物理内存中写到页文件中的内存页数

      目或者从物理内存中删掉的内存页数目

      内存页交换速率 每秒写入内存页和从物理内存中读出页的个数

      进程入交换率 交换区输入的进程数目

      进程出交换率 交换区输出的进程数目

      系统CPU利用率 系统的CPU占用率(%)

      用户CPU利用率 用户模式下的CPU占用率(%)

      磁盘阻塞 磁盘每秒阻塞的字节数

    注:上述SQL Server和Oracle数据库分析,只是一些简单、基本的分析,特别是Oracle数据库的分析和优化,是一门专门的技术,进一步的分析可查相关资料。

  • 性能测试监控点

    2008-12-22 11:12:46

    Unix主机

    • CPU使用率;
    • 内存使用状况;
    • Disk I/O;
    数据库服务器
    • Cache命中
    • Long Transaction
    • 索引使用情况
    • 数据库进程CPU使用状况
    • 数据库内存使用状况
    • 数据库连接数量
    应用服务器
    • MQ的主要进程内存使用状况
    • MQ的进程数量
    • TEMIP主要进程内存使用状况
    WEB服务器
    • 进程的CPU和内存使用状况
    • Cache命中
    • 平均响应时间等
    对这些内容的记录需要通过操作系统提供的性能观测工具或是应用自身提供的性能观测工具:
    1. 在Unix环境中,可以用top、vmstat、iostat程序观察需要记录的内容,更好的方法是自己写一个简单脚本,把时间信息和输出信息一同存入本地日志文件。在本测试中,我们用Perl和Unix的Shell脚本实现了对输出信息的抽取和格式化,生成的记录文件可以方便地被Excel等程序进行处理;
    2. 对于数据库环境,可以用Oracle自带的性能监测工具或是第三方软件(如TOAD等)观察性能并存成文件;
    3. 对WEB服务器,可以用WEB Server自带的性能监测工具监测其性能。
  • 性能测试续2 基准测试

    2007-6-07

    基准测试
    基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处:减少重新运行测试的次数;对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量,它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响:同时与服务器通信的连接(或虚拟用户)的数目,以及每个虚拟用户请求之间的考虑时间的长短。很明显,与服务器通信的用户越多,负载就越大。同样,请求之间的考虑时间越短,负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住,随着服务器上负载的增加,吞吐量会不断攀升,直到到达一个点。

    1.随着负载的增加,系统吞吐量的曲线(单位:页面/秒)
    注意,吞吐量以稳定的速度增长,然后在某一个点上稳定下来。
    在某一点上,执行队列开始增长,因为服务器上所有的线程都已投入使用,传入的请求不再被立即处理,而是放入队列中,当线程空闲时再处理。



    2. 随着负载的增加,系统执行队列长度的曲线
    注意,最初的一段时间,执行队列的长度为零,然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长,虽然最初系统有足够的空闲线程去处理增加的负载,最终它还是不能承受,而必须将其排入队列。
    当系统达到饱和点,服务器吞吐量保持稳定后,就达到了给定条件下的系统上限。但是,随着服务器负载的继续增长,系统的响应时间也随之延长,虽然吞吐量保持稳定。



    3. 随着负载的增加,系统中两个事务的响应时间曲线
    注意,在执行队列(图2)开始增长的同时,响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。
    为了获得真正可再现的结果,应该将系统置于相同的高负载下。为此,与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载,并开始构建执行队列。如果请求(虚拟用户)数保持一致,基准测试的结果应该会非常精确,完全可以再现。
    您可能要问的一个问题是:如何度量结果?对于一次给定的测试,应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户,然后在预定的时间段内持续运行。这称为“flat”测试。



    4. flat测试的情况(所有的用户都是同时加载的)
    与此相对应的是“ramp-up”测试。



    5. ramp-up测试的情况(在测试期间,用户以稳定速度(每秒x个)增加)
    ramp-up
    测试中的用户是交错上升的(每几秒增加一些新用户)。ramp-up测试不能产生精确和可重现的平均值,这是因为由于用户的增加是每次一部分,系统的负载在不断地变化。因此,flat运行是获得基准测试数据的理想模式。
    这不是在贬低ramp-up测试的价值。实际上,ramp-up测试对找出以后要运行的flat测试的范围非常有用。ramp-up测试的优点是,可以看出随着系统负载的改变,测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。
    Flat
    测试的问题是系统会遇到波动效果。



    6. 一次flat测试中所测得的系统吞吐量的曲线(单位:页面/秒)
    注意波动的出现,吞吐量不再是平滑的。
    这在系统的各个方面都有所体现,包括CPU的使用量。



    7. 一次flat测试中所测得的系统CPU使用量随时间变化的曲线
    注意,每隔一段时间就会出现一个波形。CPU使用量不再是平滑的,而是有了像吞吐量图那样的尖峰。
    此外,执行队列也承受着不稳定的负载,因此可以看到,随着系统负载的增加和减少,执行队列也在增长和缩减。



    8. 一次flat测试中所测得的系统执行队列的曲线
    注意,每隔一段时间就会出现一个波形。执行队列曲线与上面的CPU使用量图非常相似。
    最后,系统中事务的响应时间也遵循着这个波动模式。



    9. 一次flat测试中所测得的系统事务的响应时间
    注意,每隔一段时间就会出现一个波形。事务的响应时间也与上面的图类似,只不过其效果随着时间的推移逐渐减弱。
    当测试中所有的用户都同时执行几乎相同的操作时,就会发生这种现象。这将会产生非常不可靠和不精确的结果,所以必须采取一些措施防止这种情况的出现。有两种方法可以从这种类型的结果中获得精确的测量值。如果测试可以运行相当长的时间(有时是几个小时,取决于用户的操作持续的时间),最后由于随机事件的本性使然,服务器的吞吐量会被拉平。或者,可以只选取波形中两个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常短。
    性能规划测试
    对于性能规划类型的测试来说,其目标是找出,在特定的环境下,给定应用程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了,因为测试中通常都会有随机因子。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常,具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。例如,您可能想知道:如果要以5秒或更少的响应时间支持8,000个当前用户,需要多少个服务器?要回答这个问题,需要知道系统的更多信息。
    要确定系统的容量,需要考虑几个因素。通常,服务器的用户总数非常大(以十万计),但是实际上,这个数字并不能说明什么。真正需要知道的是,这些用户中有多少是并发与服务器通信的。其次要知道的是,每个用户的考虑时间即请求间时间是多少。这非常重要,因为考虑时间越短,系统所能支持的并发用户越少。例如,如果用户的考虑时间是1秒,那么系统可能只能支持数百个这样的并发用户。但是,如果用户的考虑时间是30秒,那么系统则可能支持数万个这样的并发用户(假定硬件和应用程序都是相同的)。在现实世界中,通常难以确定用户的确切考虑时间。还要注意,在现实世界中,用户不会精确地按照间隔时间发出请求。
    于是就引入了随机性。如果知道普通用户的考虑时间是5秒,误差为20%,那么在设计负载测试时,就要确保请求间的时间为1 +/- 20%)秒。此外,可以利用调步的理念向负载场景中引入更多的随机性。它是这样的:在一个虚拟用户完成一整套的请求后,该用户暂停一个设定的时间段,或者一个小的随机时间段(例如,1 +/- 25%)秒),然后再继续执行下一套请求。将这两种随机化方法运用到测试中,可以提供更接近于现实世界的场景。
    现在该进行实际的容量规划测试了。接下来的问题是:如何加载用户以模拟负载状态?最好的方法是模拟高峰时间用户与服务器通信的状况。这种用户负载状态是在一段时间内逐步达到的吗?如果是,应该使用ramp-up类型的测试,每隔几秒增加x个用户。或者,所有用户是在一个非常短的时间内同时与系统通信?如果是这样,就应该使用flat类型的测试,将所有的用户同时加载到服务器。两种不同类型的测试会产生没有可比性的不同测试。例如,如果进行ramp-up类型的测试,系统可以以4秒或更短的响应时间支持5,000个用户。而执行flat测试,您会发现,对于5,000个用户,系统的平均响应时间要大于4秒。这是由于ramp-up测试固有的不准确性使其不能显示系统可以支持的并发用户的精确数字。以门户应用程序为例,随着门户规模的扩大和集群规模的扩大,这种不确定性就会随之显现。
    这不是说不应该使用ramp-up测试。对于系统负载在一段比较长的时间内缓慢增加的情况,ramp-up测试效果还是不错的。这是因为系统能够随着时间不断调整。如果使用快速ramp-up 查看(581) 评论(0) 收藏 分享 管理

  • LoadRunner监控Windows/Unix系统资源的配置

    2008-12-22 11:12:46

    LoadRunner监控Windows/Unix系统资源需要做两件事情:

      1、配置被监视的服务器,以便于LoadRunner能够获取系统资源使用情况的数据

      2、在LoadRunner的Controller中添加计数器

      添加计数器比较简单,这里主要讲如何配置Windows/Unix服务器。

      一、配置UNIX系统:

      1、 修改/etc/xinetd.d/下的三个conf文件 rlogin , rsh ,rexec 这三个配置文件,把这三个文件里的disable =yes都改成 disable = no ( disabled 用在默认的 {} 中 禁止服务),或是把# default: off都设置成 on 这个的意思就是在xinetd启动的时候默认都启动上面的三个服务。

      2、 执行: rpc.rstatd

      3、 检查是否启动rstatd,输入命令: rpcinfo –p。如果能看到:

      程序 版本 协议 端口

      *** **** udp 741 rstatd

      那就说明rstatd服务启动了

      4、 LR中添加计算器

      如果系统没有安装rstatd的话,上面的操作将会不成功,需要先安装rstatd,安装rstatd过程很简单:

      1、从安装光盘或网上找到安装文件(一般是rstatd***.tar.gz)

      2、解压缩安装包:

      tar xzvf rstatd***.tar.gz

      3、进入源文件目录运行配置文件和编译:

      $ ./configure

      $ make

      $ make install

      安装好之后,就按上面的步骤启动rstatd即可。

      (说明:以上的操作需要root用户权限)

      二、配置windows系统

      1、 保证被监视的windows系统开启以下二个服务:Remote Procedure Call(RPC) 和Remote Registry Service

      2、 获得对远程计算机的管理权限,请在命令提示符(运行cmd命令)下执行以下命令:

      net use \\<计算机名>/用户:[<域>\<远程计算机名>]

      提示输入密码时,输入远程计算机的密码。

      例如:

      net use \\192.168.18.67 administrator

      net use \\192.168.18.67 /user:administrator

      如果提示错误,则不加用户名:

      net use \\192.168.18.67

      需要用户名和密码的话,系统会提示输入用户名和密码,按提示做即可。

      如果看到“命令成功完成”的提示,则说明配置成功了。

  • LR监控Apache

    2008-12-22 11:12:46

    打开<Apache Installation>\conf\httpd.conf,进行如下修改:

    1
      设置允许查看Apache运行状态的主机

    #

    # Allow server status reports, with the URL of http://servername/server-status

    # Change the ".your-domain.com" to match your domain to enable.

    #

    #
    取消一下代码前面的注释符号“#”,并且设置Order(顺序)为允许优先

    <Location /server-status>

        SetHandler                                  server-status

        Order                                        allow,deny

        Deny from                                 nothing

        Allow from                                all

    </Location>

    这样改变以后重新启动Apache在浏览器中输入http://servername/server-status就可以看到Apache运行时的信息,而输入http://servername/server-status?auto就会看到如下信息:

    Total Accesses: 124

    Total kBytes: 444

    CPULoad: 3.32432

    Uptime: 37

    ReqPerSec: 3.35135

    BytesPerSec: 12288

    BytesPerReq: 3666.58

    BusyWorkers: 1

    IdleWorkers: 7

    Scoreboard: ____W___.........................


    看到这样的信息就表示修改成功,这样就可以使用LoadRunner监视Apache了。

    以下两步跟使用LoadRunner监视Apache无关,可以跳过不看。

    2
      改变Apache的设置,打开详细状态开关;

    #

    # ExtendedStatus controls whether Apache will generate "full" status

    # information (ExtendedStatus On) or just basic information (ExtendedStatus

    # Off) when the "server-status" handler is called. The default is Off.

    #

    #
    取消了下面一行前面的注释符号“#”

    ExtendedStatus On

    3
      有用的设置,查看各模块信息

    #

    # Allow remote server configuration reports, with the URL of

    #  http://servername/server-info (requires that mod_info.c be loaded).

    # Change the ".example.com" to match your domain to enable.

    #

    #
    取消一下代码前面的注释符号“#”,并且设置Order(顺序)为允许优先

    <Location /server-info>

        SetHandler                                  server-info

        Order                                         allow,deny

        Deny from                                  nothing

        Allow from                                 all

    </Location>

    二、LoadRunner上的设置

    经过以上第一项设置以后就可以使用LoadRunner监控Apache的运行情况了,在LoadRunner可用的监视器中双击Web Server Resource Graphs下的Apache节点,然后在右边对应的窗口中添加Apache所在主机的IP地址,并且加入计数器后单击OK,这样就可以在LoadRunner中实时显示Apache的运行状态信息了。

    注意:您可能收到如下消息【Monitor name :Apache. Parsing error, cannot find token: BusyServers. Measurement: BusyServers|192.168.0.186. Hints: 1) Such a measurement does not exist, or the html page may be different from the supported one. 2) Try to replace the Apache.cfg with appropriate Apache_<version>.cfg file in <Installation>\dat\monitors and rerun the application (entry point: CApacheMeasurement::NewData).   [MsgId: MMSG-47479]】,这是由于要监视Apache的版本提供的计数器与LoadRunner默认的计数器不一致导致的。此时建议先关闭Controller,打开<Installation>\dat\monitors下的apache.cfg文件(其它文件名类似Apache_<version>.cfg的是Apache监视配置的备份,只有apache.cfg是生效的):

    1
      修改Counter0=IdleServersCounter0=IdleWorkers,同时修改注释信息Label0=#Idle Servers (Apache)Label0=#Idle Workers (Apache),描述信息也建议修改;

    2
      修改Counter4=BusyServersCounter4=BusyWorkers,同时修改注释信息Label4=#Busy Servers (Apache)Label4=#Busy Workers (Apache) ,描述信息也建议修改。

    然后保存并关闭该文件,重新打开Controller并添加计数器,这样监视就正常了。
  • 让你一眼区分瓶颈是Memory、processor OR disk

    2008-12-22 11:12:46

    各项硬件使用剖析(一)---让你一眼就能区分瓶颈是Memory、processor ORdisk!
    
    各项硬件使用剖析(一)
    各项硬件的资源,如CPU、内存、硬盘输入输出、网络带宽等等。在实际查看架构之前,先强调一个观念,不管是使用系统上哪一种资源,当使用率持续超过80%时,系统的性能一定会急速下滑,而不会显示线性关系,如下图所示:
    
        响应时间
    
    
    
    
                   
                   使用率        80%
               资源使用率与系统响应时间的关系
    注:从《操作系统》的知识来理解,如果在多用户环境中cup的使用率大于80%,进程就会在运行队列中花费大量的等待时间,响应时间和吞吐量就会下降。
    3.1,内存Memory
          通常系统中所发生的问题是由于内存不足所导致,这是较常见的。所以我们应该先监视内存,确认我们的服务器有足够的内存。若要执行 windows 2000 上的 iis 5.0(如MOD的web服务),一个专用web 服务器所需 ram 的最小容量是 128mb,但最好是 256mb 到 1gb。因为「iis 文件缓存」默认是使用最多一半可用的内存,因此备有的内存越多,「iis 文件缓存」就越多。 
    
      附注:windows 2000 advanced server 最多可支持 8gb 的 ram,但是「iis文件缓存」将不会利用 4gb 以上的 ram。
         所有在Windows系统执行的应用程序都以为自已最起码有2GB的连续内存(称之为虚拟内存),当应用程序的线程在存取内存时,操作系统会将其映射(mapping)到某块物理内存,若物理内存不足,操作系统就把物理内存中某些较少用到的区块写至硬盘,以空出该物理内存给当前需要的程序。
    Available MBytes 可用物理内存数  
         说明:Available MBytes 是计算机上运行进程可用的物理内存数量,以兆字节为单位。通过计算清零、空闲和待命内存列表的内存空间总数而得到。空闲内存可以马上使用; 清零内存是由零值填满的内存页,用来防止后续进程获得旧进程使用的数据; 待命内存是从进程工作集(其物理内存)中删除然后进入磁盘的内存,但是该内存仍然可以收回。该计数器仅显示最后一次观察到的值; 不是平均值。
         技 术 :一般要保留10%的可用内存。最低最低不能<4M,此值过小可能是内存不足或内存泄漏;
         原 因 :因为IIS默认最多会使用50%的可用内存供文件缓存使用,所以要保留10%的可用内存(以供尖峰时间使用)。
         知识点:物理内存、虚拟内存、IIS文件缓存、清0内存(程序常发生的错误)、待命内存。
    
           
    Page Faults/sec、Pages Input/sec、Page Reads/sec
        注(重要):导致严重的延迟原因:是因为硬件分页错误。
         说 明: Page Faults/sec 是指处理器处理错误页的综合速率。用错误页数/秒来计算。当处理器请求一个不在其工作集(在物理内存中的空间)内的代码或数据时出现的页错误。这个计数器包括硬错误(那些需要磁盘访问的)和软错误(在物理内存的其它地方找到的错误页)。许多处理器可以在有大量软错误的情况下继续操作。但是,硬错误可以导致明显的拖延。
          Pages Input/sec 指为解决页错误从磁盘上读取的页数。(当处理需要不在其工作集或物理内存的任何地方的代码或数据,而需要从磁盘上检索时出现硬页错误)。
                 Page Reads/sec 是指为解析硬页错误而读取磁盘的次数。(当处理请求的硬 页错误不在工作集和物理内存其它地方中的代码或数据,而必须从磁盘上检索时 就会出现硬页错误)。如果 Page Reads/Sec 比率持续保持为 5,表示可能内存不足(阈值为>5.越小越好)。
    
         可能引起页面错误的操作:应用程序向内存请求一个分页,但系统无法在所需的位置上找到它,就构成了一个页面错误。
         技 术:
             总述:可能涉及到1,由于页交换而导致内存不足;2,由于页交换而导致磁盘瓶颈;
                   当这些值很低时,服务器应该可以很快地响应请求;当这些值较高时,是因为你花了太多的内存在缓存处理上,而没有留足够的内存供系统的其它部份使用。可以增加内存或降低缓存的ram大小来解决;
             详细:
                  page Faults/sec:只表明数据不能在内存的指定工作集中立即使用;
                  page Input/sec: page input/sec > page reads/sec; 
                  page Reads/sec: 阈值为>5.越小越好,大数值表示磁盘读而不是缓存读;
    Page/sec:指为解析硬页错误从磁盘读取或写入磁盘的页数(是Pages Input/sec 和 Pages Output/sec 的总和)。其值推荐00-20如果服务器没有足够的内存处理其工作负荷,此数值将一直很高。如果大于80,表示有问题(太多的读写数据操作要访问磁盘,可考虑增加内存或优化读写数据的算法),如果值比较低,说明Web 服务器响应请求比较快,否则可能是服务器系统内存短缺引起( 也可能是缓存太大,导致系统内存太少)。
    
    3.2,Processor
    随着用户请求从网站获得快速的响应时间,以及在这些网站上不断增加的动态内容,需要利用到快速、有效的处理器用量。当一个或多个进程几乎耗尽所有处理器时,就会发生瓶颈,这会迫使准备好执行的进程线程必须在队列中等待处理器时间。
    (web方面) windows 2000 及 iis 5.0 的最大性能增益来自于解决内存问题。在决定改变web 服务器上处理器的个数之前,请先排除内存问题,再监视下列「性能计数器」。
    % Processor Time 指处理器执行非闲置线程时间的百分比;通俗一点讲就是CPU 使用率。这是监视处理器活动的主要指示器。它通过在每个范例间隔中衡量处理器用于执行闲置处理线程的时间,并且用100%减去该值得出。(每台处理器有一个闲置线程,该线程在没有其它线程可以运行时消耗周期)。可将其视为范例间隔用于做有用工作的百分比。
    正常值<90,此值过大表示处理器的性能已经不能应付程序的要求,要换更快的处理器。该数值持续超过 90%,则表示此测试的负载对于目前的硬件过于沉重。排除内存因素,如果该计数器的值比较大,而同时网卡和硬盘的值比较低,那么可以确定CPU 瓶颈。
    
    Processor Queue Length:是指处理列队中的线程数。显示在由 Web服务器所有处理器共享的队列中等待执行的线程数。如果处理器列队中总是有2个以上的线程通常表示处理器堵塞。
    参考值:小于2。处理器瓶颈会导致该值持续大于 2。
    
    
    3.3, Physical Disk:
        因为 MOD的WEB(iis 5.0) 会将记录文件写入磁盘上,所以在一般磁盘活动中,甚至会有高达 100 % 的客户端缓存存取次数。一般来说,如果有记录以外的大量磁盘读取活动,即表示系统上有其它区域需要调整。例如,硬件分页错误会导致大量的磁盘活动,但它们表示 ram 不足。 
    
    %Disk Time %:  指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大,那么硬盘不是瓶颈。如果只有%Disk Time比较大,另外两个都比较适中,硬盘可能会是瓶颈。在记录该计数器之前,请在Windows 2000 的命令行窗口中运行diskperf -yD。正常值<10,此值过大表示耗费太多时间来访问磁盘,可考虑增加内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络连接并没有饱和),则可能是内存泄漏。
    
    Pages per second :  每秒钟检索的页数。该数字应少于每秒一页。
    
    
    如果这三个计数器(processor: % processor time, network interface connection: bytes total/sec及physicaldisk: % disk time)的值都很高,则硬盘不会引起站点的瓶颈。
    
    补充:
      Avg. Disk Queue Length 指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。正常值<0.5,此值过大表示磁盘IO太慢,要更换更快的硬盘。
      Disk Transfers/sec 指在此盘上读取/写入操作速率。正常值<(Disk Bytes/sec)/3,此值过大表示系统要求的IO速度已接近硬盘的最大速度,要更换更快的硬盘。
        磁盘使用情况计数器和内存计数器(磁盘瓶颈or内存不足?):
    Physical Disk\ % Disk Time 、Physical Disk\ Avg.Disk Queue Length 例如,包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低,同时 % Disk Time 和 Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。
    
       3.4, 网络容量、等待时间及带宽  
      测试目标:在系统试运行之后,需要及时准确地了解网络上正在发生什么事;什么应用在运行,如何运行;多少PC正在访问LAN或WAN;哪些应用程序导致系统瓶颈或资源竞争
    作用
    1,分析关键应用程序的性能
    2,定位问题的根源是在客户端、服务器、应用程序还是网络
    3,哪些应用程序占用大量带宽
      基本上,网络是客户端向服务器传送请求的线路。它花在您的服务器上来回传递这些请求及响应的时间,对用户能察觉的服务器性能来说是个最大限制因素之一。这种请求-响应的循环时间就称为等待时间,等待时间对于web 服务器管理员来说几乎是无法控制的。例如,您对 internet 上速度缓慢的路由器,或是客户端及服务器之间的物理距离所能作的处理实在不多。
       在主要是由静态内容组成的站点上,网络带宽最有可能是性能瓶颈的来源。即使是一般的服务器也可能用满一条 t3 连接 (45mbps) 或 100mbps fast ethernet 连接。测量有效带宽最简单的方法是判定您的服务器是以哪个速度传送及接收资料的。
    Network Interface Bytes Total/sec: 为发送和接收字节的速率,包括帧字符在内。判定网络连接是否存在瓶颈。若要在传送量中留些空间供尖峰时间用,则不应常使用超过 50% 的容量。如果这个数字十分接近连接的容量,而处理器及内存的使用都很适中,则此连接也会是个问题。参考值:该计数器的值和目前网络的带宽相除,结果应该小于50%。
    如果您正在计算机上执行的其他服务也使用网络连接,请监视「web service: maximum connections」及「web service: total connection attempts」计数器,以检查您的web服务器是否能够尽可能地使用它需要的连接数目。请记得将这些数字与内存及处理器使用量作比较,如此才能确定连接就是问题,而不是其它组件有问题。
    Connection Attempts/sec:Web服务尝试连接的频率。
    Maximun Connections:“最大连接数”是和Web服务同时建立起来的最大连接数。 
    
  • 软件测试中有关界面测试经验总结

    2008-12-22 11:12:46

    1.应验证界面显示内容的完整性:

      a) 报表显示时应考虑数据显示宽度的自适应或自动换行。

      b) 所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等),必须使测试数据的记录数超过一屏/一页,以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印,界面显示是否正常;

      2.应验证界面显示内容的一致性:

      a) 如有多个系统展现同一数据源时,应保证其一致性;

      3.应验证界面显示内容的准确性:

      a) 对于报表中的所有字段值都应该有明确的定义,对于无意义的字段值,不应该显示空,应显示“--”或“/”,表示该字段值无意义。

      4.应验证界面显示内容的友好性:

      a) 对统计的数据应按用户习惯进行分类、排序。

      b) 某些重要信息在输入、修改、删除时应有“确认”提示信息;

      c) 界面内容更新后系统应提供刷新功能。

      d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;

      5.应验证界面提示信息的指导性:

      a) 在多个业务功能组成的一个业务流程中,如果各个功能之间的执行顺序有一定的制约条件,应通过界面提示用户。

      b) 用户提示信息应具有一定的指导性,在应用程序正在进行关键业务的处理时,应考虑在前台界面提示用户应用程序正在进行的处理,以及相应的处理过程,在处理结束后再提示用户处理完毕。

      c) 在某些数据输入界面,如果要求输入的数据符合某项规则,应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。

      d) 在对任何配置信息修改后,都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);

      6.应验证界面显示内容的合理性:

      a) 在对某些查询功能进行测试时,应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。

      b) 界面测试时,应考虑某一界面上按钮先后使用的顺序问题,以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。

      c) 界面测试时,应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确;

      7.界面测试时,应考虑用户使用的方便性:

      a) 在某些对数据进行处理的操作界面,应考虑用户可能对数据进行处理的频繁程度和工作量,考虑是否可以进行批量操作。

    8.界面测试时,应考虑界面显示及处理的正确性:

      a) 界面测试时应验证所有窗体中的对象状态是否正常,是否符合相关的业务规则需要。

      b) 应验证各种对象访问方法(Tab 健、鼠标移动和快捷键)是否可正常使用,并且在一个激活界面中快捷键无重复;

      c) 界面测试不光要考虑合理的键盘输入,还应考虑是否可以通过鼠标拷贝粘贴输入。

      d) 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发,应避免其他形式的触发。

      e) 对界面上的任何对象进行拖拉,然后进行查询、打印,应保证查询打印结果不变;

      9.界面测试时,应考虑数据显示的规范性:

      a) 确保数据精度显示的统一:如单价0元,应显示为0.00元;

      b) 确保时间及日期显示格式的统一;

      c) 确保相同含义属性/字段名的统一;

      d) 对所有可能产生的提示信息界面内容和位置进行验证,确保所有的提示信息界面应居中。

  • lr常见问题及精华归总结

    2007-07-16 17:35:45

  • 关于loadrunner安装和卸载的以下看法

    2007-07-06 10:04:55

  • LoadRunner监控Windows和Linux常见问题

    2007-07-02 18:09:44

  • loadrunner运行原理

    2007-07-02 15:40:30

  • 优化WebLogic 服务器性能参数

    2007-07-02 13:43:52

  • Breakdown Graph 中First Buffer是什么?

    2007-07-02 12:17:50

  • First Buffer非常大说明什么问题?

    2007-07-02 12:03:53

  • VUG运行时产生Error -27979

    2007-07-02 11:55:29

  • Controller运行完毕之后,日志文件在哪里保存的?

    2007-07-02 11:29:09

  • were not create hits per second,throughout

    2007-06-29 15:14:47

  • Loadrunner中参数设置详细分析

    2007-06-13 10:24:39

    Loadrunner中参数设置详细分析
    相信对大家会有用的,这个版本是基于7.8的。
    做负载或者压力测试时,很多人选择使用了Loadrunner测试工具。该工具的基本流程是先将用户的实际操作录制成脚本,然后产生数千个虚拟用户运行脚本(虚拟用户可以分布在局域网中不同的PC机上),最后生成相关的报告以及分析图。但是在录制脚本的过程中会遇到很多实际的问题,比如不同的用户有不同的使用数据,这就牵涉到参数的设置问题。本文就Loadrunner中参数的设置进行说明,希望对大家有所帮助。
       
    在录制程序运行的过程中,VuGen(脚本生成器) 自动生成了包含录制过程中实际用到的数值的脚本。如果你企图在录制的脚本中使用不同的数值执行脚本的活动(如查询、提交等等),那么你必须用参数值取代录制的数值。这个过程称为参数化脚本。
       
    本文主要包括如下内容:理解参数的局限性、建立参数、定义参数的属性、理解参数的类型、为局部数据类型设置参数的属性、为数据文件设置参数的属性、从已经存在的数据库中引入数据。
       
    除了GUI,以下的内容适合于各种类型的用户脚本。
    一、关于参数的定义

       
    在你录制程序运行的过程中,脚本生成器自动生成由函数组成的用户脚本。函数中参数的值就是在录制过程中输入的实际值。
        例如,你录制了一个
    Web应用程序的脚本。脚本生成器生成了一个声明,该声明搜索名称为“UNIX”的图书的数据库。当你用多个虚拟用户和迭代回放脚本时,也许你不想重复使用相同的值“UNIX”。那么,你就可以用参数来取代这个常量。结果就是你可以用指定的数据源的数值来取代参数值。数据源可以是一个文件,也可以是内部产生的变量。
       
    用参数表示用户的脚本有两个优点:
     可以使脚本的长度变短。
     可以使用不同的数值来测试你的脚本。例如,如果你企图搜索不同名称的图书,你仅仅需要写提交函数一次。在回放的过程中,你可以使用不同的参数值,而不只搜索一个特定名称的值。
       
    参数化包含以下两项任务:
     在脚本中用参数取代常量值。
     设置参数的属性以及数据源。
        参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。另外,不是所有的函数都可以参数化的。

     

    二、参数的创建
       
    可以指定名称和类型来创建参数。不存在对脚本中参数个数的限制。在Web程序的用户脚本中,你可以使用如下过程在基于文本的脚本视图中创建参数。或者,也可以在基于图标的树形视图中创建参数。
       
    在基于文本的脚本视图中创建一个参数:
    1、
     将光标定位在要参数化的字符上,点击右键。打开弹出菜单。
    2、
     在弹出菜单中,选择“Replace with a Parameter”。选择或者创建参数的对话框弹出。
    3、
     在“Parameter name”中输入参数的名称,或者选择一个在参数列表中已经存在的参数。
    4、
     在“Parameter type”下拉列表中选择参数类型。
    5、
     点击“OK”,关闭该对话框。脚本生成器便会用参数中的值来取代脚本中被参数化的字符,参数用一对“{}”括住。
        注意:在参数化
    CORBA或者General-Java 用户脚本的时候,必须参数化整个字符串,而不是其中的部分。另外注意:除了Web或者WAP,缺省的参数括号对于任何脚本都是 {}”。你可以在“General Options”对话框中的“Parameterization”标签(Tools>General Options)中定义参数括号种类。
    6、
     用同样的参数替换字符的其余情况,选中参数,点击右键,弹出菜单。从弹出的菜单中,选择“Replace More Occurrences”。搜索和替换对话框弹出。“Find What”中显示了你企图替换的值。“Replace With”中显示了括号中参数的名称。选择适当的检验框来匹配整个字符或者大小写。如果要搜索规则的表达式(.!?等等),选中“Regular Expression”检验框,然后点击“Replace”或者“Replace All”。
        注意:小心使用“
    Replace All”,尤其替换数字字符串的时候。脚本生成器将会替换字符出现的所有情况。
    7、
     如果想用以前定义过的参数来替换常量字符串的话,选中该字符串,点击右键,然后选择“Use Existing Parameter”,子菜单“Use Existing Parameters”弹出。从子菜单“Use Existing Parameters”选择参数,或者用“Select from Parameter List”来打开参数列表对话框。
        注意:如果用以前定义过的参数来替换常量字符串的话,那么,使用“
    Parameter List”非常方便。同时,还可以查看和修改该参数的属性。
    8、
     对于已经用参数替换过的地方,如果想取回原来的值,那么,就在参数上点击右键,然后选择“Restore Original value”。
        在
    Web用户脚本的树形视图中创建参数:
    1
    、将光标定位在企图参数化的地方,点击右键,从弹出的菜单中选择“Properties”。则相关的属性对话框打开。
    2、点击在要参数化的参量的旁边的“
    ABC”形状的图标。“Select or Create Parameter”对话框打开。
    3、在“
    Parameter name”中输入参数的名称,或者从列表中选择一个已经存在的参数。
    4、在“
    Parameter type”中输入参数的类型。
    5、点击“
    OK”关闭该对话框。用户脚本生成器会用参数来替换最初的字符串常量,并用一个表格形状的图标替换“ABC”形状的图标。
    6、要恢复参数化以前的值,点击图标,然后从弹出的菜单中选择“
    Undo Parameter”,则以前的值便会重现。

     

    三、定义参数的属性
       
    创建参数完成后,就可以定义其属性了。参数的属性定义就是定义在脚本执行过程中,参数使用的数据源。在Web用户脚本中,你既可以在基于文本的脚本视图中定义参数属性,也可以在基于图标的树形视图中定义参数属性。下面的过程将教你如何在基于本文的脚本视图中定义参数属性。
       
    在基于文本的脚本视图中定义参数属性步骤:
    1、
     在参数上点击右键,有菜单弹出。
    2、
     在弹出的菜单中,选择“Parameter Properties”。参数属性对话框打开,显示和当前参数类型相关的属性。
    3、
     输入参数的属性值。
    4、
     点击“Close”关闭参数属性对话框。
        在
    Web用户脚本的树形视图中定义参数的属性:
    1、
     将关标定位在参数上,然后点击右键,选择“Properties”。属性对话框打开。
    2、
     点击要定义属性的参数旁边的表格形状按钮,点击右键,选择“Parameter Properties”。参数属性对话框打开,和参数类型相关的属性显示出来。
    3、
     输入参数的属性。
    4、
     点击“Close”关闭参数属性对话框。
       
    使用参数列表:
      使用参数列表可以在任意时刻查看所有的参数,创建新的参数、删除参数,或者修改已经存在参数的属性。
    1、
     点击参数列表按钮或者用“Vuser>Parameter List”。参数列表对话框打开。
    2、
     要创建新的参数,点击“New”按钮。新的参数则被添加在参数树中,该参数有一个临时的名字,你可以给它重新命名,然后回车。设置参数的类型和属性,点击“OK”,关闭参数列表对话框。
        注意:不要将一个参数命名为“
    unique”,因为这个名称是用户脚本生成器本身的。用户脚本生成器创建新的参数,但是不会自动用该参数在脚本中替换任意选中的字符串。
    3、
     要删除已有的参数,那么,要先从参数树中选择该参数,点击“Delete”,然后确认你的行为即可。
    4、
     要修改已有参数,那么,要先从参数树中选择该参数,然后编辑参数的类型和属性。

    四、理解参数的类型
      在你定义参数属性的时候,要指定参数值的数据源。你可以指定下列数据源类型的任何一种:
    Internal Data――
     虚拟用户内部产生的数据。
    Data Files 
    ――存在于文件中的数据。可能是已存在的文件或者是用脚本生成器新创建的。
    User-Defined Functions――
     调用外部DLL函数生成的数据
      
    Internal Data包括以下几种:
    1
    、 Date/Time
      Date/Time用当前的日期/时间替换参数。要指定一个Date/Time格式,你可以从菜单列表中选择格式,或者指定你自己的格式。这个格式应该和你脚本中录制的Date/Time格式保持一致。
    2
    、 Group Name
      Group Name 用虚拟用户组名称替换参数。在创建scenario的时候,你可以指定虚拟用户组的名称。当从用户脚本生成器运行脚本的时候,虚拟用户组名称总是None
    3
    、 Load Generator Name
      Load Generator Name用脚本负载生成器的名称替换参数。负载生成器是虚拟用户在运行的计算机。
    4. Iteration Number
      
    Iteration Number用当前的迭代数目替换参数。
    5
    、 Random Number
      Random Number用一个随机数替换参数。通过指定最大值和最小值来设置随机数的范围。
    6
    、 Unique Number
      Unique Number用一个唯一的数字来替换参数。你可以指定一个起始数字和一个块的大小。
    7
    、 Vuser ID
      Vuser ID用分配给虚拟用户的ID替换参数,ID是由Loadrunner的控制器在scenario运行时生成的。如果你从脚本生成器运行脚本的话,虚拟用户的ID总是-1

    五、数据文件
      数据文件包含着脚本执行过程中虚拟用户访问的数据。局部和全局文件中都可以存储数据。可以指定现有的ASCII文件、用脚本生成器创建一个新的文件或者引入一个数据库。在参数有很多已知值的时候数据文件非常有用。数据文件中的数据是以表的形式存储的。一个文件中可以包含很多参数值。每一列包含一个参数的数据。列之间用分隔符隔开,比如说,用逗号。
      对数据文件设置参数属性
      如果使用文件作为参数的数据源,必须指定以下内容:文件的名称和位置、包含数据的列、文件格式,包括列的分隔符、更新方法。
      如果参数的类型是“
    File”,打开参数属性(Parameter Properties)对话框,设置文件属性如下:
    1、
     在“File path”中输入文件的位置,或者点击“Browse”指定一个已有文件的位置。缺省情况下,所有新的数据文件名都是“parameter_name.dat”,注意,已有的数据文件的后缀必须是.dat
    2、
     点击“Edit”。记事本打开,里面第一行是参数的名称,第二行是参数的初始值。使用诸如逗号之类的分隔符将列隔开。对于每一新的表行开始一行新的数据。
      注意:在没有启动记事本的情况下如果想添加列,就在参数属性对话框中点击“
    Add Col”,那么“Add new column”对话框就会弹出。输入新列的名称,点击“OK”。脚本生成器就会添加该列到表中,并显示该列的初始值。
    3、
     在“Select Column”部分,指明包含当前参数数据的列。你可以指定列名或者列号。列号是包含你所需要数据的列的索引。列名显示在每列的第一行(row 0)。
    4、
     在“Column delimiter”中输入列分隔符,你可以指定逗号、空格符等等。
    5、
     在“First data line”中,在脚本执行的时候选择第一行数据使用。列标题是第0行。若从列标题后面的第一行开始的话,那就在“First data line”中输入1。如果没有列标题,就输入0
    6、
     在“Select next row”中输入更新方法,以说明虚拟用户在脚本执行的过程中如何选择表中的数据。方法可以是:连续的、随机的、唯一的、或者与其它参数表的相同行。
      6.1、
     顺序(Sequential):该方法顺序地给虚拟用户分配参数值。如果正在运行的虚拟用户访问数据表的时候,它会取到下一行中可用的数据。
      6.2、
     随机(Random):该方法在每次迭代的时候会从数据表中取随机数
      6.3、
     使用种子取随机顺序(Use Random Sequence with Seed):如果从Loadrunner的控制器来运行scenario,你可以指定一个种子数值用于随机顺序。每一个种子数值在测试执行的时候代表了一个随机数的顺序。无论你何时使用这个种子数值,在scenario中同样的数据顺序就被分配给虚拟用户。如果在测试执行的时候发现了一个问题并且企图使用同样的随机数序列来重复测试,那么,你就可以启动这个功能(可选项)。
      6.4、
     唯一(Unique):Unique方法分配一个唯一的有顺序的值给每个虚拟用户的参数。
      6.5 、与以前定义的参数取同一行(
    Same Line As <parameter>):该方法从和以前定义过的参数中的同样的一行分配数据。你必须指定包含有该数据的列。在下拉列表中会出现定义过的所有参数列表。注意:至少其中的一个参数必须是SequentialRandom或者Unique
        如果数据表中有三列,三个参数定义在列表中:
    id1name1title1,如下:。
    ID Name Title
    132 Kim Manager
    187 Cassie Engineer
    189 Jane VP
        对于参数
    id1,你可以指示虚拟用户使用Random方法,而为参数name1title1就可以指定方法“Same Line as id1”。所以,一旦ID132”被使用,那么,姓名(Name)“Kim”和职位(Title)“Manager”同时被使用。

    7、
    Updta value on数据的更新方法

    7.1、
    Each iteration――每次反复都要取新值

    7.2、
    Each occurrence――只要发现该参数就重新取值

    7.3、
    Once――在所有的反复中都使用同一个值

    8、
    When out of values超出范围:(选择数据为unique时才可用到)

    8.1、
    Abort Vuser――中止

    8.2、
    Continue in a cyclic manner――继续循环取值

    8.3、
    Continue with last value――取最后一个值

    9、
    Allocate Vuser values in the Controller在控制器中分配值:(选择数据为unique时才可用到)

      9.1、
    Automatically allocate block size――自动分配

      9.2、
    Allocate()values for each Vuser――指定一个值

    六、从已存在的数据库中导入数据
      Loadrunner允许你利用参数化从已经存在的数据库中导入数据。可以使用下列两种方式之一:
    1、
     使用Microsoft Query(要求在系统上先安装MS Query)。
    2、
     指定数据库连接字符串和SQL语句。
        用户脚本生成器在从数据库中导入数据的过程中提供了一个向导。在向导中,你指明如何导入数据-通过
    MS Query创建查询语句或者直接书写SQL语句。在导入数据以后,以.dat为后缀并作为正规的参数文件保存。要开始导入数据库中数据的过程,在参数属性对话框中点击“Data Wizard”,则,数据库查询向导弹出。
      要创建新的查询
    1、
     选择“Create new query”。如果需要MS Query的帮助,选择“Show me how to use Microsoft Query”,然后点击“Finish”。
    如果你还没有安装
    Microsoft QueryLoadrunner会提示你这个功能不可用。在进行之前,从Microsoft Office中安装MS Query
    2、
     Microsoft Query中遵循以下步骤,导入期望的表和列。
    3、
     在完成数据的导入后,选择“Exit and return to Virtual User Generator”,然后点击“Finish”。在参数属性对话框中数据库记录以data文件的形式显示出来。
    要在
    MS Query中编辑并查看数据,选择“View data or edit in Microsoft Query”。若要结束,则选择“File>Exit and return to Virtual User Generator”返回到脚本生成器。
    4、
     在“Select Column”部分,指定包含当前参数数据的列可以指定列号或者列名。注意:列标题默认为第0行(row 0)。
    5、
     从“Select next row”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是:SequentialRandomUnique或者Same Line As。其中每一项的含义文章前面已经讲述,就不再赘述。
    6、
     如果选择“Advance row each iteration”,虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。
      要指定数据库连接或者
    SQL语句
    1、
     选择“Specify SQL Statement”,然后点击“Next”。
    2、
     点击“Create”指定一个新的连接字符串。选择数据源的窗口弹出。
    3、
     选择已有的数据源,或者点击“New”创建一个新的数据源。向导将提示你穿过创建ODBC数据源的过程。在完成后,连接字符串就会在连接字符串框中显示出来。
    4、
     SQL框中,输入或者粘贴SQL语句。
    5、
     点击“Finish”继续SQL语句并导入数据。数据库记录将以data文件的形式显示在参数属性框中。
    6、
     在“Select Column”部分中,指定包含当前参数数据的列。你可以指定列号或者列名。
    7、
     从“Select next row”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是:SequentialRandomUnique或者Same Line As
    8、
     如果从Update out of values中,选择“each iteration”,虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。

     

  • 231/212>

    数据统计

    • 访问量: 28703
    • 日志数: 46
    • 建立时间: 2007-06-09
    • 更新时间: 2009-01-07

    RSS订阅

    Open Toolbar