网页资源请求在Chrome中停滞了将近一分钟

时间:2019-03-23 11:18:28

标签: amazon-web-services google-chrome http

长时间停滞后,Webapp上的资源需要花费近一分钟的时间加载。这是一致发生的。如下所示,该页面上只有3个请求实际命中服务器本身,其余请求命中内存或磁盘缓存。此问题似乎仅在Chrome上出现,Safari和Firefox均未出现此问题。

我已在此SO问题中实施了Cache-Control: no-store建议,但问题仍然存在。 request stalled for a long time occasionally in chrome

下面还提供了一个示例,显示了响应一旦最终进入后的样子。

我的应用程序托管在网络负载均衡器后面的AWS中,该负载均衡器代理运行nginx的EC2实例和应用程序本身。

任何想法是什么原因造成的?

Network tab Response

4 个答案:

答案 0 :(得分:0)

我看到两件事可能是造成延迟的原因:

1)CDN的使用
如果加载速度较慢的资源是从CDN(内容交付网络)加载的,则应尝试将其下载到服务器并直接交付。
特别是如果您使用http2,则使用http1可以显着提高速度。我没有使用AWS的经验,所以我不知道默认情况下如何提供服务。
如果资源是从CDN加载的,则无法在屏幕快照中清楚地显示出来,但是我认为这是关于脚本的合理假设。

2)Chrome的资源计划程序
常规说明:https://blog.chromium.org/2013/04/chrome-27-beta-speedier-web-and-new.html
自从文章发布以来,此调度程序可能会更改,但至少会在您的屏幕快照中显示。
我认为,如果您借助https://www.webpagetest.org和chrome Web工具优化页面,则可以解决计划程序的任何问题,还可以解决其他有关速度的问题,也许还可以解决其他问题。这是链接:https://developers.google.com/web/tools/

编辑
3)代理问题
通常,由于代理服务器,Chrome可能会出现问题或延迟原因。在锁定日志文件之前无法知道详细信息,也许您需要调整日志文件的生成情况,并且日志级别足以告诉您任何问题(级别Warning甚至是Info

答案 1 :(得分:0)

在监视chrome net-export日志后,好像我遇到了以下问题:https://bugs.chromium.org/p/chromium/issues/detail?id=447463

尽管如此,我仍然没有解决方法。

答案 2 :(得分:0)

我遇到了完全相同的问题。我们正在将带网络负载平衡器(NLB)的Elastic Beanstalk与在NLB处使用TLS终止的

我从AWS支持部门获得的反馈是:

  

当客户端连接到网络负载平衡器上的TLS侦听器并且在完成TLS握手后不立即发送数据时,可能会出现此问题。根本原因是在处理新连接时出现边缘情况。请注意,只有在TLS侦听器的目标组配置为使用TCP协议而未启用代理协议v2的情况下,才会发生这种情况

他们现在正在解决此问题。 不知何故,只有在使用Chrome浏览器时才能注意到此问题。

同时,您有以下两种选择作为解决方法:

    在目标组上
  • 启用代理协议v2或
  • 配置目标组以使用TLS协议将流量路由到目标

答案 3 :(得分:0)

我知道这是一个较晚的答案,但我是为寻求解决方案的人写的。

TL; DR:就我而言,启用NLB的cross-zone load balancing属性可以解决问题。


在使用WireShark进行调查后,我发现Chrome与两个不同的IPv4地址进行了通信。 向其中一个发送数据包总是成功,而向另一个发送数据包总是失败。 实际上,这两个地址委派了两个可用区。

默认情况下,如果选择NLB,则将禁用跨区域负载平衡(相反,默认情况下,将启用ALB的相同属性)。 假设有两个可用区。 AZ-1 / AZ-2。 将两个可用区都附加到NLB时,每个可用区都有一个节点。

属于AZ-1的节点只是将流量路由到也属于AZ-1的实例。 AZ-2实例将被忽略。 我谦虚的应用程序(托管在Fargate上)在AZ-2中只有一个应用程序服务器(ECS任务),因此AZ-1中的NLB节点无法将流量路由到任何地方。

我不熟悉TCP / IP或浏览器的实现,但据我了解,您的浏览器会在DNS查找后以某种方式选择实际的IP地址。 如果在上述情况下选择了AZ-2节点,那么一切都会很好,但是如果选择了AZ-1,您的浏览器就会停止运行。 也许Chrome有随机的策略来选择ip,而Safari或Firefox却有粘性,因此问题只出现在Chrome上。

启用cross-zone load balancing后,可以从AZ-1 NLB节点看到AZ-2上的ECS任务,并且在Chrome浏览器中也可以正常工作。

(请随时纠正我的英语不好。谢谢!)