LoadRunner中对图表的分析说明
LoadRunner使用说明书
Load Runner 使用说明一、组件：(一) VuGen:用于捕获最终用户业务流程和创建怎动化性能测试脚本。
1. 录制脚本：(1) 集合点Rendezvous(2) 验证点Check Point:文本验证点Text Check、图片验证点Image Check(3) 事务Transaction:事务开始Start Transaction、事务结束End Transaction(4) 注释与消息Comment & Message:/***/2. 增强并编辑Vuser脚本(1) 参数化：在Select next now中的参数：Sequential顺序、Random随机、Unique唯一在Update value on 参数：Each iteration每次迭代、Each occurrence每次出现、Once 一次(2) 从数据库中导入数据3. 配置动行时设置Runtime settings(运行时设置)(1) Number of Iterations:迭代次数(2) 在Preferences中的Enable image and text check在脚本中添加验证点时必须选中。
4. 在独立模式下运行Vuser脚本5. 集成Vuser脚本(二) Controller:用于组织、驱动、管理和监控负载测试。
1. 创建方案(1) 创建手动方案(2) 创建百分比模式方案(3) 创建面向目标的方案2. 计划方案(1) 开始时间(2) 方案运行设置：加压Ramp Up、持续时间Duration、减压Ramp Dowm3. 运行方案4. 监视方案(1) RuntimeGraphs(运行时图)A. Running Vusers运行时图：Running正在运行的Vuser总数、Ready完成脚本初始化部分、即可以运行的Vuser数、Finished结束运行的Vuser数，包括通过的和失败的、Error执行时发生的错误VuserB. Transaction Graphs事务监视图:Trans Response Time事务响应时间、Trans/Sec(Passed)每秒事务数（通过）、Trans/Sec(Failed/Stopped)每秒事务数（失败、停止）、Total Trans/Sec（Passed）每秒事务总数（通过）。
LoadRunner分析实时监视图表
分析实时监视图表Q1 事务响应时间是否在可接受的时间内？哪个事务用的时间最长？看Transaction Response Time 图，可以判断每个事务完成用的时间，从而可以判断出那个事务用的时间最长，那些事务用的时间超出预定的可接受时间。
下图可以看出，随着用户数的不断增加，login 事务的响应时间增长的最快！Q2 网络带宽是否足够?“Throughput”图显示在场景运行期间的每一秒钟，从Web Server 上接受到的数据量的值。
拿这个值和网络带宽比较，可以确定目前的网络带宽是否是瓶颈。
如果该图的曲线随着用户数的增加，没有随着增加，而是呈比较平的直线，说明目前的网络速度不能够满足目前的系统流量。
Q3 硬件和操作系统能否处理高负载?“Windows Resources”图实时地显示了Web Server 系统资源的使用情况。
利用该图提供的数据，可以把瓶颈定位到特定机器的某个部件。
9 利用Analysis 分析结果场景运行结束后，需要使用Analysis 组件分析结果。
Analysis 组件可以在“开始程序”菜单中启动，也可以在Controller 中启动。
由于我本人对怎样分析结果最有效没有进行比较多的实践，所以这里只能按照常规的方法进行简单介绍。
注意：这里介绍的分析方法只适用于Web 测试。
9.1 分析事务的响应时间第一步，看“Transaction Performance Summary”图，确认那个事务的响应时间比较大，超出了我们的标准。
看下图，login 事务的平均响应时间最长。
然后我们再看“Average Transaction Response Time”，观察login 在整个场景运行中每一秒的情况。
从图中可以看出，login 事务的响应时间并不是一直都比较高，只是随着用户数的增加，响应时间才明显增加的。
然后我们再看“Average Transaction Response Time”，观察login 在整个场景运行中每一秒的情况。
LoadRunner常见测试结果分析（转）
LoadRunner常见测试结果分析（转）
在测试过程中，可能会出现以下常见的几种测试情况：
一、当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降这种情形表明：
* 从事务响应时间曲线图持续上升表明系统的处理能力在下降，事务的响应时间变长；
* 持续平衡表明并发用户数达到一定数量，在多也可能接受不了，再有请求数，就等待；
* 当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。
如果系统没有这种下降机制，响应时间越来越长，直到系统瘫痪。
从以上的结果分析可发现是由以下的原因引起：
1. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；
2. 内存泄露；
二、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常；
表明系统中可能产生资源争用情况；
引起原因：
开发人员注意资源调配问题。
三、所有的事务响应时间、cpu等都很正常，业务出现失败情况；
引起原因：
数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；
当数据量大时，就会出现数据错乱情况。
利用LoadRunner进行性能测试和结果分析
在场景执行的时候,虚拟用户的事务执行生成了结果数据,为了在执行测试期间监控场景的执行情况,我们可以用loadrunner的在线监测工具.为了观察执行结束后的总结情况, 你可以用下列工具:➤虚拟用户的执行日志文件包含了每个虚拟用户在场景中运行的所有记录,这些文件位于场景结果文件的目录中.(在单个用户的执行模式下,这些文件位于脚本目录中)➤控制器的输出窗口显示了场景执行的过程,如果场景执行失败,可以在这个输出窗口中找到有用的调试信息.➤分析图表帮助你定位系统的性能表现,并且提供有关事务和虚拟用户的有用信息,你也可以通过关联不同运行场景的结果到一个图表中来比较不同的图表,从而更加准确的定位性能问题➤图表数据和原始数据视图用Excel格式显示了生成图表数据的真实原始数据, 为了更深入的分析,你也可以把这些文件存储起来.➤分析模块提供的报告功能让你可以从整体上浏览整个性能的报告,包括每个图表的数据,你也可以创建一个Word格式的文件,其中会自动创建用户需要的各种格式.分析模块提供的常用图表可以分为以下一些主要类别:➤虚拟用户图表提供了虚拟用户的状态和统计信息➤错误信息图表提供了场景中错误发生的信息➤事务图表提供事务的性能和响应时间信息➤Web资源图表提供了吞吐量,每秒点击,HTTP每秒响应,每秒重试次数和web用户每秒下载页面的信息等➤Web页面细分图提供每个Web页面组件的大小和下载时间图等➤用户自定义数据点图提供用户自定义数据点的信息图等➤系统资源图表提供场景执行期间我们通过计数器添加的系统的资源统计信息➤网络监控图表提供网络延迟的图表信息➤防火墙服务器监控图表提供防火墙服务器的资源图表➤Web 服务器资源图表提供Web服务器比如Apache, IIS服务器等的资源使用信息➤Web 应用服务器图表提供各种web应用服务器的资源使用情况➤数据库服务器资源图表提供数据库服务器的资源使用情况此外,还提供了其他一些不太常用的图表信息,图表信息的多少取决于你的被测对象和场景中监控器以及计数器的选择情况. 下次我们会重点分析虚拟用户图表. 今天主要介绍虚拟用户类型和错误类型两种图表虚拟用户类型的图表可以提供三个图，分别是：* 运行虚拟用户图* 虚拟用户汇总图* 集合点图其中虚拟用户图显示的是执行负载测试的每一秒执行脚本的虚拟用户个数，以及他们的状态。
loadrunner场景运行结果的分析方法
本文对LoadRunner的场景运行结果进行分析的方法，总结成指导手册，以指导测试人员进行结果分析。
结果分析工作的遵循如下过程：1. 结果文件是以那种形式保存每个系统测试结果保存方式均为一些文件夹，例如下图：对每个结果的文件夹，我们打开进行同样操作。
2. 如何打开结果文件点击文件夹中的图标的文件，如下图LoadRunner Analysis工具会将结果文件打开最终打开的界面如下3. 如何设置全局过滤器在LoadRunner Analysis工具中，点击File->Set Global Filter…，或者【Ctrl+B】快捷键弹出设置过滤的页面：选择过滤器，将Transaction Name定位我们所需要分析的事务名称，将Think Time定为不包含Think Time；4. 如何获取关联图在一幅图，比如平均事务响应时间图上，点击鼠标右键，选择Merger Graphs…，或【Ctrl+M】快捷键点击后弹出如下页面我们可以在下拉列表中选择，资源监控图越多，下拉列表中的选择项也就越多，例如我们选择Running Vusers，点击OK，（关联类型选择只是图形的显示方式不同而已，可以根据实际需求选择），得到如下的【平均事务响应时间——运行用户数】关联分析图：5. 如何增加一张资源分析图在结果文件打开后，点击左上角区域的按钮，会弹出增加图形对话框我们可以选择我们所要分析的资源图，蓝色特殊标识的部分是本结果文件中可以进行分析的数据，黑色标识，该图形数据没有数据，不能分析。
如下图选择Web Page Diagnostics节点下的Time to First Buffer Breakdown，点击Open Graph按钮会显示图形则可以对页面组件大小进行分析。
通过对左侧树状节点的切换和选择，可以分析不同对象的下载过程消耗时间。
如下图：6. 如何删除不想要的一幅资源图选择图形，点击按钮，点击“是”，就可以删除。
loadrunner analysis 使用
LoadRunner Analysis 使用一、LoadRunner Analysis简介LoadRunner Analysis是HP公司提供的性能测试结果分析工具，用于对LoadRunner产生的测试数据进行深入分析，以评估系统的性能。
该工具能够帮助测试人员理解系统在高负载下的表现，找出瓶颈，并提供优化建议。
LoadRunner Analysis的使用对于确保系统在生产环境中的稳定性和性能至关重要。
1.1 工具特点强大的数据可视化功能：LoadRunner Analysis提供了丰富的图表和报告，以便测试人员直观地了解系统性能。
深入的瓶颈分析：通过对测试数据的深入分析，帮助定位系统瓶颈。
自动化报告生成：可以快速生成性能测试报告，提高工作效率。
1.2 适用场景LoadRunner Analysis适用于各种规模的企业和组织，尤其适用于需要进行负载和压力测试的场景。
它可以帮助测试人员快速定位和解决性能问题，提高系统的稳定性和效率。
二、LoadRunner Analysis使用方法2.1 导入测试数据首先，需要将LoadRunner产生的测试数据导入到LoadRunner Analysis中。
可以通过工具自带的导入功能或手动指定数据路径来完成。
2.2 创建分析计划在导入数据后，需要创建一个分析计划，以定义需要分析的性能指标和目标。
这有助于测试人员聚焦于关键问题，提高分析效率。
2.3 配置图表和报告根据分析计划，可以配置各种图表和报告来展示性能数据。
例如，可以通过创建图表来显示响应时间、吞吐量等关键指标的变化趋势。
2.4 运行分析在配置完图表和报告后，可以运行分析计划，LoadRunner Analysis会自动对数据进行处理和分析，并生成相应的图表和报告。
2.5 问题诊断和优化建议基于分析结果，测试人员可以找出系统性能的瓶颈，并提出优化建议。
LoadRunner Analysis提供了丰富的诊断工具和报告，可以帮助测试人员快速定位问题并制定相应的解决方案。
Loadrunner分析结果图说明
Loadrunner分析结果图说明1、Running Vusers图使用Vuser 图可以确定方案，执行期间Vuser 的整体行为。
X 轴表示从方案开始运行以来已用的时间。
Y 轴表示方案中的Vuser 数。
Vuser-Rendezvous 图主要反映Vuser 是在什么时候集合在这个点上,又是怎样的一个被释放的过程.图中可以看到在1分4秒的地方50个用户全部集中到达集合点，持续了5分48秒开始释放用户，整个过程持续了6分钟。
2、Hits per Second图“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。
通过对查看“每秒点击次数”，可以判断系统是否稳定。
系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
3、Throughput图“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。
其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
X 轴表示从方案开始运行以来已用的时间。
Y 轴表示服务器的吞吐量（以字节为单位）。
“吞吐率”图和“点击率”图的区别：“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。
4、Transaction Summary图对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
5、Average Transaction Response Time图“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
loadrunner结果分析图
使用LoadRunner Analysis进行分析的第一步是看测试结果的综合报告，当发现事务运行不正常时，才需要进行更深入的分析。
1、用户事务分析。
“用户事务”主要针对业务而言，一个“用户事务”通常由一个或一系列的用户操作组成。
Action是用户的一系列操作的组合；Transaction是用户的某一具体的动作。
与用户事务相关的图表有以下8个（1）事务综述图（Transaction Summary）通过此图可以看出每个事务在测试时间内分别通过（Pass）和失败（Fail）了多少（2）事务平均响应时间分析图（Average Transaction Response Time）此图显示测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析应用系统的性能走向；另外还可以统计出测试场景运行时间内各事务的最大值、最小值、平均值等信息。
（3）每秒通过事务数分析图（Transactions per Second）TPS图显示在场景运行的每一秒中，每个事务通过的数量，通过它可以确定系统在任何给定时刻的实际事务负载；可以将TPS图与平均事务响应时间图进行对比，以分析事务数目对执行时间的影响。
（4）每秒通过事务总数分析图（Total Transactions per Second）“每秒通过事务总数分析”图显示场景运行时，在每一秒内通过的事务总数。
如果系统性能稳定，在同等压力下，此图应该接近直线，而不是逐渐倾斜。
与TPS相比，“每秒事务总数”关注服务器整体处理事务的情况，是宏观概念。
（5）事务性能摘要图（Transaction Performance Summary）“事务性能摘要”显示方案中所有事务的最小、最大和平均时间，可以直接判断响应时间是否符合用户的需求。
可以通过网页细分方法来分析某些响应时间长的事务。
（6）事务响应时间与负载分析图（Transaction Response Time Under Load ）这个分析图是“正在运行的虚拟用户”图和“平均事务响应时间”图的组合。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
LoadRunner中对图表的分析说明（一）在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（接收）的时间也有一定的影响。
ponent（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 随着时间变化的趋势，可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致的还是由于服务器端变化导致的。