人们如何在部署大型应用时解决应用池回收问题？

目前,我们的应用程序(58个项目,大型asp.net MVC 3前端)的构建/部署需要大约15-20秒来加载,因为它通过整个"回收应用程序池"(发布配置).

如果改变了人们的答案,我们确实有一个网络农场,但问题确实是:

人们在维护窗口不可行的大规模应用程序中做了什么(我们是一个24/7非常活跃的网站),以最大限度地减少部署后应用程序池回收的初始"第一次打击"？

我们已经使用了许多工具来分析启动时间,并且似乎没有任何方法可以将其降低,所以我正在寻找的是人们使用什么技术来最小化大的影响应用部署影响用户.

默认情况下 - 如果您一次更改ASP.NET应用程序中的15个文件(甚至通过FTP),则应用程序池将自动回收.您可以更改文件数,但只要更改了web.config和bin文件,就需要回收.所以在我看来,像你这样的环境的理想解决方案如下:

4个Web服务器(这是一个任意数字)每个服务器都有一个负载均衡器查看的status.aspx - 使用TeamCity将其中2个服务器"脱机"(关闭负载均衡器)并等待20秒以获得流量过滤.分布式缓存有助于防止用户遇到问题

使用TeamCity部署到这两个服务器 - 运行您的自动化测试等,一旦您满意,将它们放回到服务器场并将其他服务器脱机并部署到那些服务器

这些都可以编写脚本/自动化.唯一的问题是任何不向后兼容的架构更改可能不允许与旧版本的站点并行运行新版本站点20秒,以便负载均衡器重新启动

这是一个很好的老式金丝雀释放 - 这里有一些模式http://continuousdelivery.com/patterns/来帮助考虑.我也建议连续交付书的副本 - 它像一个连续交付的圣经,并让我出了几个情况:)

在基础上,您可以在部署完成后对应用程序运行一个tinyget脚本,这将"预热"应用程序,但是如果客户在脚本运行之前访问您的站点,他们仍将面临延迟.你现在有什么,你有什么后期部署步骤？

在服务器场环境中,您也可以进行部署,因此请使一台服务器脱离负载平衡,更新它,然后在部署后将其联机并取出另一台服务器,完成部署,然后重新引入服务器场.您的SQL Server如何设置 - 群集？