目前，在构建/部署我们的应用程序（58 个项目，大型 asp.net MVC 3 前端）之后，加载整个“回收应用程序池”（发布配置）需要大约 15-20 秒。
如果这会改变人们的答案，我们确实有一个网络农场，但问题确实是：
人们在维护窗口不可行的大规模应用程序中做什么（我们是一个 24/7 非常活跃的网站），以最大限度地减少部署后应用程序池回收的初始“第一次命中”？
我们已经使用了许多工具来分析启动时间，但似乎没有任何方法可以降低启动时间，所以我正在寻找的是人们采用哪些技术来最大限度地减少大型应用程序部署影响用户。
默认情况下 - 如果您一次更改 ASP.NET 应用程序中的 15 个文件（甚至通过 FTP），则应用程序池会自动回收。您可以更改文件的数量，但一旦更改了 web.config 和 bin 文件，就需要对其进行回收。因此，我认为像您这样的环境的理想解决方案如下：
4 个 Web 服务器（这是一个任意数字），每个服务器都有一个 status.aspx，负载均衡器会查看它 - 使用 TeamCity 使其中 2 个服务器“离线”（关闭负载均衡器）并等待 20 秒以等待流量过滤过去。分布式缓存将有助于解决用户体验问题
使用 TeamCity 部署到这 2 台服务器 - 运行您的自动化测试等，一旦您满意，将它们放回农场，让另外 2 台脱机并部署到那些
这都可以脚本化/自动化。唯一的问题是任何不向后兼容的架构更改可能不允许新版本站点与旧版本站点并行运行 20 秒以使负载均衡器重新启动
这是很好的老式 Canary 发布 - 这里有一些模式http://continuousdelivery.com/patterns/可以帮助考虑。我还建议了一本持续交付书的副本——它就像一本持续交付圣经，让我摆脱了一些情况:)
从根本上说，您可以在完成部署后对应用程序运行一个 tinyget 脚本，这将“预热”应用程序，但是如果客户在脚本运行之前访问您的站点，他们仍然会面临延迟。你目前有什么，你有什么部署后的步骤？
在农场环境中，您也可以进行部署，因此将一台服务器从负载平衡中取出，对其进行更新，然后在部署后使其联机，然后将另一台服务器取出，完成部署，然后重新引入农场。您的 SQL Server 设置如何 - 群集？
我们在 4 层架构上运行蓝/绿部署策略，该架构在顶层有一个超过 4 台服务器的网站。由于为部署引入的架构很复杂，我们需要一种在不干扰任何流向“实时”站点的流量的情况下进行部署的方法。按照 Fowler 的建议，但方式不完全相同，我们提出了一个解决方案，这意味着我们在每台服务器上都有 2 个站点（一个蓝色和一个绿色，或者在我们的案例中是站点 A 和站点 B）。活动站点具有适当的主机标头，一旦我们部署并测试到非活动站点，我们就会翻转 2 个站点的标头，以便曾经活动的现在是非活动站点，反之亦然. 其效果是，可以在工作时间内以最高的信心完成强大的部署。
这当然会使您的配置和部署稍微复杂化，但值得付出努力。我想不用说你想编写部署和主机头交换的脚本。
首先，除非您运行的是 Google 或更大的系统，否则凌晨 3 点 15 到 20 秒的加载时间对少数用户真的有那么大的影响吗？我想说为消除偶尔的滞后所付出的努力将远远超过几个用户在 15 到 20 年代带来的不便。
不幸的是，我认为使用 ASP.NET 是必要的坏事。使用预编译站点（.DLLs 而不是代码隐藏文件）将减少时间，但不一定消除它。
您可以做的最好的事情是使用状态通知栏之类的东西来警告用户他们在“基本维护”期间可能会遇到一些“问题”。
但即便如此，我会说，就用户体验而言，当您的网站一次加载需要 20 秒时，最好保持安静并让少数人指责他们的“网速慢”，而不是向所有人宣布它会很慢。
在对您的站点一无所知的情况下，我的第一个想法是您可以将其分解为较小的站点，以便它们单独启动更快。
其次，对于您的网络农场，我假设您在其前面有某种负载平衡设备，您可以在部署机器时将它们从池中拉出。在您向站点发送请求以启动它之前，不要将它们放回池中。您应该能够编写脚本，这样您几乎可以单击一个按钮，该按钮将机器取出，部署到它，并在它备份并满意后发送请求。
您可以考虑使用aspnet_compiler.exe来预编译您的应用程序，因为我认为部署后的延迟是由编译阶段引起的，而不是“整个回收应用程序池”。