我们正在尝试优化我们的 ASP.NET MVC 应用程序，并在我们的服务器端日志和客户端延迟之间获得很大的时间差。
在时间轴中的 Chrome 中刷新页面时显示 4.47 秒：
据我了解，服务器端代码执行的时间应该是 3.34s，但是在我们的服务器日志中我们有以下内容：
因此，根据服务器端日志，代码执行总共只用了 797 毫秒。 它不会一直发生，而且 Chrome 时间线通常会显示非常接近服务器日志的时间。但有时我们会有几秒钟的延迟。
这种延迟从何而来？
【问题讨论】：
标签： asp.net asp.net-mvc google-chrome timeline
有很多东西会偶尔影响时间到这种程度，尽管在这种情况下增加近三秒有点过分。由于您没有过多提及您的网络设置方式，您使用的操作系统等， 在处理这种延迟时，我将尝试总结出我的想法，按概率排序。
这里的主要问题是等待总时间的一部分，你应该在那里集中你的侦探才能。
请注意，答案非常笼统，因为该问题几乎没有说明服务器、客户端计算机或它们之间的网络（如果有）的配置。由于您说延迟并非一直存在，因此您需要瞄准一个或多个移动目标。
杀毒软件 如果您有 internet shield 或类似名称的组件，则防病毒软件似乎会随机延迟某些连接而几乎不影响其他连接的情况并不少见。对于浏览器来说，这是透明的（这只是一个延迟，不管是什么原因造成的），因此 Waiting.
网络问题 特别是如果您通过无线网络或配置不当的有线网络进行连接，即使网络设备上的标签显示 TurboSpeedTM，也可能会出现几秒钟的延迟。
服务器端问题 服务器可能会以您的应用程序内计时器未涵盖的方式因先前的请求而过载，因为服务器在执行脚本之前和之后执行了许多步骤。
客户端操作系统问题 就像防病毒软件一样，操作系统可以出于各种原因几乎随机延迟您的数据包。
当寻找此类问题时，我建议尝试在服务器本身上执行查询并比较结果时间，尽可能尝试网络设置和操作系统的组合，更喜欢规划良好的网络环境而不是那些有许多未知或外部因素（读取无线）并使用一些数据包嗅探软件（如wireshark）来检查浏览器是否没有撒谎。这只是它的开始:)
【讨论】：