Firefox HTTP 连接在阻塞阶段花费大量时间
我的应用程序正在执行大量连续的 XHR 调用。这意味着建立大量的 HTTP 连接。
我正在尝试分析所有这些连接的性能。我发现第一个 HTTP 连接花费了大约 10% 的持续时间阻塞(以下定义引用自Firebug Wiki):
阻塞 - 在浏览器队列中等待网络连接所花费的时间(以前称为排队)。对于 SSL 连接,这包括 SSL 握手和 OCSP 验证步骤。
在连续调用中,阻塞所花费的时间会增加,大约 10 次调用后,阻塞稳定在平均约 120MS(!!!) 。
我尝试在 Chrome 中使用 DevTools 以及在 IE 中使用 Fiddler 来测量 HTTP 连接,尽管它们对于 HTTP 连接上的不同阶段没有使用完全相同的阶段/名称,但都没有显示出数量过多的迹象花费在 Firefox 拦截上的时间。
我可以排除这是缺乏可用(持久)HTTP 连接的可能性。由于 XHR 调用是同步完成的。
有人熟悉 Firefox 的这种行为吗?如果有必要,我可以显示 Firebug Net 面板输出。
My application is performing a lot of consecutive XHR calls. This means establishing a lot of HTTP connections.
I'm trying to analyze the performance of all these connections. I found out that the first HTTP connection made spends about 10% of its duration on Blocking (following definition quoted from Firebug Wiki):
Blocking - Time spent in a browser queue waiting for a network connection (formerly called Queueing). For SSL connections this includes the SSL Handshake and the OCSP validation step.
In consecutive calls, the time spent on blocking increases, and after about 10 calls, the blocking holds steady at an average of ~120MS (!!!).
I've tried to measure the HTTP connections similarly in Chrome with the DevTools and in IE with Fiddler, and though they don't use the exact same stages/names for the different stages on an HTTP connection, neither shows signs of the inordinate amount of time spent on blocking that Firefox does.
I can exclude that it's a lack of available (persistent) HTTP connections. Since the XHR calls are done synchronously.
Anyone familiar with this Firefox behaviour? If necessary, I can show the Firebug Net Panel output.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
Firefox 仅对任何给定时间的活动 HTTP(S) 连接数有限制。这是由首选项
network.http.max-connections-per-server
控制的(更改后需要重新启动)。我强烈怀疑你已经达到了这个极限。Firefox only has a limit to the number of active HTTP(S) connections at any given time. This is controlled by the preference
network.http.max-connections-per-server
(restart required after a change). I strongly suspect you are hitting this limit.