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

Question

目前，在构建/部署我们的应用程序(58个项目，大型asp.net MVC3前端)之后，加载需要大约15-20秒，因为它经历了整个“回收应用程序池”(发布配置)。

我们确实有一个网络农场，如果它改变了人们的答案，但真正的问题是：

在维护窗口不可行的大型应用程序中(我们是一个全天候非常活跃的网站)，人们在部署后如何最小化应用程序池回收的初始“第一次命中”？

我们已经使用了许多工具来分析启动时间，但似乎没有任何方法可以降低启动时间，所以我要寻找的是人们采用哪些技术来最小化大型应用程序部署对用户的影响。

Answer 1

默认情况下--如果你一次更改ASP.NET应用程序中的15个文件(即使是通过FTP)，那么应用程序池将自动回收。您可以更改文件的数量，但是一旦web.config和bin文件发生更改，它就需要回收。因此，在我看来，对于您这样的环境，理想的解决方案如下所示：

4个web服务器(这是一个任意的数字)每个服务器都有一个负载均衡器查看的status.aspx -使用TeamCity使这些服务器中的2个“离线”(离线负载均衡器)，并等待20秒，让流量通过。分布式缓存将有助于保持用户体验问题

使用TeamCity部署到这两台服务器-运行您的自动化测试等，一旦您满意，就将它们放回场中，并使其他两台服务器离线并部署到这些服务器上

这一切都可以是脚本化/自动化的。这样做的唯一问题是，任何不向后兼容的架构更改都可能不允许在20秒内并行运行新版本站点和旧版本站点，以便负载均衡器恢复运行

这是一个很好的老式金丝雀版本-这里有一些模式http://continuousdelivery.com/patterns/可以帮助考虑。我还建议复制一本持续交付手册-它就像一本持续交付圣经，已经让我摆脱了几种情况:)

Answer 2

在最基本的基础上，您可以在部署完成后针对应用程序运行tinyget脚本，这将“预热”应用程序。但是，如果客户在脚本运行之前访问您的站点，他们仍将面临延迟。您目前有什么部署步骤，部署后步骤有哪些？

在服务器场环境中，您也可以分阶段部署，因此将一台服务器置于负载平衡状态，对其进行更新，然后在部署后将其联机，并取出另一台服务器，完成部署，然后重新引入到服务器场中。您的SQL Server设置是如何群集化的？

Answer 3

copy and paste from my post here

我们在4层架构上运行蓝/绿部署策略，该架构在顶层有超过4台服务器的网站。由于架构为部署引入的复杂性，我们需要一种在不干扰“实时”站点流量的情况下进行部署的方法。按照Fowler的建议，但不完全是以同样的方式，我们提出了一个解决方案，即在每台服务器上有两个站点(一个蓝色和一个绿色，或者在我们的例子中是站点A和站点B)。活动站点有适当的主机头，一旦我们部署并测试到非活动站点，我们就翻转两个站点的头，这样曾经活动的站点现在就变成了非活动站点，反之亦然。其效果是，一个健壮的部署，可以在工作时间和最高水平的信心完成。

这当然会使您的配置和部署稍微复杂一些，但这是值得的。我想不用说，你想同时编写部署脚本和主机头交换脚本。