为什么Chrome时间线显示的时间比服务器多？

Question

我们正在尝试优化我们的ASP.NET MVC应用程序，并在服务器端日志和客户端延迟之间产生很大的时间差异。

在时间轴中刷新Chrome页面时，它会显示4.47s：

据我所知，服务器端代码执行的时间应为3.34秒，但在我们的服务器日志中，我们有以下内容：

• 开始请求15：41：52.421
• 结束请求15：41：53.218
• 预发送请求标题15：41：53.218
• 预先发送请求内容15：41：53.218

因此，根据服务器端日志，代码执行总共只需要797毫秒。 它不会一直发生，Chrome时间线通常会显示非常接近服务器日志的时间。但有时我们有几秒钟的延迟。

这种延迟可能来自哪里？

Answer 1

有很多东西可以偶尔影响时间到这种程度，即使在这种情况下几乎三秒的加入有点过多。既然您没有提及您的网络设置方式，您使用的操作系统等， 我会尝试总结一个列表，列出在处理这种延迟时出现的问题，按概率排序。

这里的主要问题是你应该集中你的侦探天赋的总时间的等待部分。

请注意，答案非常一般，因为问题几乎没有说明服务器，客户端计算机或网络（如果有）之间的配置。由于您说延迟不是一直存在，因此您需要瞄准一个或多个移动目标。

<强>病毒 如果你有一个互联网屏蔽或类似命名的组件，那么防病毒软件似乎可以随机延迟某些连接而其他几乎不受影响的情况并不罕见。对于浏览器而言，这是透明的（它只是一个延迟，无论是什么原因导致它），因此等待。

网络问题 特别是如果您通过无线网络或配置不良的有线网络连接，即使网络设备上的标签显示TurboSpeedTM，也可能会出现几秒钟的延迟。

服务器端问题 服务器可能会以您的应用程序内计时器未涵盖的方式超载先前的请求，因为服务器在执行脚本之前和之后执行了许多步骤。

客户端操作系统问题 就像防病毒软件一样，操作系统可以出于各种原因随意延迟您的数据包。

在追捕此类问题时，我建议尝试在服务器本身上执行查询并比较结果时间，尝试尽可能组合网络设置和操作系统，更喜欢规划良好的网络环境与那些有许多未知或外部因素（读取无线）并使用一些数据包嗅探软件（如wireshark）来检查浏览器是否不会说谎。这只是它的开始：）