【问题标题】:How to avoid passing slow Application_Start times to the end users in ASP.NET如何避免将缓慢的 Application_Start 时间传递给 ASP.NET 中的最终用户
【发布时间】:2012-07-21 08:36:16
【问题描述】:

由于在启动时发生了很多 IoC 事情,我的 Application_Start 非常慢。

我要解决的问题是,如何避免将启动时间传递给最终用户?

假设

我的应用程序托管在 AppHarbor 上,因此我无法访问 IIS。但是,即使我这样做了,我的研究是让应用程序池回收是最佳实践,因此无法避免 Application_Start 定期运行(我认为在 AppHarbor 上每 20 分钟运行一次)。

我的解决办法

最初我以为我会每隔一分钟或什么时候点击它,但这似乎太暴力了,甚至可能无法阻止用户体验启动缓慢。

我目前的解决方案是处理 Application_End 事件,然后立即点击应用程序使其再次启动,因此希望不会影响任何用户。

有没有更好的方法来解决这个问题?

【问题讨论】:

  • 您确定它们每 20 分钟回收一次吗? IIS 上的开箱即用体验是它们会在 20 分钟内没有任何活动时关闭应用程序池。当然,第一次命中会慢一些,但除非你在Application_Start 中做疯狂的事情,否则这应该不是问题。
  • 嘿马丁,是的,它是每 20 分钟,根据 AppHarbor。不管你是对的,它是一个使用率非常低的网站,所以它可能没有受到足够的打击。所以有可能我可以每 15 分钟打一次它,这样它就不会睡觉了......?
  • 我会调查Application_Start。实际需要多长时间?能不能优化一下,让第一次命中有一点延迟就不是问题了?
  • 嘿,马丁,需要 5 到 10 秒,这都是温莎 IoC 的东西。我有点不介意,只要用户不必体验它。
  • 好吧,如果不超过 5-10 秒,我不会打扰。

标签: asp.net-mvc-3 iis-7 ioc-container global-asax appharbor


【解决方案1】:

很遗憾,当您使用 InProcess 会话状态时,较长的会话超时不会阻止 IIS 应用程序池回收。

您是否考虑过延迟加载(某些)您的依赖项? SimpleInjector 有关于如何做到这一点的文档,它应该适用于大多数其他 IoC:

Simple Injector \ Documentation \ How To \ Register Factory Delegates \ Working With Lazy Factories

【讨论】:

  • +1 有趣,我会检查延迟加载。当您谈论进程内会话状态时,您是什么意思?
  • +1 最小化加载时间的最佳方法是通过将特定组件的加载推迟到第一次真正需要它们时,最大限度地减少加载时发生的事情。
  • 抱歉,回复晚了,安迪。会话状态可以以多种方式存储。默认方法是 InProcess,它只是在 IIS 服务器的内存中。如果您的应用程序仅在一台服务器上运行并且您对应用程序池回收很敏感,那么它很简单并且可以正常工作。另一种方法是将会话存储在数据库中,它们将在应用程序池重置或用户在负载平衡环境中的服务器之间跳转时存活下来。
【解决方案2】:

在我的理解中,为了防止启动时间传播给用户,你应该避免回收应用程序池,你可以使用IIS App pool timeout settings,这些可以通过web.config进行调整,而不仅仅是通过IIS控制台。此外,您可以阅读更多内容here on this SO qurestion。您可能不需要 Application_End hack 来实现这一点。

更新: 我发现了另一件有趣的事情可以帮助你,检查这个IIS Application Initialization Extension,它可以用来在工作进程启动时预加载依赖项。它可以帮助您改善客户体验。看看吧。

【讨论】:

  • +1 感谢furqan,但是应用池不需要回收吗?我现在检查你的链接
  • 应用程序池回收可以最小化,但绝不应该消除。此外,许多托管公司不允许您 100% 控制应用程序池回收参数(通常强制应用程序池回收以超出资源分配,例如内存)。这仍然是很好的建议,但不是这个问题的“最佳答案”。
  • 如果您可以在不泄漏内存的情况下进行编码(显然可以!)您应该禁用 AppPool 回收 imo。所以我认为这确实是最好的答案。
猜你喜欢
  • 1970-01-01
  • 2015-10-18
  • 2012-09-06
  • 1970-01-01
  • 1970-01-01
  • 2019-05-08
  • 2020-10-09
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多