100，关联函数的ORD参数

1）     当ORD=all时，则参数变成一个数组。

2）     当ORD等于一个数字时，则参数不是数组，因为指定了次数。

3）     如果参数为一个数组，则其中元素用fid_1,fid_2表示。

101，Web_reg_save_param() 关联函数。

1）     search ：返回信息的查询范围。可以是headers，body，noresource，all（缺省）

2）     ORD：说明是第几次出现的左边界子串的匹配项才是需要的内容。缺省值是1，如为all，则将所有找到的内容存储在数组中。

3）     当参数有多个值时，加上ord=all ，后可获得所有的数值。

4）     Saveoffset：当找到匹配项后，从第几个字母开始存储到参数中。

Web_reg_save_param(

“session1”,”LB=name=userSession value=”,”RB=”,”ORD=ALL”,LAST

);

Web_url()

Lr_output_message(“%s”,lr_eval_string(“{session1_1}”));

102，模拟浏览器设置：

Simulate browser cache 选项。

浏览器可以存储些从远程服务器磁盘中下载html/jpg等文件，使下次访问时速度更快，这称为缓存。

默认缓存模拟是开启的，并发测试时，每个用户都使用自己的缓存并且从缓存中检索图片等。

当缓存被设置为禁用后，虚拟用户将忽略所有的缓存功能并且在每一次请求的时候下载所有的资源。

什么时候不需要清除缓存？

生成测试数据。

模拟测试一个公司内部相同的用户群使用时等情况。

应需要要求，测试被测系统能够达到的最大压力（最大吞吐量）。如系统在框架阶段，就进行测试，想知道该系统未来能够承受的最大压力。

清除缓存？

网络应用， 每次用户都是不同的用户群体。

每次迭代，用户都是以没有缓存的状态开始，所以此时需要从远程服务器得到所有文件资源。

结论：仅仅通过设置清除缓存和不清楚缓存，事物性能测试的结果就会有很大差别，每次用户都是不同的人员。

性能测试分析：

一，  何时需要进行性能测试分析？

1）     如果性能测试结束后，所有的结果数据均正常或者符合需求指标，则不需要分析。

2）     如果测试结果有问题，则需要分析。

二，  性能测试分析的情况及过程

1，     如果测试结果没有问题，则不需要分析。

2，     如果测试结果中存在较小的问题，则需要从analysis 中查看问题原因，一般容易解决，这需要对结果报告有所了解。

3，     如果第2步无法解决问题，则分析的过程比较复杂。

1）     如果一个测试结束后，发现某事物响应时间过长（13s），该如何解决（该问题假如第2步没有解决）？

2）     首先通过analysis中的页面诊断图（网页细分图）去查找响应时间长在哪里。响应时间=客户端时间+网络时间+服务器时间。该种情况下，绝大部分都是服务器的瓶颈。

3）     通过监控被测系统的所有服务器的性能资源，即服务器资源图，通过该图，可以轻松的判断出那台服务器不正常。

4）     服务器一般分为应用服务器（也叫中间件）和数据库服务器。

5）     如果应用服务器有问题，修改一些参数即可。

6）     大部分的情况下都是数据库服务器的问题。这种情况下一般需要部署专门的服务器监控工具，如oracle的监控工具quest 、lab128 。 可以轻松的找到底层数据库问题，如索引、甚至sql语句的问题，进而进行调优，提升被测系统的性能。

三，  页面诊断图包括：

1）     页面诊断图

页面组件：也称页面元素，指构成页面的组成部分，如文字、视频、音频、动画等。

网页细分图流程：

1，     通过查看网页细分图，发现下载时间细分图中占时间比例最大是first buffer 时间。

2，     通过查看first buffer 图， 发现占该图中时间比例最大一般是server time  服务器时间。

3，     网页的大小是网页中所有组件的和。

4，     页面细分综合图的读图顺序：在实际项目中，一般是先看默认的第一张（得出时间长在第一次缓冲），再看最后一张（得出时间花费在第一次缓冲的服务器端。 ）

2） 页面组件细分图（page component breakdown）

页面中每个元素的平均响应时间占整个页面响应时间的百分比。

3）     页面组件细分图（随时间变化）：（page component breakdown over time）

整个测试过程中，任意一秒内页面中每个元素的响应时间。

如在run time 中设置了browser cache ，则页面中的资源文件只在第一次下载，后面的页面响应时间不包括这些元素的时间，这在page component breakdown 中显示不出来，通过over time图可以看出来。

设置了brower cache ：这个图是，前高后低，后面基本成直线状。

4）     页面下载时间细分图（page download time breakdown）

页面中每个元素的响应时间分割图，响应时间被分隔为以下几个部分：

1，    DNS resolution（DNS 解析时间）：

浏览器访问网站时，一般用域名，需要DNS服务器把这个域名解析成ip ，这个过程就是域名解析时间。

在局域网内直接使用ip访问，则不存在该时间。

2，    connection （连接时间）：

解析出web server的ip地址后，浏览器请求发送到web server ，然后浏览器和web server 之间需要建立一个初始化http连接，服务器需要做2件事：一是建立连接，二是分配进程，建立该连接的过程就是connection时间。

3，    first buffer（第一次缓冲时间） ，

显示从初始HTTP请求到成功收回来自web 服务器的第一个数据包为止所经过的时间。

第一次缓冲时间度量是很好的web服务器延迟和网络滞后指示器。

注意：由于缓冲区大小最大为8k ，因此第一次缓冲时间可能也是完成元素下载所需的时间。

4，    receive（接收时间） ，

从浏览器收到第一个字节起，直到成功收到最后一个字节所经历的时间，可以和组件大小结合，判断网络质量。

1）     和客户端关系：如果服务器发送过来大量的数据包，但是客户端接收有问题，甚至无法全部接收。

2）     和服务器也有关系：服务器可能发送慢。

3）     如果receive 时间过长，先查看网络是否存在问题， 在看客户端问题（页面上包括很多图片，而且图片很大，最大达163k ，） 这样就会造成receive时间过长。 分析：一张图片163k ，相当于0.2M，当1000用户并发，则0.2M*1000=200M , 网速一般是10Mb（1Byte = 8 bits ），200M /(10Mb/8)=150s 左右， 给被测系统造成很大的性能问题。

使用bmp类型图片，不可以。因为bmp基于无损压缩，图片中每个像素都是24bits，则1024*798*24bits=所以这种类型的图片无论是一张白纸还是一张色彩斑斓的图片，大小相似。 都很大。

JPG----基于有损压缩，图片中存储像素直接的色彩差值，即如果一张白纸会比色彩图片的大小小很多。

5，    SSL  handshaking（ssl握手时间），

显示建立SSL连接所用的时间。此时刻后，客户端和服务器之间的所有通信都被加密。

SSL握手度量仅适用于HTTPS通信。

 

6，    client（客户端时间） ，

请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的处理时间或者客户端其他方面引起的延迟。

 

7，    FTP authentication（FTP验证时间） ，

仅限于FTP服务器测试

8，    error（错误时间）

从发送HTTP请求，到web server 返回一个HTTP错误信息需要的时间

5）     页面下载时间细分图（随时间变化）：（page download time breakdown over time）

在整个测试过程中，任意一秒内页面中每个元素的响应时间分割图。

6）     第一次缓冲细分时间图

Time to first buffer 第一次缓冲时间：

1，     网络时间：定义为从发送第一个http请求那一刻直到收到确认为止，所经过的平均时间。

2，     服务器时间：定义为从收到初始HTTP请求确认直到成功收到来自web服务器的第一次缓冲为止，所经过的平均时间。

3，     注意：由于要从客户端测定服务器时间，因此，发送初始HTTP请求到发送第一个缓冲区这一段时间内如果网络性能发生变化，则网络时间可能会影响此测定。因此，所显示的服务器时间是一个估计值，可能不太准备，因为包含了回来的网络时间。

7）     第一次缓冲细分时间图（随时间变化）

8）     已下载组件大小图（downloaded component size KB）

页面中每个元素的大小KB ， 通过它可以直接看出那些组件比较大，并需要进一步优化，以提高性能。

9）每张图和随时间变化图的区别：

--非时间变化图注重的是宏观的表现。

--随时间变化图注重的是元素在测试过程中的微观细节表现。

--一般测试中查看的顺序：先宏观了解，再微观研究细节。

四，  LR监视的性能计数器

1，     Processor

%processor time ： 处理器执行非空闲线程的时间百分比，如果该值持续超过95% ， 怀疑瓶颈是CPU  。

处理器时间的阈值（正常范围）：对于一个系统而言，如果%processor time 的平均值小于85% ，则一般没有问题。如果其平均值超过85% 或者其值持续超过95% ，则怀疑CPU瓶颈。

对于阈值，一般不同公司不一样，不同项目也不一致，一般情况小于70% 到 85% 都视为正常。

如果%processor time 偶然走高，达到100% ， 要看其平均值，一般没问题。

2，     System

Processor queue length ： 线程单元中的处理器队列的即时长度，所有处理器都使用单一队列（线程在该队列中等待处理器进行循环），此长度不包含当前正在执行的线程。

性能测试过程中，双核处理器一般视为2个CPU 。

处理器队列的阈值是：小于等于n+1，其中n是处理器的个数。

总结：判断处理器瓶颈的方法：

1）     如果processor queue length 显示的队列长度保持不变（>=n+1）个并且处理器的利用率%processor time 超过90% ，那么很有可能存在处理器瓶颈。

2）     如果发现processor queue length 的长度超过n + 1 ， 而处理器的利用率却一直很低，那么或许更应该解决处理器阻塞问题，这时处理器性能一般不是瓶颈。

3，     memory

要监视内存不足的状况，请从以下的对象计数器开始：

1）      Available Mbytes ： 当前系统的可用内存（以M为单位），至少要有1%的物理内存。 如果系统的可用内存小于1%  ， 则有可能内存存在瓶颈。

2）     当处理器向内存指定位置请求一页面数据或代码出现错误，就构成一个page fault 。

如果该页在内存的其他位置找到，该错误被称为软错误，用transition fault / sec 计数器衡量。

如果该页必须从磁盘重新读取时，被称为硬错误，许多处理器可以在存在大量软错误的情况继续操作，但是硬错误可能导致明细拖延。 一般来讲，硬错误（单位个数）的阈值为内存1%，即2g内存，硬错误不要超过20个，否则要引起注意。

3）     page fault /sec 是处理器每秒钟处理的错误页，包括软硬错误。

4）     page reads /sec 是为了解决硬错误，从磁盘读取的次数。 如果page reads/sec 比率持续大于物理内存1%，表示可能内存不足。

5）     pages/sec 是指为解析硬错误，从磁盘读取或写入磁盘的页数。

4，     system

context switches / sec ：指计算机上的所有处理器，全都从一个线程转换到另一个线程的综合速率。

为了避免错误，必须保证在恢复一个任务之后，其上下文环境跟即将挂起前是一样的。操作系统内核有责任通过在任务挂起前保存其上下文来确保这种情况。当任务恢复时，保存的上下文就被操作系统内核恢复到先前的执行情况。保存一个被挂起的任务的上下文并在任务恢复时恢复其上下文的处理过程就叫上下文切换context switching 。

5，     physical disk

%disk time ：指所选磁盘驱动器忙于为读或写请求提供服务所用的时间的百分比。 磁盘的使用率。

Avg.DISK queue length ：指读取或写入请求（为所选磁盘在实例间隔中队列）的平均数，该值不应该超过磁盘数的1.5-2 倍，要×××能，可增加磁盘。

Disk reads/sec ,       Disk writes/ sec ： 物理磁盘上每秒钟磁盘读写次数， 两者相加，应小于磁盘设备最大容量。 该值如果超过几十M ，或者上百M, 则考虑磁盘瓶颈。

avg.disk sec/read ：读数据所用时间

avg.disk sec/write ：写数据所用时间

性能调优的原则：尽量减少磁盘IO ， 因为磁盘IO 如果较大， 会严重影响系统的性能。

5.1如何确定磁盘瓶颈？

下面假设在有4块硬盘的RAID5中观察到的Physical Disk性能对象的部分值： （如何查看电脑有几块硬盘？？通过我的电脑---属性---设备管理---磁盘驱动器，有几个就是几个磁盘）

Avg. DiskQueue Length 12  队列长度

Avg. DiskSec/Read .035    读数据所用时间ms

Avg. DiskSec/Write .045    写数据所用时间ms

DiskReads/sec 320        每秒读数据量

DiskWrites/sec 100        每秒写数据量

Avg. DiskQueue Length，12/4=3，每块磁盘的平均队列建议不超过2。  

Avg. DiskSec/Read一般不要超过11～15ms。  

Avg. DiskSec/Write一般建议小于12ms。  

从上面的结果，我们看到磁盘本身的I/O能力是满足我们的要求的，原因是因为有大量的请求才导致队列等待，这很可能是因为你的SQL语句导致大量的表扫描所致。在进行优化后，如果还是不能达到要求，下面的公式可以帮助你计算使用几块硬盘可以满足这样的并发要求：

Raid 0 -- I/Os per disk = (reads +writes) / number of disks

Raid 1 -- I/Os per disk = [reads +(2 * writes)] / 2

Raid 5 -- I/Os per disk = [reads +(4 * writes)] / number of disks

Raid 10 -- I/Os per disk = [reads +(2 * writes)] / number of disks

我们得到的结果是：(320+400)/4=180，这时你可以根据公式①来得到磁盘的正常I/O值。假设现在正常I/O计数为125，为了达到这个结果：720/125=5.76。就是说要用6块磁盘才能达到这样的要求。

但是上面的Disk Reads/sec和Disk Writes/sec是个很难正确估算的值。因此只能在系统比较忙时，大概估算一个平均值，作为计算公式的依据。另一个是你很难从客户那里得到Seek time、 Rotational latency参数的值，这也只能用理论值125进行计算。

6，     network interface

byte total /sec ： 为发送和接收字节的速率，包括帧字符在内。

判断网络连接速率是否是瓶颈， 可以用该计数器的值和目前网络的宽带比较。 该值的阈值：该值* 8 /1024/1024 换算成M 之后，再与网络宽带的一半进行比较，如果小于宽带的一半， 则一般认为网络没有瓶颈。 1Byte = 8bits ，而宽带的单位为bits 。

五，  资源实例分析

1，     判断cpu瓶颈：

1）     如果processor queue length 显示的队列长度保持不变（>=n+1）个并且处理器的利用率%processor time 超过90% ，那么很有可能存在处理器瓶颈。

2）     如果发现processor queue length 的长度超过n + 1 ， 而处理器的利用率却一直很低，那么或许更应该解决处理器阻塞问题，这时处理器性能一般不是瓶颈。

3）     %processor time 平均值大于95% ， processor queue length 大于n+ 1 ， 通过此过程可以判断cpu存在瓶颈，需要扩展。

2，     性能实例分析：

1）     系统中硬件的瓶颈比软件的瓶颈容易解决， 但大部分情况下， 都不是硬件问题，都是表现为硬件，实际是软件瓶颈引起的，如程序代码或是sql 等。

3，     判断内存泄漏的问题

如果发生内存泄漏，process :  private bytes 计数器和 process  :   working set 计数器的值往往会升高， 同时avaiable Mbytes 的值会下降。内存泄漏应该是一个长时间的测试过程来检验的。

process :  private bytes ：指不能与其他处理共享的、已分配的当前字节数。当内存泄漏时，该值会增高。

4，     判断应用程序的问题

吞吐量降低， cpu使用率高， context switches /sec 已经持续超过15000 ， 说明程序的上下文切换比较频繁，需要调优。

5，     分析原则 ： 分段排除法很有效

服务器硬件瓶颈。

网络瓶颈（局域网可以不考虑）

服务器操作系统瓶颈（参数配置）

中间件瓶颈（参数配置，数据库和web服务器）

应用瓶颈（sql语句， 数据库设计， 算法， 业务逻辑）

6，