16、 事务响应时间
|
A.GUI客户端 API |
B.外部Internet |
C.前向前端的Web |
D.Internet |
E.负载平衡器 |
F.中间件 |
G.数据库 服务器 |
端到端响应时间是总的消费的“来回”时间，从用户发起动作时起（例如在Web浏览器上点击提交按钮）- 再加上通过网络，和中间件（如IBM WebSphere MQ或Tuxedo 6/7）和服务器的处理的时间，- 到来自Web服务器的一个响应被完全收到，用户可以对服务器响应采取动作止：
为了找出瓶颈，需要更精细的事务数据：
网络和服务器的响应时间通过在客户端机器上运行非GUI Vusers来衡量。
GUI文件下载的响应时间通过比较GUI端到端时间与非GUI总时间来计算。
GUI客户端显示（描绘）的时间被手动得到（用秒表） 。
中间件到服务器的响应时间，只有通过运行Vusers向应用服务器发出单独许可的中间件的API得到。
单独的服务器响应时间通过运行直接连接到应用服务器（不只是一起在同一个子网中）的一台机器上的Vusers得到。
几个运行在事务处理时间的不同允许不同的负载，在事务分析图形中加以比较。
每项事务衡量一个或更多的活动步骤的性能。[Workbook 3-17]
在事务性能图中，“Top时间”事务的结果指向该系统的瓶颈，在这方面他们不论系统的负载 - 明显需要多于平均的时间来完成。
按照安排的斜上和斜下坡道影响这个。
17、 网页的分项数字
每秒事务数（通过和失败）和事务响应时间从虚拟用户的用户定义的数据点得到，该虚拟用户由网页细分图详述，网页细分图祥细分析了从Web服务器资源监测器获得的虚拟用户的客户端事务时间。
网页的分项图形只有在运行前的分析中可用，在LR8控制器Diagnostics菜单上的Distribution...对话框中，无论是“启用以下诊断”和“网页诊断”复选框都选中。
以下说明了网页下载时间分解图测量的默认的顺序：
|
协议 Protocol |
度量 Metric |
测量说明 Measurement Description |
基础结构技术 Infrastructure Technologies |
|
HTTP/S |
[客户端时间] |
由于浏览器思考时间或其他客户端相关的延迟，请求在客户机上的延时时，平均所需的时间。这不包括为Flash来绘画图形（需呀许多秒）的时间。 |
- |
|
[连接时间] |
需要与Web服务器主机指定的URL建立一个初始连接。连接测量是沿网络问题的一个很好的指标。它还表明服务器是否是回应请求。 |
- | |
|
[DNS解析时间] |
使用最接近的DNS服务器，解决DNS名称为一个IP地址所需要的时间。DNS查询测量是DNS解析中问题，或DNS服务器问题的一个很好的指标。 |
- | |
|
[出错时间] |
从HTTP请求被发送时刻，直到错误信息（只是HTTP错误）被返回的时刻，所经过的平均时间 |
- | |
|
[第一缓冲时间] |
从最初的HTTP请求（通常是GET），直到第一次缓冲从Web服务器返回时被成功接收所经过的时间。第一缓冲的测量是Web服务器延误，以及网络延迟的一个很好的指标。（到第一缓冲的时间） |
- | |
|
FTP |
[FTP认证时间] |
在FTP服务器开始处理客户端的命令前认证客户端所需要的时间。这种测量只适用于使用FTP（不是HTTP/s）协议的通信。 |
|
|
HTTP/S |
[接收时间] |
that passes until the last byte arrives from the server and the downloading is complete. The Receive measurement is a good indicator of network quality (look at the time/size ratio to calculate receive rate). This is the metric reported by: 直至最后一个字节从服务器到达，并且下载完成的耗时。接收测量是网络质量（看时间/大小比例来计算接收率）的一个很好的指标。这是度量报告： longLastByteMSecs=web_get_int_property( HTTP_INFO_DOWNLOAD_TIME ); |
|
|
HTTPS |
[SSL交换信息时间] |
建立一个安全套接字层连接（包括客户呼叫，服务器呼叫，客户端的公钥转移，服务器证书转让，和其他阶段）需时。 |
|
17.1 LRAnalysis70.ini
分析模块读取和保存其设置在Windows目录（C:\Winnt或对Windows XP的C:\Windows）的LRAnalysis70.ini文件中。为了让LoadRunner 7.8网页分项图形显示长度大于25个字符的URL，，在[WPB]段添加一个SURLSize入口指定为255（最大）：[WPB] SURLSize=255 此外，在LoadRunner\bin\dat目录，使用MS Access 2000打开loader2.mdb或使用MS Access 97打开loader.mdb。突出Breakdown_map表，选择设计视图，改变“事件名称”一栏的尺寸到255。
17.2 Web服务器资源监测器（虚拟用户）：
第一缓冲分项图形也显示服务器和网络的时间，即每个网页组成部件相关的服务器和网络的时间（以秒计），直到从Web服务器返回的第一缓冲被成功地接收时的一段时间。如果为一个部件下载时间较高，该图可以用来判断是否问题与服务器或与网络相关。
吞吐量图表显示在场景运行的每秒（X轴）的Web服务器上（Y轴）的吞吐量数额。
每秒点击图表显示作为场景的经过时间（X轴）的一个函数的Web服务器上的点击数（Y轴）。
18、 测量计算
每次事务的时间越少，系统的吞吐量越大，由Little的法则所推导的公式表达如下：服务器吞吐量 = ＃真正的同时使用者/（平均响应时间+思考时间）因此，当没有思考时间使用时，虚拟用户的数量可以由Menasce＆Almeida所建议的这个公式计算：＃真正同时使用者*[响应时间/（响应时间+思考时间）]
举例来说，模拟1,000个真正用户使用2秒响应时间和20秒思考时间：1,000 x [ 2 / ( 2 + 20 ) ] = 91
18.1 错误
如果您定义了一个事务在另一个事务中，在控制器的场景状态失败事务统计中，一个错误会算两次，每项事务概要下1次。
18.2 系统负载
通过一个比率 - 在一定期限内，执行的任务的总数（1小时，1天，1周，1个月，1季，1年等）来衡量。例如：每秒300事务。
可以有几个层次的负载：
每小时或每秒高峰期的数量通常用于系统限上限。
正常负载水平用来计划持续支持需求。
低负载水平用来计划资源百分比，它可以用于脱线的维修和升级。
18.3 任务分配概况
目前任务数的两维视图在时间线的连续段上执行。
风险概况同时也可能包括故障风险的一个估计和影响业务的可能性。
19、 变化的测量
平均数测量一组数的主要倾向。举例来说，10，20和30的平均数是20。这是这样计算的，所有三个数加入到一起（10+20+30=60），由加起来的项数（在这个例子中是3）除以这个和。
19.1 标准偏差
标准偏差是在一组数据中对变化程度的一种统计度量。标准偏差告诉你单个项围绕平均数离开的程度。
运行在分析程序，（而不是在控制器）完成后，90％列的数目被显示，因为它是计算由运行期间获取的值排序的所有项计算，然后确定与前所有项的10％的项相关的值。
CV（变化系数（Coefficient of Variation））通过代表它为一个平均数的倍数，使标准偏差数更容易理解，。
19.2 统计的意义
为了确定是否两个平均数的不同足够使单靠机会不会发生，变化的测量是必要的。为了确定随机的机会的程度，结果需要标准化成一个标准的分布。这是一种数学技术，成为ANOVA（方差分析（Analysis of Variance）），一个对于因子和等级的任意数的t测试的扩展。标准分布的形态可发展成正态分布或指数伽玛分布。
如果一个平均数大于另一个平均数的90％，这是一个很好的时机，在两个平均数之间有一个显著的差异。但一个统计上显著的影响实际上并不一定是重要的。
20、 使用分析模块
默认情况下，分析概要（Analysis Summary）被过滤成包括考率时间。因此，每次运行后，单击全面过滤通道图标，向下滚动到“考虑时间”过滤器条件，并取消勾选框。
在控制器中定义的合并图没有输送到分析器。所以，你必须重新建立他们。
结合/合并图形，如“运行的Vusers”和“事务响应时间”：
选择“叠加图”或...
在分析器工具中，将鼠标移动到“运行的Vusers”图表，并右键单击（竖向的X轴）。
然后选择“合并图形”。
对于“合并的图”，选择“平均事务响应时间”（横向Y轴）。
选中单选按钮为“关联”。
复制[整体运行]图流行的原因在下面列出。
[初始] –上坡道期间，良好的识别限制。
[上限] -限制层，所以相对较少波动的测量更为明显。
[平坦] -上坡道期间以后。
我喜欢抹掉默认的名称“… …的副本”，并在图形的名称底部添加一个标记，如方以上括号内的词。这是为了让类似的图形保持垂直对齐。
分析器选定的颜色非常随机 - 因此，（讨厌地）就同一图形，相同的颜色可用于两种不同的线。[你会认为应该比这更精确]
因此无论如何你要手动分配颜色，可以考虑为主要指标使用一套标准的基本颜色：
