1、去掉“启用第三方浏览器扩展”

　　打开IE8，找到“工具 -> Internet选项 -> 高级 -> 浏览 -> 启用第三方浏览器扩展*”，取消选中后重新启动IE8浏览器。就是使用了这个方法解决的SysFader错误！成功。

1．  在LoadRunner的Virtual User Generator中增加SQL SERVER的环境变量：在Run-time Settings-Java Environment Settings-Classpath中增加msbase.jar、mssqlserver.jar、msutil.jar这三个包。

2．  在Virtual User Generator中选择Java Vuser协议

3．  输入以下内容：

   public int action() {

        try{

             Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver");

                      Connection conn=DriverManager.getConnection("jdbc:microsoft:sqlserver://192.168.1.145:1433;databaseName=fund","sa","password");

             String sql="select * from(select distinct a.NewsTextID,a.PUBLISHDATE, a.Title,ROW_NUMBER() OVER (ORDER BY a.NewsTextID desc) AS ROWID from fund.dbo.NewsText a left join fund.dbo.CategoryInfoLink_bocom b on a.NewsTextID = b.INFOID where b.categoryid like '01%' )c WHERE ROWID>=110 and ROWID<=130 order by c.NewsTextID desc";//这就是在测试的SQL语句

             PreparedStatement pstmt=conn.prepareStatement(sql);

 

           //6 执行语句

            pstmt.execute();

            //7 程序提交

         

            pstmt.close();

            conn.close();

        }

        catch(Exception e){

                      }

               return 0;

       }//end of action   

4．记得Licsene的问题，就可以直接测试SQL SERVER了，相应的测试任何的数据库都可以用这种方法。

在目前我看到的资料当中，频繁换页是内存导致性能问题的主要原因。而频繁换页主要是由可用内存不够 或 分配给sql server 的内存不够导致的，以下将分别对这些方面进行探讨。
频繁换页：
        换页简单的说就是页在内存 和 磁盘之间交换（将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间）。相对来说，内存读较快，而磁盘读要消耗较多的时间。并且频繁换页也消耗不少的磁盘 和 cpu 的处理时间。
 
SQL Server 使用内存有两种情况：
 
第一种情况： 动态改变它的内存需求。
        默认情况下，SQL Server 会依据可获得的系统资源动态改变它的内存需求。如果 SQL Server 需要更多的内存，它会要求操作系统确定是否有空闲的物理内存可用，并使用可用的内存。若 SQL Server 不再需要当前分配给它的内存，它就将内存释放给操作系统。当 SQL Server 动态使用内存时，它要求系统定期地检测可用的物理内存数量。SQL Server 根据服务器活动增大或收缩高速缓冲存储器，以使可用物理内存保持在 4 MB 到 10 MB 之间。这就避免了系统进行换页操作。
        [也就是说，这种情况下SQL SERVER 本身不会使物理可用内存小于4M，如果比较长的时间内都小于4M的话，则要看一下是不是该服务器上其它应用程序有问题]
 
 第二种情况：限制使用内存
        使用 set working set size 为sql server保留等于服务器内存设置的物理内存空间。即使是sql server 进程此时是空闲的，系统也不会将 SQL Server 页交换出去。
        使用min server memory 保证sql server 使用的最小内存。SQL Server 启动时不立即分配 min server memory 中所指定的内存量。但是，当内存使用由于客户端负荷而达到该值后，SQL Server 将无法从已分配的缓冲池中释放内存。
        使用max server memory 则防止 SQL Server 使用多于指定数量的内存，这样剩余的可用内存可以快速运行其它应用程序。SQL Server 启动时不立即分配 max server memory 中所指定的内存。内存使用随 SQL Server 的需要而增长，直到达到 max server memory 中所指定的值。SQL Server 无法超过该内存使用值，除非增加 max server memory 值。
        第一种情况比较适用于服务器专做sql server服务器的情况，第二种情况适用于为在同一台计算机上运行的其它应用程序保留一定的内存以便于快速响应。（另：如果想动态分配sql server 的内存，则不要设置set working set size 选项，使用默认值即可。至于这些参数如何设置参见另外的文档）
    
        监视 SQL Server 所使用的内存和计数器有助于确定： 
        是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。 
        是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。 
        SQL Server 需要从磁盘读取数据的频率。与其它操作相比，例如内存访问，物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。 

磁盘的读写（关注的部分）分为：sql server 数据的读写和换页. 
        sql server 在操作时，如果由换页造成磁盘忙于读写且性能下降的，不能说明此操作导致磁盘出现了瓶颈，而是说可能内存不足，先应解决内存不足的问题，然后再看磁盘的读写速率是否有问题。如果是由sql server 读写数据造成的性能瓶颈的，则说明要更换磁盘系统了。
 
 
监视的参数：
 
Memory:Page Faults/sec 
        每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存指定工作集中立即使用。
        如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。
 
PhysicalDisk:% Disk Time计数器监视磁盘忙于读/写活动所用时间的百分比。
 
PhysicalDisk:Current Disk Queue Length有多少系统请求在等待访问磁盘。等待 I/O 请求的数量。
 
        如果 PhysicalDisk:% Disk Time 计数器的值很高（大于 90%），则应再查看PhysicalDisk:Current Disk Queue Length的值，该值应该保持在不超过组成物理磁盘的轴数（大多数磁盘只有一个轴，独立磁盘冗余阵列 (RAID) 设备通常有多个轴）的 1.5 到 2 倍（也有说阀值：主轴数加 2），否则，说明磁盘可能是瓶颈。
 
对磁盘逻辑分区的监视：
   Logical Disk:Disk Write Bytes/sec
   Logical Disk:Disk read Bytes/sec
 
        如果在同一硬盘上有多个逻辑分区，使用 Logical Disk 计数器而非 Physical Disk 计数器。查看逻辑磁盘计数器有助于确定哪些文件被频繁访问。
        通常，Ultra Wide SCSI 磁盘每秒可以处理 50 到 70 次 I/O 操作。
 
对sql server 使用磁盘的监视：
        SQL Server:Buffer Manager Page Reads/sec 和 Page Writes/sec 计数器来监视sql server 对磁盘的读写
 
        若这些计数器的值将要达到硬件 I/O 子系统的容量极限，则需要减小这些值，方法是调整应用程序或数据库以减少 I/O 操作（如索引覆盖、索引优化或规范化），增加硬件的 I/O 容量或添加内存。
 
参考（硬盘读写速率）：
        现在的硬盘理论上可以支持到每秒80MB 的速率，但在实际运行时往往是达不到的，较好的情况下恒定读写速率可以达到每秒20MB 左右，这已经是一个非常理想的指标了.

web_url
语法：
        Int Web_url(const char *name, const char * url, <Lists of Attributes>, [EXTRARES,<Lists of Resource Attributes>,LAST)

返回值
        成功时返回LR_PASS (0)，失败时返回 LR_FAIL (1)。

参数：
        Name：VuGen中树形视图中显示的名称，在自动事务处理中也可以用做事务的名称。

        url：页面url地址。

        List of Attributes

        EXTRARES：分隔符，标记下一个参数是资源属性的列表了。

        List of Resource Attributes

        LAST：属性列表结束的标记符。

说明
        Web_url根据函数中的URL属性加载对应的URL，不需要上下文。

        只有VuGen处于URL-based或者HTML-based（此时A scrīpt containing explicit URLs only选项被选中时）的录制模式时，web_url才会被录制到。

        可以使用web_url 模拟从FTP服务器上下载文件。web_url 函数会使FTP服务器执行文件被真实下载时的操作。除非手工指定了"FtpAscii=1"，下载会以二进制模式完成。

        在录制选项中，Toos—Recording Option下，Recording选项中，有一个Advanced HTML选项，可以设置是否录制非HTML资源，只有选择了“Record within the current scrīpt step”时，List of Resource Attributes才会被录制到。非HTML资源的例子是gif和jpg图象文件。

        通过修改HTTP头可以传递给服务器一些附加的请求信息。使用HTTP头允许请求中包含其他的内容类型（Content_type），象压缩文件一样。还可以只请求特定状态下的web页面。

        所有的Web Vusers ，HTTP模式下的WAP Vusers或者回放模式下的Wireless Session Protocol（WSP），都支持web_url函数。

web_image
语法：
        Int web_image (const char *StepName, <List of Attributes>, [EXTRARES, <List of Resource Attributes>,] LAST );

返回值
        成功时返回LR_PASS (0)，失败时返回 LR_FAIL (1)。

参数：
        StepName：VuGen中树形视图中显示的名称，在自动事务处理中也可以用做事务的名称。

        List of Attributes（服务器端和客户端映射的图片）：SRC属性是一定会被录制到的，其他的ALT、Frame、TargetFrame、Ordinal则是有的话会被录制到。

1、ALT：描述图象的元素。用鼠标指向图象时，所浮出来的文字提示。

2、SRC：描述图象的元素，可以是图象的文件名. 如： button.gif。也可以使用SRC/SFX来指定图象路径的后缀。所有拥有相同此后缀的字符串都会被匹配到。

3、Frame：录制操作时所在的Frame的名称。

4、TargetFrame：见List of Attributes的同名参数。

5、Ordinal：参见Web_link的同名参数。

        List of Attributes（客户端映射的图片）：

1、AreaAlt：鼠标单击区域的ALT属性。

2、AreaOrdinal：鼠标单击区域的顺序号。

3、MapName：图象的映射名。

        List of Attributes（服务器端映射的图片）：尽管点击坐标不属于属性，但还是以属性的格式来使用。

1、Xcoord：点击图象时的X坐标。

2、Ycoord：点击图象时的Y坐标。

        EXTRARES：分隔符，标记下一个参数是资源属性的列表了。

        List of Resource Attributes：参见List of Resource Attributes一节。

        LAST：属性列表结束的标记符。

说明
        web_image模拟鼠标在指定图片上的单击动作。此函数必须在有前置操作的上下文中使用。

        在Toos—Recording Option，如果录制级别设为基于HMTL的录制方式时，web_image才会被录制到。

        web_image支持客户端（client-side）和服务器端server-side的图片映射。

        在录制选项中，Toos—Recording Option下，Recording选项中，有一个Advanced HTML选项，可以设置是否录制非HTML资源，只有选择了“Record within the current scrīpt step”时，List of Resource Attributes才会被录制到。非HTML资源的例子是gif和jpg图象文件。

        通过修改HTTP头可以传递给服务器一些请求附加信息。使用HTTP头允许请求中包含内容，如同压缩文件一样。还可以只请求特定状态的web页面。

        web_image支持Web虚拟用户，不支持WAP虚拟用户。

例子
        下面的例子模拟用户单击Home图标以回到主页（黑体部分）：

web_url("my_home", "URL=http://my_home/", LAST)；

web_link("Employees", "Text=Employees", LAST)；

web_image("Home.gif", "SRC=../gifs/Buttons/Home.gif", LAST)；

web_link("Library", "Text=Library", LAST)；

web_image("Home.gif", "SRC=../../gifs/buttons/Home.gif", LAST)；

        下面的例子模拟用户在客户端映射的图片上单击：

web_image("dpt_house.gif",

       "Src=../gifs/dpt_house.gif",

       "MapName=dpt_house",

       "AreaOrdinal=4",

       LAST)；

        下面的例子模拟用户在服务端映射的图片上单击：

web_image("The Web Developer's Virtual Library",

       "Alt=The Web Developer's Virtual Library",

       "Ordinal=1",

       "XCoord=91",

       "YCoord=17",

       LAST)；

        下面是一个使用文件名后缀的例子：它指定了dpt_house.gif作为后缀，所以象../gifs/dpt_house.gif、/gifs/dpt_house.gif、gifs/dpt_house.gif、/dpt_house.gif等都会匹配到。

web_image("dpt_house.gif",
        "Src/sfx=dpt_house.gif", LAST)；

web_link
语法：
        Int web_link (const char *StepName, <List of Attributes>, [EXTRARES, <List of Resource Attributes>,] LAST )；

返回值
        成功时返回LR_PASS (0)，失败时返回 LR_FAIL (1)。

参数：
        StepName：VuGen中树形视图中显示的名称，在自动事务设置中也被用做事务名称。

        List of Attributes：支持下列的属性：

1.      Text：超链接中的文字，必须精确匹配。

2.      Frame：录制操作时所在的Frame的名称。

3.      TargetFrame、ResourceByteLimit：见List of Attributes一节。

4.      Ordinal：如果用给出的属性（Attributes）筛选出的元素不唯一，那么VuGen使用此属性来指定其中的一个。例如：“SRC=abc.gif”，“Ordinal=3”标记的是SRC的值是“abc.gif”的第3张图片。

        EXTRARES：表明下面的参数将会是list of resource attributes了。

        LAST：结尾标示符。

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

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

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

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

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

　　注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。
　　在某一点上，执行队列开始增长，因为服务器上所有的线程都已投入使用，传入的请求不再被立即处理，而是放入队列中，当线程空闲时再处理。51Testing软件测试网/}
随着负载的增加，系统执行队列长度的曲线

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

随着负载的增加，系统中两个事务的响应时间曲线
　　注意，在执行队列开始增长的同时，响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。
　　为了获得真正可再现的结果，应该将系统置于相同的高负载下。为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以再现。
　　您可能要问的一个问题是：“如何度量结果？”对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。这称为“flat”测试。
flat测试的情况（所有的用户都是同时加载的）
　　与此相对应的是“ramp-up”测试。
ramp-up测试的情况（在测试期间，用户以稳定速度（每秒x个）增加）
　　ramp-up测试中的用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。因此，flat运行是获得基准测试数据的理想模式。
　　这不是在贬低ramp-up测试的价值。实际上，ramp-up测试对找出以后要运行的flat测试的范围非常有用。ramp-up测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。
　　Flat测试的问题是系统会遇到“波动”效果。
  一次flat测试中所测得的系统吞吐量的曲线（单位：页面/秒）
　　注意波动的出现，吞吐量不再是平滑的。
　　这在系统的各个方面都有所体现，包括CPU的使用量。
   一次flat测试中所测得的系统CPU使用量随时间变化的曲线

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

一次flat测试中所测得的系统执行队列的曲线
　　注意，每隔一段时间就会出现一个波形。执行队列曲线与上面的CPU使用量图非常相似。

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

一次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性能降低的有关迹象？测试运行（不停地重复“峰值/空闲”周期）的时间越长，您对系统的长期健康状况就越了解。

sar -P ALL   cpu使用情况

sar -a 文件访问情况
dirblk/s  定位文件时被目录访问守护进程读取的快（512b）的个数
iget/s    i节点查找系统进程被调用次数
lookuppn/s 目录查找进程找到v节点，并获取路径名的次数

sar -b  buffer的活动情况，包括传输、访问、和命中率
bread/s、bwrit/s 块IO操作的数量
lread/s、lwrit/s 逻辑 IO请求的个数
pread/s、pwrit/s 裸设备IO操作数量
%rcache、%rwrit cache命中率，计算共式为：((lreads-breads)/lreads)*100

sar -c 系统调用情况
exec/s、fork/s  调用和执行系统调用总数
sread/s、swrit/s read/writ 系统调用次数
rchar/s、wchar/s 被read/writ系统调用的字符数量
scall/s  系统调用总数

sar -k 内核进程活动情况
kexit/s 中断的内核进程数
kproc-ov/s 由于进程数的限制无法创建内核进程的次数
ksched/s 被作业分派的内核进程数

sar -m 消息队列和信号灯活动情况
msg/s  IPC消息队列活动情况
sema/s 信号灯活动情况

sar -d 磁盘读写情况

sar -q 队列统计信息
run-sz 内核线程处于运行队列的平均数
%runocc 最近时间段运行队列占用百分比
swpq-sz 内核线程等待 页面调度的平均数
%swpocc 交换队列最近活动情况

sar -r 页面调度信息
cycle/s 每秒中页面置换次数
fault/s 每秒中page fault次数
slots   在页空间中空闲页数量
odio/s 每秒中不使用页面空间的磁盘io数

sar -v 进程、内核线程、i节点、和文件表 的状态

sar-w 上下文切换次数

sar -y tty设备活动情况
canch/s  tty输入队列中规范的字符数
mdmin/s  tty modem 中断
outch/s  输出队列字符数
rawch/s  输入队列字符数
revin/s  tty接收中断
xmtin/s  tty传输中断

如果CPU的使用率接近100％（usr＋system），可以视为是CPU瓶颈。而如果相当大的时间都花费在IO等待上，那就意味着cpu执行受到了磁盘IO的限制，而IO瓶颈可能来自于文件访问或者没有足够的内存来分配页面。
注意：系统花费在等待远程文件访问的时间不会记入io 等待时间，如果CPU和IO等待的时间都相当的低，但是响应时间又不是很满意，那应该确认系统花费多少时间在等待远程io，一直一来aix下没有命令对远程io进行分析，只能通过跟踪数据来观察。

vmstat

vmstat命令报告内核线程，虚拟内存、磁盘、陷阱、和CPU活动情况。
Kthr  线程活动情况
r 运行队列
b 等待队列

memory 虚拟和实际内存使用情况
avm  活动的虚拟页面
fre  空闲的页面，当系统内存大于64MB时，最小值MINFREE为120frames，当内存小于64MB时，最小值为内存以MB计的两倍
     MINFREE和MAXFREE值可以通过vmtune命令来查看

page  page fault和page活动情况，当在内存里分配一个页面时（非NFS或者永久文件页面），其被视为工作页面，工作页面通常包括应用堆栈、数据和其他的共享内存段。因此当一个程序栈或者数据区域需要增长时，内存会被被访问，vvm会从ram和页面空间所在设备分配空间。这就意味着在内存耗尽之前，页面空间会被使用。
re    页面输入输出列表，每秒中内存回收数量，当页面处于空闲列表且没有被再利用，它就会被回收应为没有新的IO会初始化它，也包括那些没有完成的IO操作但又被VMM使用预先读取算法调入内存的页面。
pi    从页面空间page in的页面
po    从页面空间page out的页面

fr    页面空闲（页面重置）
sr    页面被页面调度算法扫描次数
cy    页面调度算法进行调度的时钟周期

faults  陷阱和系统中断率
in    设备中断
sy    系统调用
cs    内核线程上下文切换

CPU  cpu使用情况
usr  用户进程
sys  系统进程
id   cpu空闲时间
wa   等待磁盘IO时间

准则：
r<5，b≈0，
如果fre<MINFREE，将会出现连续不断的页面调度，将导致系统性能问题。
对于page列，re，pi，po，cy维持于比较稳定的状态，PI率不超过5，如果有pagin发生，那么关联页面必须先进行pageout在内存相对紧张的环境下pagein会强制对不同的页面进行steal操作。如果系统正在读一个大批的永久页面，你也许可以看到po和pi列会出现不一致的增长，这种情景并不一定表明系统负载过重，但是有必要对应用程序的数据访问模式进行见检查。在稳定的情况下，扫描率和重置率几乎相等，在多个进程处理使用不同的页面的情况下，页面会更加不稳定和杂乱，这时扫描率可能会比重置率高出。

faults列，in，sy，cs会不断跳跃，这里没有明确的限制，唯一的就是这些值最少大于100

cpu列，us，sys，id和wa也是不确定的，最理想的状态是使cpu处于100%工作状态，单这只适合单用户的情况下。
如果在多用户环境中us＋sys》80，进程就会在运行队列中花费等待时间，响应时间和吞吐量就会下降。wa>40表明磁盘io没有也许存在不合理的平衡，或者对磁盘操作比较频繁，

【摘要】 本文在分析市场上已有的商用的性能测试工具实现原理和体系架构的基础上，提出了利用现有的开源代码构建开源的性能测试工具思路。

【关键词】 性能测试、 Vugen 、 Conductor 、 Player 、 Analysis

•  性能测试的意义

追求更高的质量和更高的性能是人类的天性。 “ 更高，更快，更强 ” 的奥运会是对人类自身运动能力的测试。同样，人类也在追求我们工作生活中不可或缺的 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 。

•  Proxy 二次捕获的问题

Vugen 的 Proxy 方式需要解决的一个问题是二次捕获数据包的问题。

早期的网络服务器程序对外提供一个固定端口，客户端仅仅和这个端口通讯就可以了。这对于 proxy 录制非常容易。但是现在很多服务器程序为了提高对客户端并发量的支持，采用两个端口通讯的方式。如下图所示：

 

整个通讯的过程如下：

•  第一步：客户端将请求发往 Proxy 录制器。

•  第二步： Proxy 录制器将请求发往真正的服务器的指定端口，即图中的 3200 端口。

•  第三步：服务器机器的 3200 端口返回数据包给 Proxy 录制器。该数据包中包含了下一次通讯的目的地址，形式为 IP:Port 。很显然，这里的 IP 数据为真正服务器的 IP 地址。

•  第四步， Proxy 录制器把请求返回给客户端。

•  第五步，客户端根据提供的 IP:Port 信息直接把请求发往真正的服务器，不再经过 Proxy 录制器。

•  第六步：以后的通讯只是客户端和服务器之间的通讯了， Proxy 录制器是无法捕获这些通讯包了。

因此一般的 Proxy 录制器只能捕获头两个收发的数据包。 这个问题更一般的情形的例子是 HTTP 的 redirection 功能。第二次通讯可能发往另外一台机器了。 Proxy 录制器必需解决这个问题。

•  关联的问题

客户端和服务器之间的通讯，有一部分是数据是动态的，每次通讯都不一样。 Proxy 录制器在录制的时候是无法区分哪些是静态的信息，哪些是动态的信息，所有的信息都以 hard-coded 的方式记录下来。但是在回放的时候，如果有些信息不改变，那么脚本是不能执行成功的。考虑如下情形：

 

如上图所示，用户 jojo 以 jojo/bean 的账号 / 口令登录某一 web 服务器，查询某产品的信息，由 Vugen 录制交易的全部通讯包。 web 服务器返回给 jojo 一个动态的会话 ID: SessionID@12345 ，作为这次登录的会话标识。由于 Vugen 无法知道哪些信息是动态的，它会照单全收的方式，把所有的数据就记录下来。接着 jojo 根据 Web 服务器告诉他的 SessionID 去查询产品列表，交易可以正常执行下去。

我们会观察到，当 Vugen 根据捕获的通讯包生成 http 脚本的时候， SessionID 是 Hard-coded 的，即 “ 写死 ” 在程序里面的。当我们不加修改的回放该脚本的时候，会出现什么问题呢？如下图所示：  

按照录制时候的脚本， jojo 以 jojo/bean 登录后， Web 服务器返回给 jojo 一个动态会话 ID: SessionID@23456 ，这个值已经不是录制时候产生的 SessionID@12345 了，而是新的值： SessionID@23456 。那么脚本根据记录的 SessionID 的值，仍然会使用 SessionID@12345 去执行下面的查询交易。由于会话 ID 是有时效性的，用户退出系统后，其 SessionID 会失效，那么，服务器会给出一个 “SessionID 失效 ” 的错误，从而导致脚本无法正常执行下去。

对于上面的问题的通用解决方法如下图所示：

 

在第一次从服务器得到 SessionID 的时候把其放在一个变量 <session_id> 里面，在后面脚本访问服务器的语句里面，把所有的 ”SessionID@12345” 替换为变量 <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“ 小而灵活 ” 的哲学思想，在一个大的框架下面开发或者利用已经存在的开源工具软件制造出一个个灵活的部件。当把这些部件组合起来以后，就是一个功能完整、质量可靠的性能测试工具箱。

在拜读了段念的《软件性能测试过程详解与案例剖析》一书后，对各种性能测试类型有了豁然开朗的感觉。
网上关于性能测试类型方面一直都讨论不休并有多种见解，以下是根据书上描述和个人经验对测试侧重点做了进一步探索，不对之处请指正。

    我们所说的性能测试是一种广义上的说法，包括了以下各种不同的性能测试类型，每种测试类型都带着明确的测试目的。

性能测试（Performance Testing）
    原文摘要：性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生成性能要求。即在特定的运行条件下验证系统的能力状况。
    个人理解：主要强调在固定的软硬件环境、确定的测试业务场景下，其主要意义是获得系统的性能指标。

负载测试（Load Testing）
    原文摘要：在给定的测试环境下，通过在被测系统上不断增加压力，直到性能指标超过预定指标或某种资源使用已经达到饱和状态，目的是了解系统性能容量和处理能力极限。负载测试的主要用途是发现系统性能的拐点，寻找系统能够支持的最大用户、业务等处理能力的约束。
    个人理解：也可以理解为扩展性测试（Scalability Testing），即在固定测试环境，在其它测试角度（负载方面）不变的情况下，变化一个测试角度并持续增加压力，查看系统的性能曲线和处理极限，以及是否有性能瓶颈存在（拐点）。主要意义是从多个不同的测试角度去探测分析系统的性能变化情况，配合性能调优。测试角度可以是并发用户数、业务量、数据量等不同方面的负载。

压力测试（Stress Testing）
    原文摘要：测试系统在一定饱和状态下系统能够处理的会话能力，以及是否出现错误，一般用于稳定性测试。
个人理解：可以理解为资源的极限测试。测试关注在资源处于饱和或超负荷的情况下，系统能否正常运行，是一种在极端压力下的稳定性测试。其主要意义是通过测试调优保证系统即使在极端的压力情况下也不会出错甚至系统崩溃。
    网友补充：压力测试的目的是调查系统在其资源超负荷的情况下的表现，尤其是对系统的处理时间有什么影响。这类测试在一种需要反常数量、频率或资源的方式下执行系统。目标是通过极限测试方法，发现系统在极限或恶劣环境中自我保护能力。主要验证系统的可靠性。

配置测试（Configuration Testing）
    原文摘要：通过对被测系统的软硬件环境的调整，了解各种不同环境对性能影响的程度，从而找到系统各项资源的最有分配原则。
    个人理解：主要用于性能调优，在经过测试获得了基准测试数据后，进行环境调整（包括硬件配置、网络、操作系统、应用服务器、数据库等），再将测试结果与基准数据进行对比，判断调整是否达到最佳状态。

并发测试（Concurrency Testing）
    原文摘要：模拟并发访问，测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题。
    个人理解：测试目的并非为了获得性能指标，而是为了发现并发引起的问题。

可靠性测试（Reliability Testing）
    原文摘要：通过给系统加载一定的业务压力的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。
    个人理解：需要和压力测试区分开，两者的测试环境和测试目的不一样。压力测试强调在资源极限情况下系统是否出错，可靠性测试强调在   一定的业务压力下长时间（如24×7）运行系统，关注系统的运行情况（如资源使用率是否逐渐增加、响应是否是否越来越慢），是否有不稳定征兆

 性能测试是 Web 应用系统的一项重要质量保证措施。在现实中，很多 Web 性能测试项目由于性能测试需求定义不合理或不明确，导致性能测试项目不能达到预期目标或进度超期。本文针对 Web 应用系统的技术架构和系统使用特点，探讨如何有效实施性能测试过程，并重点介绍如何分析获得合理的性能测试需求，最终对 Web 应用系统性能进行科学、准确的评估。
1 引言
        基于Web服务器的应用系统由于提供浏览器界面而无须安装，大大降低了系统部署和升级成本，得以普遍应用。目前，很多企业的核心业务系统均是Web应用，但当Web应用的数据量和访问用户量日益增加，系统不得不面临性能和可靠性方面的挑战。因此，无论是Web应用系统的开发商或最终用户，都要求在上线前对系统进行性能，科学评价系统的性能，从而降低系统上线后的性能风险。
        在很多性能测试项目中，由于不能合理定义系统的性能测试需求，不能建立和真实环境相符的负载模型，不能科学分析性能测试结果，导致性能测试项目持续时间很长或不能真正评价系统性能并提出性能改进措施。
        本文在总结许多Web应用系统性能测试实践经验和教训的基础上，从与性能测试工具无关的角度介绍Web应用系统性能测试的方法和实施过程，以及如何定义合理的性能测试需求。
1.1 术语定义
        性能测试：通过模拟大量浏览器客户端同时访问Web服务器，获得系统的性能数据。
        虚拟用户：模拟浏览器向Web服务器发送请求并接收响应的一个进程或线程。
        响应时间：浏览器向Web服务器提交一个请求到收到响应之间的间隔时间。
        思考时间：浏览器在收到响应后到提交下一个请求之间的间隔时间。
        请求成功率：Web服务器正确处理的请求数量和接收到的请求数量的比。
        吞吐量：单位时间内Web服务器成功处理的HTTP页面或HTTP请求数量。
        在线用户：用户通过浏览器访问登录Web应用系统后，并不退出该应用系统。通常一个Web应用服务器的在线用户对应Web应用服务器的一个Session。
        并发用户数：Web服务器在一段时间内为处理浏览器请求而建立的HTTP连接数或生成的处理线程数。当所有在线用户发送HTTP请求的思考时间为零时，Web服务器的并发用户数等于在线用户数。
1.2 Web应用系统技术架构
        Web应用系统的前端为浏览器，后台为Web服务器（如Apache，Microsoft Internet Information Server），浏览器和Web服务器之间的交互基于HTTP协议。HTTP协议本身是无连接的，Web服务器通过Session机制来建立一个浏览器所发出的先后连接之间的关联。通过实验证明，当浏览器客户端在首次访问Web服务器后，如果该浏览器客户端不发送后续请求，服务器维持该浏览器客户端的Session变量所消耗的系统资源非常小。
2 Web应用系统性能测试过程
        标准的Web应用系统性能测试过程包括确定性能测试需求，开发性能测试脚本，定义性能测试负载模型，执行性能测试和形成性能测试报告。本章将分别介绍上述过程，并通过举例说明如何完成每一环节。
2.1 确定性能测试需求
        科学定义Web应用系统性能测试需求对一个成功的性能测试非常重要。通常，Web应用系统的性能测试需求有如下两种描述方法。
2.1.1 基于在线用户的性能测试需求
        该需求描述方法主要基于Web应用系统的在线用户和响应时间来度量系统性能。当Web应用系统在上线后所支持的在线用户数以及操作习惯（包括操作和请求之间的延迟）很容易获得，如企业的内部应用系统， 通常采用基于在线用户的方式来描述性能测试需求。以提供网上购物的Web应用系统为例，基于在线用户的性能测试需求可描述为：10个在线用户按正常操作速度访问网上购物系统的下定单功能，下定单交易的成功率是100%，而且90%的下定单请求响应时间不大于8秒；当90%的请求响应时间不大于用户的最大容忍时间20秒时，系统能支持50个在线用户。
2.1.2 基于吞吐量的性能测试需求
        该需求描述方法主要基于Web应用系统的吞吐量和响应时间来度量系统性能。当Web应用在上线后所支持的在线用户无法确定，如基于Internet的网上购物系统，可通过每天下定单的业务量直接计算其吞吐量，从而采取基于吞吐量的方式来描述性能测试需求。以网上购物系统为例，基于吞吐量的性能测试需求可描述为：网上购物系统在每分钟内需处理10笔下定单操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。
2.2 开发性能测试脚本
        在确定Web应用系统性能测试需求后，就要根据性能测试需求中确定的功能开发性能测试脚本。比如，针对前面定义的网上购物系统的性能测试需求，将开发下定单功能的性能测试脚本。
        性能测试脚本是描述单个浏览器向Web服务器发送的HTTP请求序列。每个性能测试工具（如IBM Rational Performance Tester， LoadRunner）所提供的测试脚本语法是不同的。测试人员利用性能测试工具可从头手工编写测试脚本，也可以通过录制浏览器和Web服务器之间的网络通信数据而自动形成测试脚本。
        任何性能测试工具都不能保证录制形成的性能测试脚本的正确性，测试人员应通过在单用户下运行性能测试脚本对其正确性进行验证。测试脚本不正确的一个重要原因就是脚本的数据关联不正确，也就是并没完全建立一个测试请求和前面的响应内容之间的关联。测试脚本HTTP请求和响应之间的数据关联是否正确的一个重要标准是单用户运行脚本，脚本能完成期望的功能。
        在完成性能测试脚本的数据关联后，需要对脚本进行参数化，也就是把脚本中的某些请求数据替换成变量，变量的值来于一个独立的数据文件，从而保证在多虚拟用户运行脚本的情况下，每个虚拟用户所提交的数据是不同的。
        此外，为了测试Web应用的可靠性，还需要对请求所收到的响应进行验证（比如验证响应的HTTP返回码或验证响应的内容），便于性能测试完成后统计请求成功率。
2.3 建立性能测试负载模型
        性能测试负载模型定义了测试工具如何向Web应用系统提交请求，包括向Web应用系统发送请求的虚拟用户数，每个虚拟用户发送请求的速度和频率。针对前面介绍的网上购物系统的性能测试需求，在性能测试工具中定义的性能测试负载模型应包括如下信息：
        虚拟用户数：性能测试不仅仅是执行一次，而且每次执行时虚拟用户数也不固定，因此在性能测试负载模型中定义的虚拟用户数将在测试执行时进行设置。
        虚拟用户发送请求的思考时间和迭代次数：虚拟用户发送请求的思考时间长短是决定Web应用系统负载量的重要因素之一，而迭代次数将决定性能测试的执行持续时间。对基于在线用户的性能测试需求，将基于录制脚本时记录的思考时间，而且由于现实中不同用户访问系统的思考时间不同，可把思考时间设置为在一定范围内的随机值。对于基于吞吐量的性能测试需求，将把思考时间设置为零，此时Web应用系统的在线用户数量将等于并发用户数。同时，为了避免性能测试压力的随机性，将增加请求的迭代次数来增加测试执行持续时间，从而获得系统在稳定压力下的性能数据。
        虚拟用户启动模式：在现实中，Web应用系统的用户不太可能同时做相同的操作，因此为了让Web应用系统所承担的压力随时间均匀分布，建议虚拟用户依次启动，同时也避免大量用户同时登录造成系统阻塞。以10个虚拟用户模拟下定单为例，可设置每个虚拟用户间隔30秒启动，这样10个虚拟用户可在5分钟后完成启动，并保证10个虚拟用户不会在同一时刻下定单，从而更符合实际情况。
2.4 执行性能测试
        执行性能测试是指通过多次运行性能测试负载模型，获得系统的性能数据。在执行过程中，需利用测试工具、操作系统、系统软件（如Web Server或DB Server）提供的资源监控手段对资源进行监控和分析，帮助发现资源瓶颈，并在系统层面进行优化。同时，还需对应用进行性能分析，帮助定位应用代码中的性能问题，切实解决系统的性能问题。
2.5 形成性能测试报告
        性能测试项目的最后阶段就是向相关人员提交性能测试报告，汇报性能测试结果。在向相关人员汇报性能测试结果时，并不是性能测试报告越丰富、性能数据越多越好。好的性能测试报告是能准确、简单地传递性能测试结论，而不需太多的技术细节。
针对基于在线用户数的性能测试需求，可通过下图总结性能测试结论。其中横轴是在线用户数，纵轴是响应时间，如40在线用户访问网上购物系统时，90%的下定单请求响应时间不超过10秒。

图一：在线用户数和响应时间时间的趋势图

                                       
        针对基于吞吐量的性能测试需求，可通过下图的曲线来描述性能测试结果。以网上购物系统为例，下图描述下定单的并发用户、下定单响应时间以及吞吐量（服务器每秒处理定单笔数）之间的关系，从而快速判断系统是否能满足性能测试需求。从下图中可看出，并发用户增加，请求的响应时间也增加。服务器的吞吐量是先随并发用户数增加而增加，当吞吐量到达一定峰值后，再增加并发用户数，吞吐量会减少。原因在于当并发用户数少时，向Web服务器提交的请求量不大，服务器处理能力还有富余，所以吞吐量逐步增大；但当并发用户数超过某一值时，由于向服务器提交的请求太多，造成服务器阻塞，反而导致吞吐量减少。

图二：响应时间、吞吐量和并发用户数的趋势图

                         
3 如何获取合理的性能测试需求
        前一章介绍了Web应用系统的性能测试过程，确定性能测试需求是整个性能测试的起点和成功的重要因素。性能测试需求定义得过高，虽然确保系统上线后能满足性能需求，但可能会造成硬件资源的浪费；性能测试需求定义得过低，系统上线后可能会出现性能问题。如何通过分析系统上线后可能的用户访问行为，来获得合理的性能测试需求指标呢？
        假设现有一个基于Web的办公自动化系统（简称OA系统），该系统提供公文收发和查询功能。在部署该系统前，将对该系统进行性能测试。下面将详细介绍如何分析该OA系统的使用情况，定义合理的性能测试需求。
3.1 如何获得OA系统的在线用户数量
        在线用户数量是指在特定时间区间内，有多少用户访问Web应用系统（对应到Web服务器的Session数），根据系统可能访问用户数以及每个用户访问系统的时间长短来确定。
        对于将要部署的OA系统，通过分析获得该系统有8000个注册用户，基本上所有的用户每天（8小时工作时间）都会访问OA系统，平均在线时间（从登录OA系统到退出OA系统之间的时间间隔，也可以是多次在线时间的合计）为12分钟，那么该OA系统的平均在线数（也就是Web应用Session变量数）为200个（8000 * 0.2 / 8），假设峰值在线用户数是平均在线用户数的3倍（该倍数可根据实际情况调整），则性能测试需求的在线用户数为600。
3.2 如何确定OA系统的性能测试用例
        由于时间和资源限制，不可能对Web应用系统的所有功能进行性能测试，而是从业务的角度（如某一功能操作的用户多）和技术的角度（如某一功能虽然访问用户不多，但内部处理逻辑复杂或处理数据量大）来选择Web应用系统的特定功能作为性能测试用例。
        以OA系统为例，由于所有用户都经常公文查询功能，因此确定的性能测试用例为公文查询。
3.3 如何确定OA系统的响应时间
        响应时间的快慢直接影响了系统使用用户的满意度，采用平均响应时间来描述系统系统性能测试需求是不科学的，因为无法直接和客户的满意度挂钩。而且，在做性能测试，如果某一请求的响应时间过长或过短，将导致平均响应时间和实际情况偏离。
        以OA系统为例，定义的响应时间需求为：90%（该百分比和要求的系统用户满意度相关）的查询请求响应时间不超过8秒（该时间可根据实际情况确定）。
3.4 如何确定OA系统的交易吞吐量
        单位时间内Web应用系统需处理多少笔特定的交易可通过统计获得。以OA系统为例，假设每个用户每天（一天按8小时计算）平均会查询公文4次，那OA应用的Web服务器平均每分钟要能处理8000 * 4 / ( 60 * 8 ) = 66.67笔查询公文交易，考虑到峰值因素，要求每分钟能处理66.7 * 3=200笔查询公文交易。
3.5 OA系统性能测试需求描述
        通过前面的分析，能明确定义合理的性能测试需求。OA系统性能测试需求定义如下：
基于在线用户数的性能测试需求：600个在线用户按正常操作速度访问OA系统的查询公文功能，所有查询请求的成功率是100%，而且90%的查询请求响应时间不大于8秒。
基于吞吐量的性能测试需求：OA系统在每分钟内需处理200笔查询公文操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。
4 总结
        Web应用性能测试项目成功的关键不在于性能测试工具，而在于有效的性能测试分析方法和实践。只有切实掌握性能测试需求分析方法，性能测试实践经验，才能保证一个Web应用性能测试的成功。

 

LR只能监视它支持的服务器的资源，它支持大部分常见的服务器。
System Resource：包括windows平台，Unix平台等
Web Server：包括Apache、IIS、Sun的iplanet等
Application server：包括Weblogic、WebSphere等
Database server：包括DB2，Oracle，Sql server，Sybase等
Java： ejb，J2ee等，需要一个ejbdetector.jar文件
1.对Windows（Win2k server）的监视：
对windows的监视相对比较简单，监视前首先需要用有管理员权限的帐号连接被监
server，例如：net use  file://qa-test/  /user:donny ,输入密码。然后就可以添加计数器，
比较常用的计数器有：
Memory：Available Mbytes  物理内存的可用数（单位 Mbytes）至少要有10% 的物理内存值
Processor：%Processor Time CPU 使用率。这是查看处理器饱和状况的最佳计数器。显示所有 CPU 的线程处理时间。如果一个或多个处理器的该数值持续超过 90%，则表示此测试的负载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的 0 到 x 个实例。
Processor Queue Length：是指处理列队中的线程数，小于2。处理器瓶颈会导致该值持续大于2。
 
Context Switches/sec：如果切换次数到5000*CPU个数和10000*CPU个数中，说明它忙于切换线程
Network Interface：Bytes Total/sec 为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。
SQL Server2000：%Processor Time，CPU 使用率
General Statistics，Logins/sec，这是每秒登录到 SQL Server 的计数。
SQL Statistics： Batch Requests/sec，每秒收到的 Transact-SQL 命令批数。这一统计信息受所有约束（如I/O、用户数、高速缓存大小、请求每秒收到的 Transact-SQL 命令批数。这一统计信息受所有约束（如I/O、用户数、高速缓存大小、请求的复杂程度等）影响。
批请求数值高意味着吞吐量很好。

2.对Unix（Linux等）的监视，需要配置相应的服务器端，可以查看帮助文件，这里就只举
一个例子了。
1)  LoadRunner 如何监控Apache，需要修改apache的配置文件httpd.conf.
 
<Location /server-status>
SetHandler server-status
Order deny,allow
Allow from all
Allow from .your-domain.com
</Location>
把这节加在httpd.conf里面， restart apache即可。

页面分解
如果某个transaction的时间过长，为了分析问题出在哪里？就可以利用页面分解了，它可
以把每个页面分解成：

DNS解析时间：浏览器访问一个网站的时候，一般用的是域名，需要dns服务器把这个域名解析为IP，这个过程就是域名解析时间，如果我们在局域网内直接使用IP访问的话，就没有这个时间了。
Connection：解析出Web Server 的IP地址后，浏览器请求被送到了Web Server，然后浏览器和Web Server 之间需要建立一个初始化HTTP连接，服务器端需要做2件事：一是接收请求，二是分配进程，建立该连接的过程就是connection时间。
First Buffer：建立连接后，从Web Server 发出第一个数据包，经过网络传输到客户端，浏览器成功接受到第一字节的时间就是First Buffer。这个度量时间不仅可以表示Web Server 的延迟时间，还可以表示出网络的反应时间。
Receive：从浏览器接收到第一个字节起，直到成功收到最后一个字节，下载完成止，这段时间就是receive时间。
其他的时间还有SSL Handshaking（SSL 握手协议，用到该协议的页面比较少）、
ClientTime（请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的think time 或者客户端其他方面引起的延迟）、Error Time（从发送了一个HTTP 请求，到Web Server发送回一个HTTP 错误信息，需要的时间）

为了确认问题缘由到底是服务器还是网络，选择“Time to First Buffer(缓冲器) Breakdown”发现network时间比Server时间要高的多，从而确定问题是network引起的。

有朋友开始投诉了，说我已经好长一段时间没有写技术类文章了。汗颜，积极改进。刚好今天在群里有同行遇到一个关于 LR 参数化的问题，其实这个问题以前也遇到过，所以就顺便把我的想法整理一下发上来。

当时我们要做的是使用性能测试工具模拟大量用户在线点播 Movie 的业务，这个点播 Movie 的业务在第一次点播成功后，如果同一用户再次点播同一 Movie，系统的处理流程与第一次点播是不同的。另外，我们在执行测试时，通常都会连续执行几个小时以获得尽可能多的样本数据。

那么问题就在于，一方面我们不能在一次测试中重复的读取同样的数据，另一方面准备几十万甚至上百万的数据工作量也太大，而且还涉及到相关的基础数据的准备。那么，我们该如何在使用 LoadRunner 连续长时间执行测试，保证参数化的数据充足而又不会重复呢？

其实方法很简单。无论上 LR 还是 jmeter\" href="http://jakarta.apache.org/jmeter/" target=_blank>JMeter，都提供了将多个参数的取值存放在同一个文件中，或者每个参数单独指定一个文件的功能，针对上面这个例子，我们只是简单的创建了两个文件和三个参数，第一个参数和第二个参数（用户账号和密码）存放在第一个文件中，有1000条记录；第三个参数（Movie 的 ID）存放在第二个文件中，有999条记录。然后在测试工具中设置参数取值的读取为顺序读取并且循环读取。通过这种简单的方法组合出了大量的数据。

问题被解决了。

本文是《LoadRunner没有告诉你的》系列的第六篇，我将继续保持“无废话”的原则，用尽可能简洁、明确的语句来表述我对性能测试的看法和经验。在这篇文章中，我们要讨论的是如何获取“有效的”性能需求。

      

一个实际的例子

为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。

这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的 ^_^

l         系统总容量达到日委托6000万笔，成交9000万笔

l         系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔

l         实际股东帐号数3000万

 

这个例子中已经包括几个明确的需求：

l         最佳并发用户数需求：每秒7300笔

l         最大并发用户数需求：峰值处理能力达到每秒10000笔

l         基础数据容量：实际股东帐号数3000万

l         业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型

 

什么是“有效的”性能需求？

要想获得有效的性能需求，就要先了解什么样的需求是“有效的”。有效的性能需求应该符合以下三个条件。

1.     明确的数字，而不是模糊的语句。

结合上面的例子来看，相信这个应该不难理解。但是有的时候有了数字未必就不模糊。例如常见的一种需求是“系统需要支持5000用户”，或者“最大在线用户数为8000”。这些有数字的需求仍然不够明确，因为还需要考虑区分系统中不同业务模块的负载，以及区分在线用户和并发用户的区别。关于这方面的内容，在下面两篇文章中的留言内容中有精彩的讨论：

http://www.cnblogs.com/jackei/archive/2006/11/15/560578.html

http://www.cnblogs.com/jackei/archive/2006/11/16/561846.html

2.     有凭有据，合理，有实际意义。

通常来说，性能需求要么由客户提出，要么由开发方提出。对于第一种情况，要保证需求是合理的，有现实意义的，不能由着客户使劲往高处说，要让客户明白性能是有成本的。对于第二种情况，性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜测，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的——本文后面的部分会介绍获得可用的数据和计算公式的方法。

3.     相关人员达成一致。

这一点非常关键。如果相关人不能对性能需求达成一致，可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。这里要注意“相关人员”的识别，通常项目型的项目的需要与客户方的项目经理或负责人进行确认，产品型的项目需要与直属领导或者市场部进行确认。如果实在不知道该找谁确认，那就把这个责任交给你的直属领导；如果你就是领导了，那这领导也白当了 ^_^

 

如何获得有效的性能需求

上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可行的。这几种方法由易到难排列如下：

1.       客户方提出

这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。

2.       根据历史数据来分析

根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统，可以根据已有系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不同行业、不同应用、不同的业务是有各自的特点的。例如，购物网站在平时的负载主要集中在晚上，但是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了周末，还有周一到周五的一早一晚上下班时间。

3.       参考历史项目的数据

如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。

4.       参考其他同行类似项目的数据

如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。

5.       参考其他类似行业应用的数据

如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。

6.       参考新闻或其他资料中的数据

最后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，通常可以通过各种新闻媒体找到一些可供参考的数据，但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中，可以根据新闻中公布的各省、各市，以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。

 

又一块砖抛出来了，希望大家在看完之后也有更多的玉丢过来 ^_^

 

提到性能测试，相信大家可以在网上找到很多种不同的定义、解释以及分类方法。不过归根结底，在大多数情况下，我们所要做的性能测试的目的是“观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能”。

本文是《LoadRunner没有告诉你的》系列的第五篇，在这篇文章中，我希望可以跟大家一起来探讨“如何将性能测试应用到软件开发过程的各个阶段中，如何通过尽早的开展性能测试来规避因为性能缺陷导致的损失”。

因此，本文的结构也将依据软件开发过程的不同阶段来组织。

另外，建议您在阅读本文前先阅读本系列文章的第三篇《理发店模型》和第四篇《理解性能》。51Testing软件测试网 jx3t9Q!w&l?/Sq

 

需求阶段

我们不可能将一辆设计载重为0.75吨的皮卡改装成载重15吨的大型卡车，如果你面对的正是这样的问题，那么恐怕你只能重做一辆，而且客户不会为你之前那辆付钱。对于一个已经完成的应用系统来说也是如此。

如果我们在系统结构确定之前就能够了解到系统的将要面对的压力，用户的使用习惯和使用频度，我们就可以更早也更有效的提前解决或预防可能发生的性能缺陷，也将会极大的减少后期返工和反复调优所带来的工作量。如果我们预期到系统的容量将会不断的增长，我们还可以给出相应的解决方案来低成本的解决这类问题，就像上面那辆皮卡，也许你可以有办法把20辆皮卡捆在一起，或者把15吨的东西分由20辆来运。

 

分析设计阶段

系统性能的优化并不是要等待整个系统全部集成后才能开始的，早在分析设计阶段，我们就可以开始考虑系统的技术架构和数据库部分的优化。

数据库通常位于整个系统的最底层，如果直到系统上线前才发现因为数据库设计不合理而导致性能极差，通常使用任何一种方法来优化都已经于事无补了。要避免这类问题，最常见的做法是在数据库结构确定后，通过工具或脚本向数据库中注入大量的数据，并模拟各种业务的数据库操作。根据对数据库性能的观察和分析，对数据库表结构和索引进行调整以优化数据库性能。

在系统的技术架构方面，要明白先进的技术并不是解决问题的唯一方法，过于强调技术的作用反而会将你带入歧途。例如：某些业务虽然经常面临着巨大的压力，并且业务本身的复杂性决定了通过算法的优化来提高系统的性能收效甚微。但是我们知道用户对于该业务的实时性要求并不高，并且返回结果对于不同用户来说是相同的。那么我们完全可以考虑将每次请求都动态生成返回结果的方式改为每次用户请求都返回一个定期更新的静态页面。

另外，所谓“先进技术”通常都会在带来某一方面改进的同时带来另一方面的问题，未经试验就盲目的在系统中加入各种流行元素未必是最好的选择。例如ORM可以提供一些方便，但是它生成的SQL是未经优化的，有时甚至比人工编写的SQL效率更低。

最后，要知道不同厂家的设备性能是不同的，而且不同的硬件设备搭载不同的操作系统、数据库、中间件以及应用服务器，表现出来的性能也是不同的。如果有足够的资源，应当考虑提前进行软硬件平台的对比选型；如果没有足够的资源，可以考虑通过一些专业的组织或网站来获取或购买相关的评估报告。

 

编码阶段

一片树叶在哪里最难被发现？——当这片树叶落在一堆树叶里面的时候。

如果你只是在系统测试完成后才开始性能测试，那么即使发现系统存在性能缺陷，并且已经有了几个可供怀疑的对象，但是当一段因为使用了不当的算法而导致执行效率很低的代码藏身于一个庞大的系统中时，找出它是非常困难的。避免这种情况出现的方法是尽早开始核心业务代码的性能测试，重点集中在对算法和实现方法的优化上。

另外，及早开始的测试也可以帮你更容易找到内存泄漏的问题。

 

测试阶段

产品终于交到我们手上了，搭建测试环境，设计测试场景，执行测试，找到系统的最佳并发用户数和最大并发用户数，将系统进行分类，评判系统的性能表现是否满足需求中定义的目标——如果有需求的话 ^_^

如果发现系统的性能表现与预期目标相去甚远，则需要根据执行测试过程中收集到的数据来分析和识别性能瓶颈，优化系统性能。

在这个阶段还有很多值得我们深入思考和讨论的东西，在本系列后续的文章中，我们将会更多的关注这一部分的内容。

 

维护阶段

维护阶段通常遇到的问题是需要在实验室中模拟客户环境，重现在客户那里发现的缺陷并修复缺陷。相比功能缺陷，性能缺陷与某一具体环境和场景的关联更加密切，所以在测试前需要检查生产环境中各服务器的资源利用率、系统访问日志、应用服务器的日志、数据库的日志。如果客户使用了专门的系统来监测各个服务器的软硬件资源使用情况的话，检查该系统是否记录下了软硬件资源的异常或者警告。

 

与性能测试相关的其他测试

可靠性测试（Reliability Testing）    对于一个运营商级的系统来说，能够保证提供7×24的连续稳定的服务是非常重要的。当然，你可以通过一些“高可用性（High Availability）”技术方案来增强系统的可靠性，但是对于系统本身的可靠性测试是不能被忽略的。

常用的测试方法是使用一定的负载长时间向服务器加压，并观察随着加压时间的延长，响应时间、吞吐量以及资源利用率的变化。要注意的是，所使用的负载应当是系统的最佳并并发用户数，而不是最大并发用户数。

可伸缩性测试（Scalability Testing） 对于一个系统来说，在一个给定的环境下，它的最佳并发用户数和最大并发用户数是客观存在的，但是系统所面临的压力却有可能随上线时间的延长而增大。例如，一个在线购物站点，注册用户数量不断增多，访问站点查询商品信息和购买商品的人也不断的增多，我们应该用一种什么样的方案，在不影响系统继续为用户提供服务的前提下来实现系统的扩容？

一种常用的方案是使用负载均衡（Load Balance）和集群（Cluster）技术。但是在我们为客户提供这种方案之前，需要先自己进行测试，保证该技术的有效性——我们是否真的可以通过简单的增加服务器数据和修改某些参数配置，就能够使得系统的容量得到线性的增长？

可恢复性测试（Recoverability Testing）      虽然我们已经可以准确的估算出系统上线后将要面对的压力，并且可以保证系统的最佳并发用户数和最大并发用户数是足以应对这些压力的，但是这个世界上总是有些事情上我们所无法预料到的——例如9.11事件发生后，AOL的网站访问量在短时间内增长到了平时的数十倍。

我们无法保证系统可以在任何情况下都能为用户正确无误的提供服务，但是我们需要确保当意外过去后，系统可以恢复到正常的状态，并继续后来的用户提供服务——就像从未发生过任何事情一样。

如果要实现“可恢复性测试”，我们可以借助于测试工具或脚本来逐渐的增大并发用户数，直至并发用户数已经超过了系统所能承受的最大并发用户数，并导致软硬件资源利用率饱和，响应时间无限延长，大量的请求因为超过响应时间要求或无法获得响应而失败；之后，我们逐渐的减少并发用户数，并观察资源利用率、响应时间、吞吐量以及交易成功率的变化是否与预期目标一致。

 

当然，这一切的前提是在系统负载达到峰值前，Server一直在顽强的挣扎着而没有down掉 ^_^

 

性能测试，并非网络应用专属

软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的，但是软件性能和性能测试却并非网络应用的专属名词，因为单机版的应用同样需要考虑性能问题。下面举几个简单的例子来方便大家的理解：

1.               当使用Word来编辑一个500多页，并包含了丰富图表、图片和各种格式、样式信息的文档时，是否每次对大段的文字或表格的修改、删除或重新排版，都要等待系统花几秒钟的时间进行处理？

2.              当在Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，是否每次都要两三分钟才能看到结果？

3.              杀毒软件是否每次都要花费两个小时才能完成一次对所有的分区的扫描？

4.              是否每次在手机的通讯簿中根据姓名搜索某个人的联系方式都要三四秒钟才有响应？

如果大家有兴趣，也可以通过Google搜索到更多的有关单机应用性能测试的资料。

另外，从系统的视角来看，所需要关注的还包括三个与“性能”有关的属性：可靠性（Reliability），可伸缩性（Scalability）和 可恢复性（Recoverability）——我将会在本系列文章的第五篇“无处不在的性能测试”中专门讨论这三个属性的含义和相关的实践经验。

 

响应时间

上面这张图引自段念兄的一份讲义，不过我略作了些修改。从图中我们可以清楚的看到一个请求的响应时间是由几部分时间组成的，包括

C1：用户请求发出前在客户端需要完成的预处理所需要的时间；

C2：客户端收到服务器返回的响应后，对数据进行处理并呈现所需要的时间；

A1：Web/App Server 对请求进行处理所需要的时间；

A2：DB Server 对请求进行处理所需的时间；

A3：Web/App Server 对 DB Server 返回的结果进行处理所需的时间；

N1：请求由客户端发出并达到Web/App Server 所需要的时间；

N2：如果需要进行数据库相关的操作，由Web/App Server 将请求发送至DB Server 所需要的时间；

N3：DB Server 完成处理并将结果返回Web/App Server 所需的时间；

N4：Web/App Server 完成处理并将结果返回给客户端所需的时间；

从用户的角度来看，响应时间＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是从系统的角度来看，响应时间只包括(A1+A2+A3)+(N1+N2+N3+N4)。

在理解了响应时间的组成之后，可以帮助我们通过对响应时间的分析来更好的识别和定位系统的性能瓶颈。

 

吞吐量 vs. 吞吐量

在不同的测试工具中，对于吞吐量(Throughput)会有不同的解释。例如，在LoadRunner中，这个指标是以字节数为单位来衡量网络吞吐量的，而在JMeter\" href="http://jakarta.apache.org/jmeter/" target=_blank>JMeter中则是以事务数/秒为单位来衡量系统的响应能力的。不过在大多数英文的性能测试方面的书籍或资料中，吞吐量的定义使用的是后者。

 

并发用户数 ≠ 每秒请求数

这是两个容易让初学者混淆的概念。

简单说，当你在性能测试工具或者脚本中设置了100并发用户数后，并不能期望着一定会有每秒100个请求发给服务器。事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。

所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。

大概在一年前的一次讨论中，我的好友陈华第一次提到了这个模型的最初版本，经过几次讨论后，我们发现经过完善和扩展的“理发店模型”可以用来帮助我们理解很多性能测试的概念和理论，以及一些测试中遇到的问题。在最近的一次讨论后，我决定撰写一篇文章来专门讲述一下这个模型，希望可以帮助大家更好的理解性能测试有关的知识。

不过，在这篇文章中，我将会尽量的只描述模型本身以及相关的一些扩展，而具体如何将这个模型完全同性能测试关联起来，我不会全部说破，留下足够的空间让大家继续思考和总结，最好也一起来对这个模型做进一步的完善和扩展^_^ 我相信，当大家在思考的过程中有所收获并有所突破时，那种快感和收获的喜悦才真的是让人倍感振奋而且终生难忘的 ^_^

当然，我要说明的是，这个模型仅仅是1个模型，它与大家实际工作中遇到的各式各样的情况未必都可以一一对应，但是大的方向和趋势应该是一致的。

 

理发店模型

进一步理解“最佳并发用户数”和“最大并发用户数”

理发店模型的进一步扩展

相关资料

 

相信大家都进过或见过理发店，一间或大或小的铺面，1个或几个理发师，几张理发用的椅子和供顾客等待的长条板凳。

在我们的这个理发店中，我们事先做了如下的假设：

 

1.        理发店共有3名理发师；

2.      每位理发师剪一个发的时间都是1小时；

3.      我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。

 

通过上面的假设我们不难想象出下面的场景：

1.        当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；

2.      当理发店内同时有两位顾客时，就会同时有两名理发师在为顾客服务，另外1位发呆或者打杂帮忙。仍然是1小时后，两位顾客剪完头发出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；

3.      很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时；

从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。

当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。

不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着。1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。

通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。如果你可以理解上面的这些场景，就可以继续往下看了。

在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。

我想并不需要特别说明，大家也一定可以把上面的这些场景跟性能测试挂上钩了。如果你还是觉得比较抽象，继续看下面的这张图 ^_^
a)dBl!J169151Testing软件测试网x"l G1R![t

这张图中展示的是1个标准的软件性能模型。在图中有三条曲线，分别表示资源的利用情况（Utilization，包括硬件资源和软件资源）、吞吐量（Throughput，这里是指每秒事务数）以及响应时间（Response Time）。图中坐标轴的横轴从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。

在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，但是吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。

根据这种性能表现，图中划分了三个区域，分别是Light Load（较轻的压力）、Heavy Load（较重的压力）和Buckle Zone（用户无法忍受并放弃请求）。在Light Load和Heavy Load 两个区域交界处的并发用户数，我们称为“最佳并发用户数（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数（The Maximum Number of Concurrent Users）”。

当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。

对应到我们上面理发店的例子，每小时3个顾客就是这个理发店的最佳并发用户数，而每小时9个顾客则是它的最大并发用户数。当每小时都有3个顾客到来时，理发店的整体工作效率最高；而当每小时都有9个顾客到来时，前几个小时来的顾客还可以忍受，但是随着等待的顾客人数越来越多，等待时间越来越长，最终还是会有顾客无法忍受而离开。同时，随着理发店里顾客人数的增多和理发师工作时间的延长，理发师会逐渐产生疲劳，还要多花一些时间来清理环境和维持秩序，这些因素将最终导致理发师的工作效率随着顾客人数的增多和工作的延长而逐渐的下降，到最后可能要1.5小时甚至2个小时才能剪完1个发了。

当然，如果一开始就有10个顾客到来，则注定有1位顾客剪不到头发了。

 

进一步理解“最佳并发用户数”和“最大并发用户数”

在上一节中，我们详细的描述了并发用户数同资源占用情况、吞吐量以及响应时间的关系，并且提到了两个新的概念——“最佳并发用户数（The Optimum Number of Concurrent Users）”和“最大并发用户数（The Maximum Number of Concurrent Users）”。在这一节中，我们将对“最佳并发用户数”和“最大并发用户数”的定义做更加清晰和明确的说明。

对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该 保证最佳并发用户数要大于系统的平均负载。

要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么 ^_^

而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：

1.              当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；

2.             在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。

对于一个系统来说，我们应该 确保系统的最大并发用户数要大于系统需要承受的峰值负载。

如果你已经理解了上面提到的全部的概念，我想你可以展开进一步的思考，回头看一下自己以往做过的性能测试，看看是否可以对以往的工作产生新的理解。也欢迎大家在这里提出自己的心得或疑惑，继续讨论下去。

 

理发店模型的进一步扩展

这一节中我会提到一些对理发店模型的扩展，当然，我依然是只讲述现实中的理发店的故事，至于如何将这些扩展同性能测试以及性能解决方案等方面关联起来，就留给大家继续思考了 ^_^

扩展场景1：有些顾客已经是理发店的老顾客，他们和理发师已经非常熟悉，理发师可以不用花费太多时间沟通就知道这位顾客的想法。并且理发师对这位顾客的脑袋的形状也很熟悉，所以可以更快的完成一次理发的工作。

扩展场景2：理发店并不是只有剪发一种业务，还提供了烫发染发之类的业务，那么当顾客提出新的要求时，理发师服务一位顾客的时间可能会超过标准的1小时。而且这时如果要计算每位顾客的等待时间就变得复杂了很多，有些顾客的排队时间会比原来预计的延长，并最终导致他们因为无法忍受而离开。

扩展场景3：随着烫发和染发业务的增加，理发师们决定分工，两位专门剪发，一位专门负责烫发和染发。

扩展场景4：理发店的生意越来越好，理发师的数量和理发店的门面已经无法满足顾客的要求，于是理发店的老板决定在旁边再开一家店，并招聘一些工作能力更强的理发师。

扩展场景5：理发店的生意变得极为火爆了，两家店都无法满足顾客数量增长的需求，并且有些顾客开始反映到理发店的路途太远，到了以后又因为烫发和染发的人太多而等太久。可是理发店的老板也明白烫发和染发的收入要远远高于剪发阿，于是他脑筋一转，决定继续改变策略，在附近的几个大型小区租用小的铺面开设分店，专职剪发业务；再在市区的繁华路段开设旗舰店，专门为烫发、染发的顾客，以及VIP顾客服务。并增设800电话，当顾客想要剪发时，可以拨打这个电话，并由服务人员根据顾客的居住地点，将其指引到距离最近的一家分店去。

 

这篇文章就先写到这里了，希望大家在看完之后可以继续思考一下，也写出自己的心得体会或者新的想法，记下自己的不解和疑惑，让我们在不断的交流和讨论中走的更远 ^_^

数据统计分析的思路与分析结果的展示方式是同样重要的，有了好的分析思路，但是却不懂得如何更好的展示分析结果和数据来印证自己的分析，就像一个人满腹经纶却不知该如何一展雄才

^_^

一图胜千言，所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中的其他应用。

在这张图中，我们继续使用了上一篇文章——《描述性统计与结果分析》一文中的方法，对响应时间的分布情况来进行分析。上面这张图所使用的数据是通过对

Google.com 首页进行测试得来的，在测试中分别使用10/25/50/75/100 几个不同级别的并发用户数量。通过这张图表，我们可以通过横向比较和纵向比较，更清晰的了解到被测应用在不同级别的负载下的响应能力。51Testing软件测试网Nx5G!w A P

这张图所使用的数据与第一张图一样，但是我们使用了另外一个视角来对数据进行展示。表中最左侧的2000/5000/10000/50000的单位是毫秒，分别表示了在整个测试过程中，响应时间在0-2000毫秒范围内的事务数量占成功的事务总数的百分比，响应时间在2001-5000毫秒范围内的事务数量占成功的事务总数的百分比，响应时间在5001-10000毫秒范围内的事务数量占成功的事务总数的百分比，以及响应时间在10001-50000毫秒范围内的事务数量占成功的事务总数的百分比。

这几个时间范围的确定是参考了业内比较通行的“2-5-10原则”——当然你也可以为自己的测试制定其他标准，只要得到企业内的承认就可以。所谓的“2-5-10原则”，简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。

那么从上面的图表中可以看到，当并发用户数量为10时，超过95％的用户都可以在5秒内得到响应；当并发用户数量达到25时，已经有80％的事务的响应时间处在危险的临界值，而且有相当数量的事务的响应时间超过了用户可以容忍的限度；随着并发用户数量的进一步增加，超过用户容忍限度的事务越来越多，当并发用户数到达75时，系统几乎已经无法为任何用户提供响应了。

这张图表也同样可以用于对不同负载下事务的成功、失败比例的比较分析。

 

Note：上面两个图表中的数据，主要通过Excel 中提供的FREQUENCY，AVERAGE，MAX，MIN和PERCENTILE几个统计函数获得，具体的使用方法请参考Excel帮助手册。

LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题，并引申出“描述性统计”方法在性能测试结果分析中的应用。51Testing软件测试网K(f x2OICO4w

 

为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？

假如有两组测试结果，响应时间分别是 {1，3，5，10，16} 和 {5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？

假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？

为了解答上面的疑问，我们先来看一张表：51Testing软件测试网Z QN%^4?w!Z!Ni

在上面这个表中包含了几个不同的列，其含义如下：

CmdID   测试时被请求的页面

NUM      响应成功的请求数量

MEAN    所有成功的请求的响应时间的平均值

STD DEV      标准差（这个值的作用将在下一篇文章中重点介绍）

MIN              响应时间的最小值

50 th(60/70/80/90/95 th)          如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th 也是同样的含义

MAX      响应时间的最大值

我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论性的东西整理一下：

1.      90％用户响应时间在 LoadRunner中是可以设置的，你可以改为80％或95％；

2.      对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILE 函数很简单的算出不同百分比用户请求的响应时间分布情况；

3.      从上面的表中来看，对于Home Page来说，平均事务响应时间(MEAN)只同70％用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20％的用户请求的响应时间是大于这个值的；对于Page 1也是一样，假如我们确定对于Page 1 的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30％的用户请求的响应时间是超过了我们的要求的；

4.      你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的范围之内的；

5.      如果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况；

6.      在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90％或95％用户响应时间来作为度量标准，它们并不冲突。实际上，在定义某些系统的性能需求时，一定范围内的请求失败也是可以被接受的；

7.      上面提到的这些内容其实是与工具无关的，只要你可以得到原始的响应时间记录，无论是使用LoadRunner还是jmeter\" href="http://jakarta.apache.org/jmeter/" target=_blank>JMeter或者OpenSTA，你都可以用这些方法和思路来评估你的系统的性能。

 

事实上，在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说，性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识，例如数学和统计学，来帮助我们更好的分析性能数据，找到隐藏在那些数据之下的真相。欢迎各位同行高手灌水拍砖 ^_^

 loadrunner安装的问题很多，各个网站的帖子也很多，51test中就有很多。

        安装的时候基本上的问题就是安装包所在路径为汉字名称或者别的什么。

        主要说一下自己遇到的问题，和解决的方法，希望遇到的人可以绕过而行，不用在走弯路了。
       安装的问题：51Testing软件测试网 

        整个装的过程都是OK的，完成后，提示需要重启系统丢失system32下的 BHOManager.dll    DLLRegisterServer  return  error 8007007e”（我的系统是番茄花园的xp系统），当你确定以后，lr安装目录下bin中的所有dll文件都不能注册了，所以安装就失败，就这个问题，刚开始我一直没有定位好，等看了一段时候之后发现，BHOManager虽然在system32下，但是不是系统本身的dll，而是lr自己写入的（因为以前装好的lr中IE加载项中，印象是见过的）， DLLRegisterServer  return  error 8007007e 意味着没有找到BHOManager这个dll文件，或者这个dll没有注册，但是手动去注册却是报错，那现在问题基本上已经可以看出端倪了，所有的不能成功的因素，全都是BHOManager.dll没有成功注册的缘故，（找到根源就可以迎刃而解了）。

        在百度中搜索，发现如下内容:

        你问题的解决方法，我今天也遇到同样的问题，给你做回答，呵呵，这个跟双核没关系，可能是你用的也是番茄花园的xp系统把，它的atl.dll是没有注册的，导致lr的BHOManager。dll无法成功注册！！！（原理就是这些），方法如下：

附：
        我再重新安装时遇到的另一个问题。可能遇到的朋友并不多，放上来给大家参考吧。
        在安装到最后的时候遇到这样一个报错：BHOManager.dll 注册失败。
       于是在提示重启时未重启，而是去手动注册该dll文件，却弹出了另一个提示，"DLLRegisterServer in BHOManager.dll failed 

        于是到网上搜了下，终于找到了解决方法。
        1. 需要IE 6.0 及以上版本支持, 请检查你的IE浏览器是否为 6.0 以上版本。
        2. 请检查Windows系统目录中是否存在以下三个文件: msvcp60.dll, mfc42.dll, msvcrt.dll 文件, 如果有缺少,请下载并拷贝到Windows系统目录中去即可。
        3. 请查看您的系统中是否缺少 atl.dll 文件, 如果没有, 请从其他相同操作系统的机器上拷贝这个文件到Windows系统目录, 然后打开命令行窗口并在该目录下运行命令: 
       regsvr32 atl.dll
       看到成功提示后，再次手动注册BHOManager.dll（注册方法：打开命令行窗口并在该目录下运行命令regsvr32 c:\windows\system32\BHOManager.dll），提示注册成功。

        全部完成后重启电脑，该问题就解决拉 :)
        LR终于装好了。
        那就意味这，BHOManager.dll的注册是和atl.dll的注册有关，前者调用后者中的东西，只要后者成功注册，前者就可以OK解决了！呵呵~~~~世界清净了许多！！哈哈！！

        因为之前一直没有分析正确问题的所在，所以卸载和重新安装loadrunner好几次，关于卸载的一些问题，及时你按照卸载工具卸载了 loadrunner，下次装的时候还是会包license失效，解决方法，要登录到注册表regedit中（当发现报错后，立即去注册表删除下边的内容，只要有相同的就删除，这样注册码就可以再次使用了，并不会报错，呵呵）。
       删除如下内容： 
        HKEY_CLASSES_ROOT\Mercury.Lm70Control 
        HKEY_CLASSES_ROOT\Mercury.Lm70Control.1
        同时删除
        Mercury.Lm70ControlMgr
        Mercury.Lm70ControlMgr.1

        然后就使用查找功能，搜索“Mercury”，发现有Lm70Contro字样的东西都要删除掉。

        最后删除下面内容：

        HKEY_CURRENT_USER\Software\Mercury Interactive 
       HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive

        删除完成后，继续填入license，下一步，如果还是不行，继续去注册表中删除上边内容，知道没有了，就OK了。
       这些都是自己做过实际操作的内容，希望对大家有帮助。