我已经预编译了我的应用程序: precompilation settings,还将编译配置设置为
<compilation targetFramework="4.6.2"
batch="false"
debug="false"
optimizeCompilations="true">
</compilation>
但是每次第一次访问页面时,它仍然需要很长时间(不仅是对应用程序的第一个请求,这可以通过应用程序初始化来解释,但是首先请求每个视图,即使在应用程序初始化之后)。< / p>
我使用分析器来检查它是否是我们的代码,但它执行得很快。第一页访问延迟大约20秒(有时甚至高达60秒)。即使视图已预编译(请注意最后一次SQL查询和响应后的20秒延迟),Profiler会显示此信息(第一页访问的响应会延迟返回): profiler result on first request
立即返回每个下一页请求的响应: profiler result on second request
我已经检查过ORM初始化,试图缩小js / css,gzip它们并检查其他所有已知选项,但无济于事。即使应用程序和应用程序池已预热,第一次请求的每个视图/页面都会返回缓慢。
然后我在IIS中启用了跟踪并找到了以下内容: delay after HANDLER_CHANGED event
处理程序更改后发生延迟。现在......奇怪的是,我想,它是从OldHandlerName改变的,它是null。这可能是原因吗?或者可能是延迟后发生的事件(HttpCacheModule)?我发现了其他几个这样的发现,这些发现与慢速初始页面请求有关,但没有一个得到适当的回答。其中一个答案可以找到here,但更改outputCache没有帮助。我的outputCache设置:
<caching>
<outputCacheSettings>
<!--outputCacheSettings - Controls how controller actions cache content in one central location.
You can also modify the web configuration file without recompiling your application.-->
<outputCacheProfiles>
<!--Cache the 400 Bad Request route for a day.-->
<add name="BadRequest" duration="86400" location="Server" varyByParam="none" />
<!--Cache the 403 Forbidden route for a day.-->
<add name="Forbidden" duration="86400" location="Server" varyByParam="none" />
<!--Cache the 405 Method Not Allowed route for a day.-->
<add name="MethodNotAllowed" duration="86400" location="Server" varyByParam="none" />
<!--Cache the 404 Not Found route for a day.-->
<add name="NotFound" duration="86400" location="Server" varyByParam="none" />
<!--Cache the 401 Unauthorized route for a day.-->
<add name="Unauthorized" duration="86400" location="Server" varyByParam="none" />
<!--Cache the 500 Internal Server Error route for a day.-->
<add name="InternalServerError" duration="86400" location="Server" varyByParam="none" />
</outputCacheProfiles>
</outputCacheSettings>
</caching>
我在这里碰壁...有什么想法吗?
:编辑: 在进一步分析之后,事实证明,即使在预编译运行之后,
也是如此C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
在部署时没有填充dll。我跑的时候
aspnet_compiler -v /virtual_path
事实上,它确实将所有页面预编译到该临时文件夹,但是当我第一次访问页面时,则会创建该.dll的第二个浅表副本,这会导致延迟。该文件由IIS而不是预编译工具创建后,视图可以正常工作。
所以......看起来IIS不知道,这些dll已经预先编译并准备好采取行动了。你知道如何让它为人所知吗?我们是否可以完全禁用临时ASP.NET文件并强制它仅使用我们应用程序的bin文件夹?
:EDIT2:我看到IIS页面和控件中有一个选项,称为编译模式,默认情况下它是“始终”(这意味着它总是强制编译),但如msdn中所述,这些设置适用于ASP仅限.NET Webforms。 MVC必须有类似的设置。救命! : - )
答案 0 :(得分:0)
预编译并不能完成你想到的一切。它确实编译成了一个dll,但是那个dll需要从IL转换成机器代码。在IIS中启动应用程序时会发生这种情况。如果您使用的是WIndows Server 2012或更高版本,则可以在应用程序池中设置一些功能,以便在使用“始终运行”启动模式加载后保持热度。
您可以通过打开IIS管理器来找到此设置应用程序池|选择适当的App Pool |高级设置并将开始模式设置为始终运行。
初始命中仍然需要一些编译时间,但之后应用程序应该保持加载状态,只有在应用程序池被强制回收的情况下才会被拆除。