了解Chrome网络日志“停滞”状态

Question

我在Chrome中发布了以下网络日志：

我不明白其中的一件事：填充灰色条和透明灰色条之间的区别是什么。

Answer 1

Google在DevTools文档的Evaluating network performance部分提供了这些字段的细分。

摘自Resource network timing：

  

失速/阻断

     

请求在发送之前等待的时间。此时间包括代理协商所花费的任何时间。此外，此时间将包括浏览器等待已建立的连接可供重用时，遵守Chrome的maximum six每个源连接的TCP连接。

（如果您忘记了，Chrome在悬停工具提示和“时间”面板下方有一个“解释”链接。）

基本上，您会看到这一点的主要原因是Chrome一次只能为每台服务器下载6个文件，其他请求将会停止，直到连接插槽可用为止。

这不一定需要修复，但避免陷入停滞状态的一种方法是将文件分布到多个域名和/或服务器上，如果适用于您的需要，请记住CORS，然而，HTTP2可能是未来更好的选择。资源捆绑（如JS和CSS连接）也可以帮助减少停滞的连接数量。

Answer 2

DevTools: [network] explain empty bars preceeding request

  

进一步调查并确定我们的停滞和排队范围之间没有显着差异。都   是从其他时间戳的delta计算的，而不是   从netstack或渲染器提供。

           

目前，如果我们正在等待套接字可用：

     

  
• 如果发生一些代理协商，我们会称之为停滞不前
  
• 如果不需要代理/ ssl工作，我们会称之为排队。
  

Answer 3

https://developers.google.com/web/tools/chrome-devtools/network-performance/understanding-resource-timing

这来自Chome-devtools的官方网站，它有所帮助。 在这里我引用：

  

  
• 的队列   如果请求排队，则表明：      
    
  • 请求被呈现引擎推迟，因为它被认为比关键资源（例如脚本/样式）的优先级低。这通常发生在图像上。
    
  • 请求被暂停，等待即将释放的TCP套接字不可用。
    
  • 请求被暂停，因为浏览器在HTTP 1上每个源只允许六个TCP连接。   制作磁盘缓存条目所花费的时间（通常很快。）
    
  
• 的失速/阻断   请求在发送之前等待的时间。它可以等待排队描述的任何原因。此外，此时间包括代理协商所花费的任何时间。
  

Answer 4

由于许多人来到这里调试其速度缓慢的网站，所以我想向您介绍我的情况，而Google的解释都没有解决这个问题。我的巨大停滞时间（有时是1分钟）是由于在Windows上运行的Apache的工作线程太少而无法处理连接，因此正在排队。

如果您的apache日志有以下注释，这可能适用于您：

Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

此问题已在Apache httpd.conf中解决。取消注释： 包含conf / extra / httpd-mpm.conf

并编辑httpd-mpm.conf

<IfModule mpm_winnt_module>
   ThreadLimit              2000
   ThreadsPerChild          2000
   MaxConnectionsPerChild   0
</IfModule>

请注意，您可能不需要2000个线程，或者可能需要更多线程。我的情况下2000年还可以。

Answer 5

我的情况是该页面在打开时发送带有不同参数的多个请求。因此，大多数人正在停滞不前＆＃34;。立即发送以下请求后停止＆＃34;停止＆＃34;。避免不必要的请求会更好（懒惰......）。