关于Web事务响应时间的细分以及深入分析
2017-09-15 11:20
543 查看
对于loadrunner而言,response time只反映了传输时间和系统处理事务的时间,而客户的浏览器从接收完所有字节开始到浏览器加载完所有元素、运行完所有js,呈现给用户的这段时间loadrunner是不统计的,这部分属于页面前端性能,需要通过前端工具辅助分析。
通过Loadrunner获取的事务响应时间,主要可以分解为:First Buffer +Receive + Client Time
1)First Buffer(建立Connection后,浏览器发送请求并成功接收第一个字节的时间)
2)Receive(浏览器接收到第一个字节到最后一个字节的时间)
3)Client Time(请求在客户端浏览器延迟的时间,基本可以忽略)
除了这三个时间,一般细分时间表里还包括DNS解析时间、FTP认证时间、SSL加密握手时间、Connection创建连接时间等(all time = dns time + connection time + first buffer time + received time + ssl time + error time + client time + ftp authrioze time),以下是Loadrunner中的页面时间细化表:
针对first buffer time我们还可以进一步分解:first buffer time = server time + network time,以下说明一下这两个时间:
Network Time 每个网页组件的网络时间
Server Time 每个网页组件的服务器时间 = web application time + server deal time + database time
|C-----------------request------------>S| 浏览器发送请求
|C<----------------ACK-----------------S| 服务器发送ACK
|C<--------the first buffer------------S| 服务器发送the first buffer
network time 是发出请求到收到ACK的时间
Server time 是收到ACK后到完成接收the first buffer的时间
由于Loadrunner统计的事务响应时间不包括浏览器的加载显示时间,所以不能完全体现用户的真实体验时间,所以借用浏览器性能分析工具进行单用户操作分析是有必要的,以下通过浏览器的F12开发者工具进行响应时间的细分分析:
(1)Firefox(Firebug插件)
1)阻挡(Blocking):每个浏览器有并发连接数量的上限(例如Firefox对每个host限制6个连接),如果当前建立的连接数已经超过上限,那么其余该请求会被阻塞,等待新的可以用的连接。
2)域名解析(DNS Lookup):就是从DNS请求发出去到收到回复的时间。
3)建立连接(Connecting):三次握手建立TCP链接的时间。如果是HTTPS的话,还有SSL链接的时间。
4)发送请求(Sending):从发送本次请求的第一个bit,到最后一个bit。对应Request sent
5)等待响应(Waiting):从发送结束起,到收到host返回的第一个bit。相当于是Request和Response中间的间隙。这段时间即系统处理时间(包括后台数据库、应用服务处理时间)。
6)接收数据(Receiving):从收到host返回的第一个bit,到收到最后一个bit。
7)DOMContentLoaded:DOMContentLoaded事件完成的时间,从请求发起时开始,到所有页面元素加载完成。
8)Load:事件,页面load事件完成的时间,从请求发起时开始,到所有js事件运行完成。
(2)Chrome(F12)
1)DNS lookup:域名解析时间
2)stalled:相当于Blocking,是浏览器得到要发出这个请求的指令,到请求可以发出的等待时间(一般是代理协商、以及等待可复用的TCP连接释放的时间,不包括DNS查询、建立TCP连接等时间等)。
3)request sent:请求第一个字节发出前到最后一个字节发出后的时间,也就是上传时间。
4)waiting:请求发出后,到收到响应的第一个字节所花费的时间(Time To FirstByte)。
5)Content Download/ Downloading:接收响应数据的时间(可理解为下载时间)。
6)InitialConnection / Connecting:建立连接的时间,包括TCP握手/重试和协商SSL。
7)DOMContentLoaded:DOMContentLoaded事件完成的时间,从请求发起时开始,到所有页面元素加载完成。
8)Load:事件,页面load事件完成的时间,从请求发起时开始,到所有js事件运行完成。
(3)IE(F12)
1)等候:自开始页面导航起至开始此请求之间的时间。
2)开始:从最初创建请求到发送请求之间的时间。
3)请求:接收到第一个字节所需的时间。发送请求并接收服务器的第一个响应所需花费的时间。
4)响应:接收服务器的响应数据所花费的时间。
5)差距:完成此请求到加载页面之间的时间。
6)DOMContentLoaded(event):DOMContentLoaded事件完成的时间,从请求发起时开始,到所有页面元素加载完成。
7)Load(event):事件,页面load事件完成的时间,从请求发起时开始,到所有js事件运行完成。
以上这些工具已经能够站在用户角度分析响应时间了,但是如果站在开发角度分析应用响应时间,还不足以细分,比如我们已经知道Watting花的时间长,大都是由于后台处理慢引起的,但不知道是Web服务慢还是数据库处理慢。这时候我们就可以利用一些市面上的APM工具(或更直接一点的,利用一些性能分析小工具,比如.Net的ANTS、Java的visualvm),来监控分析关键事务的响应时间,其监控原理比较复杂,不在这细说,APM的主要功能就是统计分析应用(如.net或Java等)的CPU、内存、网络、数据库、UI等性能,并提供错误日志捕获。以下是监控事务响应时间的效果图:
细分到具体的慢组件,就可以看到是否是数据库组件慢:
通过Loadrunner获取的事务响应时间,主要可以分解为:First Buffer +Receive + Client Time
1)First Buffer(建立Connection后,浏览器发送请求并成功接收第一个字节的时间)
2)Receive(浏览器接收到第一个字节到最后一个字节的时间)
3)Client Time(请求在客户端浏览器延迟的时间,基本可以忽略)
除了这三个时间,一般细分时间表里还包括DNS解析时间、FTP认证时间、SSL加密握手时间、Connection创建连接时间等(all time = dns time + connection time + first buffer time + received time + ssl time + error time + client time + ftp authrioze time),以下是Loadrunner中的页面时间细化表:
针对first buffer time我们还可以进一步分解:first buffer time = server time + network time,以下说明一下这两个时间:
Network Time 每个网页组件的网络时间
Server Time 每个网页组件的服务器时间 = web application time + server deal time + database time
|C-----------------request------------>S| 浏览器发送请求
|C<----------------ACK-----------------S| 服务器发送ACK
|C<--------the first buffer------------S| 服务器发送the first buffer
network time 是发出请求到收到ACK的时间
Server time 是收到ACK后到完成接收the first buffer的时间
由于Loadrunner统计的事务响应时间不包括浏览器的加载显示时间,所以不能完全体现用户的真实体验时间,所以借用浏览器性能分析工具进行单用户操作分析是有必要的,以下通过浏览器的F12开发者工具进行响应时间的细分分析:
(1)Firefox(Firebug插件)
1)阻挡(Blocking):每个浏览器有并发连接数量的上限(例如Firefox对每个host限制6个连接),如果当前建立的连接数已经超过上限,那么其余该请求会被阻塞,等待新的可以用的连接。
2)域名解析(DNS Lookup):就是从DNS请求发出去到收到回复的时间。
3)建立连接(Connecting):三次握手建立TCP链接的时间。如果是HTTPS的话,还有SSL链接的时间。
4)发送请求(Sending):从发送本次请求的第一个bit,到最后一个bit。对应Request sent
5)等待响应(Waiting):从发送结束起,到收到host返回的第一个bit。相当于是Request和Response中间的间隙。这段时间即系统处理时间(包括后台数据库、应用服务处理时间)。
6)接收数据(Receiving):从收到host返回的第一个bit,到收到最后一个bit。
7)DOMContentLoaded:DOMContentLoaded事件完成的时间,从请求发起时开始,到所有页面元素加载完成。
8)Load:事件,页面load事件完成的时间,从请求发起时开始,到所有js事件运行完成。
(2)Chrome(F12)
1)DNS lookup:域名解析时间
2)stalled:相当于Blocking,是浏览器得到要发出这个请求的指令,到请求可以发出的等待时间(一般是代理协商、以及等待可复用的TCP连接释放的时间,不包括DNS查询、建立TCP连接等时间等)。
3)request sent:请求第一个字节发出前到最后一个字节发出后的时间,也就是上传时间。
4)waiting:请求发出后,到收到响应的第一个字节所花费的时间(Time To FirstByte)。
5)Content Download/ Downloading:接收响应数据的时间(可理解为下载时间)。
6)InitialConnection / Connecting:建立连接的时间,包括TCP握手/重试和协商SSL。
7)DOMContentLoaded:DOMContentLoaded事件完成的时间,从请求发起时开始,到所有页面元素加载完成。
8)Load:事件,页面load事件完成的时间,从请求发起时开始,到所有js事件运行完成。
(3)IE(F12)
1)等候:自开始页面导航起至开始此请求之间的时间。
2)开始:从最初创建请求到发送请求之间的时间。
3)请求:接收到第一个字节所需的时间。发送请求并接收服务器的第一个响应所需花费的时间。
4)响应:接收服务器的响应数据所花费的时间。
5)差距:完成此请求到加载页面之间的时间。
6)DOMContentLoaded(event):DOMContentLoaded事件完成的时间,从请求发起时开始,到所有页面元素加载完成。
7)Load(event):事件,页面load事件完成的时间,从请求发起时开始,到所有js事件运行完成。
以上这些工具已经能够站在用户角度分析响应时间了,但是如果站在开发角度分析应用响应时间,还不足以细分,比如我们已经知道Watting花的时间长,大都是由于后台处理慢引起的,但不知道是Web服务慢还是数据库处理慢。这时候我们就可以利用一些市面上的APM工具(或更直接一点的,利用一些性能分析小工具,比如.Net的ANTS、Java的visualvm),来监控分析关键事务的响应时间,其监控原理比较复杂,不在这细说,APM的主要功能就是统计分析应用(如.net或Java等)的CPU、内存、网络、数据库、UI等性能,并提供错误日志捕获。以下是监控事务响应时间的效果图:
细分到具体的慢组件,就可以看到是否是数据库组件慢:
相关文章推荐
- 关于Web事务响应时间的细分以及深入分析
- 转:LoadRunner响应时间与用户体验时间不一致问题的深入分析
- LoadRunner:Controller及结果分析 一、性能测试概述 1、关于性能测试目标: ①TPS ②一定并发用户数下功能点的响应时间 ③一定响应时间内功能点的并发用户数 性能测试不是
- 性能结果分析与理解(关于90%响应时间、图表等)
- JavaWeb开发之深入分析请求转发和重定向的应用场景以及请求包含 (跟着龙哥学JavaWeb)
- Transaction Response Time事务响应时间图-我整理的LR性能测试结果分析
- Analysis常见分析图(Vuser图、每秒点击数图、平均事务响应时间、吞吐量)
- 关于JAVAEE servlet filter listener 的作用以及在整个WEB响应过程中所处的位置和功能
- 转:LoadRunner响应时间与用户体验时间不一致问题的深入分析
- 关于堆排序建堆时间以及堆排序的分析之暑假学习记录
- Transaction Response Time事务响应时间图-我整理的LR性能测试结果分析
- 深入分析JS原型链以及为什么不能在原型链上使用对象
- tps 与 事务平均响应时间关系对答(转)
- 用httping测试WEB页面响应时间
- 购物车与商城订单的关系以及技术实现深入分析
- 辛星深入分析vim的自己主动补全功能以及vim的映射
- 关于hibernate一级,二级缓存以及事务隔离机制。
- 关于SpringMVC事务失效的分析
- 【转载】深入分析事务的隔离级别
- 对LR analysis的平均事务响应时间和summary里的时间值的不同的解释