（一）在Vusers（虚拟用户状态）中

　　1.Running Vusers（负载过程中的虚拟用户运行情况）

　　说明——系统形成负载的过程，随着时间的推移，虚拟用户数量是如何变化的，描述为（用户在几分钟左右到达了组在峰值多少个虚拟用户，负载的生成是大约每分钟增加几个用户，峰值负载持续为几分几秒）。

　　2.Rendezvous（负载过程中集合点下的虚拟用户数）

　　说明——脚本中一般要设置集合点才会产生并发，随着时间的推移各个时间点上并发用户的数目，方便我们了解并发用户数的变化情况。描述（刚开始的几分钟内，负载的并发用户都是几个，而后面变化为几个用户并发）。

　　（二）在Transactions（事务）中

　　这里给出了所有和事务相关的数据统计，方便了解被测试系统业务处理的响应时间和吞吐量。

　　1.Average Transaction Response Time（平均事务响应时间）

　　说明——反映随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。如果和前面的用户负载生成图合并在一起看，就可以发现用户负载增加对系统事务响应时间的影响规律。描述（看到响应时间是如何增长的，随着时间的推移响应时间逐渐变长，并且在不到多少时间的时候突然出现响应时间大幅下降的情况）另外事务的响应时间也不应该超过用户的最大接受范围，否则会出现系统响应过慢的问题。

　　2.Transactions per Second（每秒事务数）

　　说明——数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。描述（看到系统的TPS随着时间的变化逐渐变大，而在不到多少分钟的时候系统每秒可以处理多少个事务。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。而在几分钟以后开始出现少量的失败事务）

　　3.Transaction Summary（事务概要说明）

　　说明——通过的事务数越多，说明系统的处理能力越强；失败的事务越少，说明系统越可靠。描述（对于注册操作一共有对少次操作成功，有几次失败。可以开率结合前面的每秒错误数进一步分析为什么会出现几个注册错误，以及错误发生的时间和该时间产生错误的原因）

　　4.Transaction Performance Summary（事务性能概要）

　　说明——给出事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。描述（看到这个事务最大时间为多少S，最小时间为多少S，平均时间为多少S。柱状图的落差越小说明响应时间的波动较小，那么说明系统不够稳定。）

　　5.Transaction Response Time Under Load（在用户负载下事务响应时间）

　　说明——在负载用户增长的过程中响应时间的变化情况，起始这张图也是将Vusers和Average Transaction Response Time图做了一个Correlate Merge得到的，该图的线条越平稳，说明系统越稳定。描述（看到负载逐渐增加到几个用户时，事务的响应时间基本没有变化，而用户增加到几个开始，随着用户负载的增加响应时间也有较大的波动）

　　6.Transaction Response Time（Percentile）（事务响应时间的百分比）

　　说明——有多少比例的事务发生在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。描述（看到百分几%的事务是在几秒内）

　　7.Transaction Response Time （Distribution）（每个时间段上的事务数）

　　说明——在每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。描述（看到在所有的事务中，有多少个事务的响应时间最接近几秒，而有几个事务的响应时间最接近几秒）

　　（三）在Web Resources（网页资源信息）中

　　当Controller的Run Time Setting中Preferences下的Generated Web performance graphs选项处于开启状态时，该图表才会出现。

　　1.Hits per Second（每秒点击数）

　　说明——每秒点击数提供了当前负载重对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。描述（随着时间的增加，每秒点击数在上升，最高达到了多少次/s）。

　　2.Throughput（带宽使用）

　　说明——当前系统负载下所使用的带宽，该数据越小说明系统的贷款依赖越小，通过这个数据能确定是否出现了网络带宽的瓶颈。描述（得到醉倒的带宽峰值是多少B，远远低于100Mb的局域网带宽上限，所以系统不存在带宽瓶颈）。

　　3.HTTP Responses per Second（每秒HTTP响应数）

　　说明——每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而HTTP响应数是指服务器返回的响应数。如果服务器返回的响应数小于发出的请求数，那么说明服务器无法应答超出负载的连接请求。描述（最高峰时服务器每秒能返回接近多少个HTTP _ 200 OK的状态）。

　　4.Connections Per Second（每秒连接数）

　　说明——两种不同状态的连接数，即中断的连接和新建的连接，方便用户了解当前每秒对服务器产生连接的数量。描述（随着时间的推移，系统的连接数逐步上升，最高达到每秒几个连接）同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常这个时候服务器会返回504错误。可以通过修改服务器的最大连接数来解决问题。

　　（四）在Web Page Diagnostics（网页分析）中

　　当在场景中打开Diagnostics菜单下的Web Page Diagnostics功能，就能得到网页分析组图。通过这个图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过这个功能，可以实现对网站的前端性能分析，明确系统响应时间较长时由服务器端（后端）处理能力不足还是短连接到服务器的网络（前端）消耗导致的。

　　1、 Web Page Diagnostics（网页分析）

　　说明——添加该图先会得到整个场景运行后虚拟用户访问的Page列表，也就是所有页面下载时间列表。描述（在注册用户事务进行分析，整个负载由三个页面请求组成，其中有一个请求始终在多少秒以内，而另外几个请求时间较长并且有上升趋势，然后通过Select Page to Break Down命令选择具体的Page来获得每个请求的相关详细信息——分析如下：

　　1.Download Time下载时间分析——组成页面的每个请求下载时间——可以看到创建用户的操作由4个请求组成，其中导致注册用户较慢的主要原因是注册完成后需要等待两秒钟再刷新至论坛首页，而非注册用户本身需要消耗的时间，首页刷新慢也只是因为Client（客户端）需要消耗较多时间，同时Receive（接收）的时间也有一定的影响。

　　2.Component（Over time）各模块的时间变化——通过这个功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。随着时间的增加，首页的处理时间（最上面的一根线）从多少秒上升到了最大值多少秒，而注册英护响应时间几乎没有上升。

　　3.Download Time（Over time）模块下载时间——针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。发现首页请求的下载时间主要消耗在Client上，而多少分多少秒之前Recevie所消耗的时间在逐渐变长。

　　4.Time to Buffer（Over time）模块时间分类——列出该元素所使用的时间分配比例，是受Network Time影响的多还是Server Time影响的多。对于首页刷新的响应时间来说，主要是Network Time网络上消耗的时间，而Server Time服务器端的处理时非常优秀的。Server Time是服务器对该页面的处理时间；Network Time是指网络上的时间开销。）

　　2、 Page Download Time Breakdown（页面响应时间组成分析）

　　说明——显示每个页面响应时间的组成分析，一个页面的响应时间一般由以下内容组成：

　　Client Time客户端浏览接收所需要使用的时间，可以不用考虑。

　　Connections Time连接服务器所需要的时间，越小越好。

　　DNS Resolution Time通过DNS服务器解析域名所需要的时间，解析受到DNS服务器的影响，越小越好。

　　Error Time服务器返回错误响应时间，这个时间反映了服务器处理错误的速度，一般是Web服务器直接返回的，包含了网络时间和Web服务器返回错误的时间，该时间越小越好。

　　First Buffer Time连接到服务器，服务器返回第一个字节所需要的时间，反映了系统对于正常请求的处理时间开销，包含网络时间和服务器正常处理的时间，该时间越小越好。

　　FTP Authentication Time FTP认证时间，这是进行FTP登录等操作所需要消耗的认证时间，越短越好。

　　Receive Time接受数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。

　　SSL Handshaking Time SSL加密握手的时间，而Analysis在这里会分析得到页面请求的组成比例图，便于分析页面时间浪费在哪些过程中。

　　3、 Page Download Time Breakdown（Over time）（页面组成部分时间）

　　说明——随着时间的变化所有请求的响应时间变化过程。这里会将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析再不同的时间点上组成该页面的各个请求时间是如何变化的。描述（看到大多数页面的响应时间是比较稳定的，其中首页刷新变动较大——首先找到变化最明显或者响应时间最高的页面，随后在针对这个页面进行进一步的分析了解时间偏长或者变化较快的原因。）

　　4、 Time to First Buffer Breakdown（页面请求组成时间）

　　说明——组成页面时间请求的比例说明（客户端时间/服务器时间），通过这个图，我们可以直接地了解到整个页面的处理是在服务器端消耗的时间长，还是在客户端消耗的时间长，从而分析得到系统的性能问题是在前段还是在后端。描述（网络或客户端的时间开销占了绝大多数）

　　5、 Time to First Buffer Breakdown（Over time）（基于时间的页面请求组成分析）

　　说明——在整个负载过程中，每一个请求的Server Time和Client Time随着时间变化的趋势，可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致的还是由于服务器端变化导致的。描述（对于用户注册操作，望楼上的时间变化比服务器上的时间变化要剧烈）

　　（五）在Network Monitor（网络监控）中

　　在 Controller中添加了Network Delay Time监控后会出现该数据图。这个功能很好但并不是非常直观和方便，建议使用第三方专门的路由分析工具进行网络延迟和路径分析。

　　1、Network Delay Time（网络延迟时间）

　　说明——从监控机至目标主机的平均网络延迟变化情况。描述（看到网络延迟从多少毫秒逐渐减少到多少毫秒，最后上升到多少毫秒）。

　　2、Network Sub-Path Time（网络Sub-Path时间）

　　说明——当客户端在连接一个远程服务器时，路径并不是唯一的，收到路由器的路由选择，可能会选择不同的路径最终访问到服务器。描述（从监控服务区至目标服务器所经历的路径，以及每个路径上的网络延迟）

　　3、Network Segment Delay Time(网段延迟时间)

　　说明——各个路径上的各个节点网络延迟情况。描述（路由器和路由器之间的网络延迟变化情况，以便于分析影响整个网络时间的原因及节点）。

　　（六）在Resources（资源监控）中

　　资源包括很多种，在Analysis中监控的都市各种系统的计数器，这些计数器反映了系统中硬件或者软件的运行情况，通过它可以发现系统的瓶颈。

　　1、 System Resources（系统资源）列出了再负载过程中系统的各种资源数据是如何变化的，该图需要在场景中设置了对应系统的监控后才出现：

　　1.Database Server Resources（数据库资源）

　　说明——数据库的相关资源在负载过程中的变化情况。

　　2.Web Server Resources（Web服务器资源）

　　说明——Web服务器资源在负载过程中的变化情况。

　　（七）在Error（错误统计）中

　　当场景在运行中出现错误时，错误信息将会被保存在该计数器组中，通过Error信息可以了解错误产生的时间和错误的类型，帮助我们定位产生错误的原因。

　　Error per Second（每秒错误数）

　　说明——每秒错误数可以了解在每个时间点上错误产生的数目，该数据越小越好。通过这个图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。描述(看到场景在多少的时候出现了一次错误)。

　　Service Level Agreement Legend（SLA图标说明）

　　1、图标为灰色带减号的为No Data，说明在SLA中未对这个数据项进行监控，没有数据；

　　2、图标为红色带叉的为Fail，说明在SLA中定义了该项的数据监控，但该数据未能达到期望的阀值；

　　3、图标为绿色带钩的为Pass，说明在SLA中定义了该项的数据监控，该数据达到了期望阀值。

-----------------------------------------------------------------------------------------------------------------------------------------------------------

Vusers (虚拟用状态)

　　Vusers　用户状态计数器组提供了产生负载的虚拟用户运行状态的相关信息，可以帮助了解负载生成的过程。

　　Running Vusers(负载过程中的虚拟用户运行情况)

　　此图反映系统形成负载的过程，随着时间的推移，虚拟用户数是如何变化的。

　　Rendezvous(负载过程中集合点下的虚拟用户)

　　当场景中设置了集合点后会出现该图，反映了随着时间的推移各个时间点上并发用户的数目，方便了解并发用户数的变化情况。

　　Errors(错误统计)

　　当场景在运行中出现错误时，错误信息将会保存在该计数器组中，通过 Error 信息可以了解错误产生的时间和错误的类型，帮助定位产生错误的原因。

　　Errors per Second(每秒错误数)

　　可以了解在每个时间点上错误产生的数目，该数据越小越好，通过该图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。

　　Transactions(事务)

　　给出所有和事务相关的数据统计，方便了解被测系统业务处理的响应时间和吞吐量。

　　事务默认状态：PASS、FAIL、STOP，如果是手工事务那么状态会有 PASS 和 FAIL 两种。

　　Average Transaction Response Time(平均事务响应时间)

　　反映了随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。

　　结合负载生成图合并一起看，可以发现用户负载增加对系统事务响应时间的影响规律。

　　Transactions per Second(每秒事务数)

　　另一个关键数据是 TPS 吞吐量，该数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。

　　TPS 会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS 会有所下降。

　　Transaction Summary(事务概要说明)

　　说明事务的 Pass 个数和 Fail 个数，了解负载的事务完成情况。通过的事务越多，说明系统的处理能力越强，失败的事务越少，说明系统越可靠。

　　结合每秒错误数图进一步分析错误产生的原因。

　　Transaction Performance Summary(事务性能概要)

　　事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。

　　柱状图的落差越小说明系统响应时间的波动较小，如果落差很大，说明系统不够稳定。

　　Transaction Response Time Under Load(在用户负载下事务响应时间)

　　在负载用户增长的过程中响应时间的变化情况，改图的线条越平稳，说明系统越稳定。

　　Transaction Response Time(Percentile)(事务响应时间的百分比)

　　不同百分比下的事务响应时间范围，可以了解有多少比例的事务发送在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。

　　Transaction Response Time(Distribution)(每个时间段上的事务数)

　　每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。

　　Web Resources(网页资源信息)

　　给出的是对于 Web 操作的一些基本信息，这些信息在服务器端也能获得，当 Controller 的 RunTime Setting 中 Preferences 下的 Generated Web performance graphs 选相处于开启状态时，才会得到该图。

　　Hits per Second(每秒点击数)

　　每秒点击数提供了当前负载中对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。

　　Throughput(宽带使用)

　　在当前系统下所使用的带宽，该数据越小说明系统的带宽依赖越小，通过这个数据能确定是否出现了网络带宽的瓶颈(注意使用单位为字节)。

　　HTTP Responses per Second(每秒 HTTP 响应数)

　　每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而 HTTP 响应数是指服务器返回的响应数。如果服务器返回的响应数小于客户端发出的点击数，那么说明服务器无法应答超出负载的连接请求。

　　结合每秒点击数看，如吻合，则说明服务器能够对每一个客户端请求进行应答。

　　Connections Per Second(每秒连接数)

　　给出两种不同状态的连接数，即中断的连接和新建的连接，方便了解当前每秒对服务器产生连接的数量。

　　同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常服务器会返回504错误。

　　可以通过修改服务器的最大连接数来解决该问题。

　　Web Page Diagnostics(网页分析)

　　当在场景中打开 Diagnostics 菜单下的 Web Page Diagnostics 功能，就能得到网页分析组图。

　　通过该图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间的分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过该功能，可以实现对网站前端的性能分析，明确系统响应时间较长是由服务器端处理能力不足还是客户端连接到服务器的网络消耗导致的。

　　Web Page Diagnostics(网页分析)

　　添加改图先会得到真个个场景运行后虚拟用户访问 Page 列表，也就是所有页面下载时间列表。

　　通过 Select Page to Break Down 命令选择具体的 Page 来获得每个请求的相关详细信息。

　　Diagnostics options 选项提供四大块功能。

　　Download Time(下载时间分析)

　　可以得到组成页面的每个请求下载时间。

　　Component(Over time)(各模块的时间变化)

　　列出组成页面的每个元素，以及随着时间的变化所带来的响应时间变化。

　　通过该功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。

　　Download Time(Over time)(模块下载时间)

　　提供了针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。

　　Time to First Buffer(Over time)(模块时间分类)

　　这里会列出该元素所使用的时间分配比例，是受 Network Time 影响的多还是 Server Time 影响的多。

　　Network Time：指网络上的时间开销。

　　Server Time：服务器对该页面的处理时间。

　　Page Download Time Breakdown(页面响应时间组成分析)

　　这张图显示了每个页面响应时间的组成分析，一个页面的响应时间一般由以下内容组成：

　　Client Time

　　客户端浏览器接收所需要使用的时间，可以不考虑。

　　Connections Time

　　连接服务器所需要时间，越小越好。

　　DNS Resolution Time

　　通过 DNS 服务器解析域名所需要的时间，解析受到 DNS 服务器的影响，越小越好。

　　Error Time

　　服务器返回错误响应时间，这个时间反映了服务器处理错误的速度，一般是 Web 服务器直接返回的，包含了网络时间和 Web 服务器返回错误的时间，该时间越小越好。

　　First Buffer Time

　　连接到服务器，服务器返回第一个字节所需要的时间，反映了系统对于正常请求的处理时间开销，包含了网络时间和服务器正常处理的时间，该时间越小越好。

　　FTP Authentication Time

　　FTP 认证时间，这是进行 FTP 登录等操作所需要消耗的认证时间，越短越好。

　　Receive Time

　　接受数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。

　　SSL Handshaking Time

　　SSL加密握手时间

　　得到页面请求的组成比例图，便于分析页面时间浪费在那些过程中。

　　Page Download Time Breakdown(Over Time)(页面组成部分时间)

　　提供了随着时间的变化所有请求的响应时间变化过程。将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析在不同的时间点上组成该页面的各个请求时间是如何变化的。

　　首先找到变化最明显或者响应时间最高的页面，随后再针对这个页面进行进一步的分析了解时间偏长或者变化快的原因。

　　Time to First Buffer Breakdown(页面请求组成时间)

　　提供了组成页面时间请求的比列说明(客户端时间/服务器时间)，通过这个图，可以直观的了解到整个页面的处理是在服务器端消耗的时间长，还是在客户端消耗的时间长。从而分析得到系统的性能问题是在前端还是后端。

　　Time to First Buffer Breakdown(Over Time)(基于时间的页面请求组成分析)

　　给出了整个负载过程中，每一个请求的 Server Time 和 Client Time 随着时间变化的趋势，可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致的还是由于服务器端变化导致的。