性能 – 服务器日志和chrome开发人员工具中的响应时间之间的差异
我正在对一个网站进行负载测试,并注意到我从网络服务器(在本例中为tornado web server)和Chrome开发者工具收到的时间信息之间存在相当大的差异. Web服务器提供一个作为进程运行的服务(实际上,由主管管理的几个进程)在nginx后面.还有一个与此服务交互的Web界面.这个龙卷风Web服务器可以相当快地检索查询(平均30毫秒).但是,Chrome开发者工具显示的响应时间要慢得多(大约240毫秒). 每个查询都会检索一些信息,并需要查询其他资源(主要是图像).我认为这是造成这么大差异的主要原因,但我尝试使用curl和time_starttransfer测量172ms. 另一方面,对nginx使用此日志记录指令:
我能够检查request_time和upstream_response_time实际上是非常小(45毫秒). 可能是造成这种响应时间差异的原因是什么? UPDATE 这是Firebug的截图: 我不认为我可以用有限的信息找出延迟. 更新2 我能够通过curl获得更好的信息.不过我不确定它是否准确:
从我所看到的,time_starttransfer – time_pretransfer = content_generation,所以0.172 – 0.062 = 0.110s.但是,查看日志,Web服务器报告0.044s,nginx同意(0.045s)request_time.此外,curl输出中的time_connect,我认为应该是延迟,并不是那么大(0.062s). 有趣的是time_starttransfer – time_connect * 2 = 0.048类似于nginx或tornado报告的时间(0.048 vs 0.044).但这种计算不应该是正确的.有谁知道什么是正确的方法来证明chrome开发人员工具/ curl与web服务器/ nginx的响应时间之间的差异? 最佳答案
TL; DR
您正在将苹果与橙子进行比较…使用ping检查您的RTD. HTTP请求处理 单个HTTP(S)请求的简化(但仍然非常复杂)步骤集如下: >客户端执行DNS查找以解析URL中的主机名. 正如您所看到的,Web服务器只知道步骤5到8(因为许多初始连接设置将超出其控制范围),并且只能测量5-6和5-8.但是,客户端知道步骤1到9.此外,它还可以测量完全相反的数据点列表. 网络延迟 任何请求或响应都必须通过网络(通常是用于公共服务的Internet)传输,因此在数据从一台机器传输到另一台机器时会产生延迟.两台机器之间的最短时间(从一台机器到另一台机器再返回)称为往返时间(RTT)或往返延迟(RTD).这会影响所有通信,通常使用ping等工具进行测量. 该RTD影响所有通信,并且HTTP请求也不例外,因此它将非常接近上述步骤中步骤4-5和6-7之间的延迟之和. 净结果 把它们放在一起,然后,你会发现curl已经测量了time_pretransfer返回的步骤1-4(好,到4的开头).此外,它还为您作为time_starttransfer测量了1-7(同样是7的开头).但是,服务器已经测量了5-6的时间. 你错过了4-5到6-7之间的时间,我们上面看到的基本上是RTD. 因此,您应该发现time_starttransfer = time_pretransfer request_time RTD (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- 会话/身份验证如何与nginx/NHPM/PHP-FPM一起使用?
- node.js – socket.io何时使用轮询而不是websockets?
- JavaScript – 第3方脚本缓存在Rails 3.1
- ruby-on-rails – 使用rails,nginx和send_file在Chrome中流
- apache的keepalive和keepalivetimeout
- 将Nginx和uWSGI Web服务器错误记录到Sentry
- 基于Git的网站部署工作流程
- html5 – Nginx:如何让重写规则忽略文件或文件夹
- Nginx反向代理Websocket身份验证 – HTTP 403
- 使Nginx从PHP-FPM发送4xx/5xx错误