目前，在构建/部署我们的应用程序(58 个项目，大型 ASP.NET MVC 3 前端)之后，加载整个“回收应用程序池”(发布配置)需要大约 15-20 秒。
如果这会改变人们的答案，我们确实有一个网络农场，但问题确实是:
在维护窗口不可行的大型应用程序中(我们是一个 24/7 非常活跃的网站)，人们在做什么以尽量减少部署后应用程序池回收的初始“第一次命中”？
我们已经使用了许多工具来分析启动时间，但似乎没有任何方法可以缩短启动时间，因此我要寻找的是人们采用哪些技术来最大程度地减少大型启动时间的影响影响用户的应用程序部署。
最佳答案
默认情况下 - 如果您一次更改 ASP.NET 应用程序中的 15 个文件(甚至通过 FTP)，则应用程序池会自动回收。您可以更改文件数量，但一旦 web.config 和 bin 文件更改，则需要回收。因此，在我看来，像您这样的环境的理想解决方案如下:
4 个网络服务器(这是一个任意数字)
每个服务器都有一个负载平衡器查看的 status.aspx - 使用 TeamCity 使其中的 2 个服务器“脱机”(从负载平衡器)并等待 20 秒让流量过滤。分布式缓存将有助于解决用户体验问题
使用 TeamCity 部署到这 2 台服务器 - 运行您的自动化测试等，一旦您感到满意，将它们放回服务器场并将其他 2 台脱机并部署到那些服务器上
这都可以脚本化/自动化。唯一的问题是任何不向后兼容的架构更改可能不允许新版本站点与旧版本站点并行运行 20 秒，以便负载均衡器重新启动
这是很好的老式 Canary 发布 - 这里有一些模式 http://continuousdelivery.com/patterns/以帮助考虑。我还推荐了一本持续交付书的副本——它就像一本持续交付圣经，让我摆脱了一些情况:)
关于asp.net-mvc - 人们如何解决大型应用程序部署时的应用程序池回收问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8151860/