Web服务器上的剃刀性能比使用VS开发服务器慢得多

时间:2013-12-24 00:41:31

标签: asp.net-mvc asp.net-mvc-3 razor

我有一个MVC 3应用程序,当使用VS2010和我的桌面上的VS开发服务器(带有8GB RAM的Windows 7)在调试模式下运行时,浏览器页面加载比从实际Web服务器加载时更快运行IIS 7.5的虚拟化2008服务器,托管在英特尔机箱上,双核Xeon CPU与我的桌面在同一个局域网上。恰恰与人们期望和希望的相反。

为了帮助弄清楚发生了什么,我添加了代码来记录对应于执行控制器代码和剃刀代码的开始和结束时间以及两者之间的间隔。我反复切换在我的浏览器(FF)中加载已检测页面和同一应用程序中的另一个网页,然后查看来自两个服务器的日志。 (仅供参考,有问题的页面是通过Ajax加载的,因此浏览器端没有缓存)

我跳过了初始循环,其中包括编译剃刀代码的时间并在随后的5个加载循环中平均结果,尽管所有重复的数字非常相似。

IIS的控制器代码执行时间为133毫秒,而我的开发服务器为113。考虑到开发服务器正在运行调试版本而IIS正在运行发布版本,但至少从用户的角度来看,这有点令人惊讶。

然而,对于我的开发服务器,剃须刀执行时间为823毫秒,超过72毫秒,超过一个数量级的差异!!起初我可能是剃刀代码总是在IIS上重新编译,但是日志显示在控制器执行结束和第一次加载的剃刀执行开始之间有很长的时间间隔,而且对于IIS和所有后续加载只有几个msecs VS dev服务器所以很明显在两种情况下都使用编译的剃刀代码。

我确认两者都是以32位应用程序运行(通过记录intptr的大小),并且在IIS应用程序池设置中也设置了启用32位应用程序(也设置为v4和集成模式)。

我验证了IIS版本正在运行发布代码而dev服务器正在运行调试代码(通过在控制器中记录HttpContext.IsDebuggingEnabled)

我还在我的应用程序中重复了其他页面的实验,它们对于相似复杂性的页面都显示相同的加载行为,因此对于该特定页面看起来并不是很有趣(更简单的页面加载速度更快)会期待的)

到目前为止,我从这些结果中得出的结论是:

由于控制器代码的执行时间几乎相同,并且在测试时除了我之外在虚拟服务器上没有其他重要流量,因此两个盒子上的资源不太可能存在差异。

这不是因为未能缓存和重用已编译的剃刀代码(从日志中的时间模式中可以看出)

由于所有类似复杂性的页面都遇到类似问题,因此不太可能由于应用程序而导致

这不是浏览器方面的问题,因为使用相同的浏览器实例来查看它们。

这不是64比32位问题,因为两者显然都使用32位。

代码也没有区别,因为我在执行测试的同时将代码发布到Web服务器(并且它们都添加了我添加的新日志代码)。

我认为它可能是局域网(因为可能是剃刀代码在执行的同时被渲染和发送而不是在渲染后被缓冲和发送)但是有效载荷只有大约140KB(来自Net标签)在Firebug)和LAN是100MB切换。为了帮助消除这个因素,我在同一个Web服务器上的文件共享上找到了大约240KB的文件,并将其复制到我的桌面。转移几乎是瞬间完成的。当然没有接近800毫秒。

到目前为止,我很遗憾在网络服务器上渲染时可能导致这700多毫秒的额外时间。

更新:我成功地在桌面上安装了IIS 7并直接指向我的项目。页面加载与使用VS开发服务器一样快捷,因此它似乎不仅仅是IIS与VS Dev Server问题。

更新:我添加了代码来打印出Environment.Version。 开发箱:4.0.30319.468 Web服务器:4.0.30319.1

我将弄清楚如何更新Web服务器。也不确定这是不是整个故事。也许MVC dll有单独的版本,但还不知道如何解决它。

我也很好奇,即使在发布之后(当我构建了发布版本时),当我运行本地Web服务器(指向发布的同一文件夹)时,它显示调试模式。

更新:我检查过,似乎我在项目的bin文件夹中提供了所有Razor dll,因此它们在服务器和桌面上应该是相同的。据推测,MVC将首先检查垃圾箱然后检查GAC。

0 个答案:

没有答案