人们如何解决大型应用程序部署时的应用程序池回收问题？
目前，在我们的应用程序（58 个项目，大型 asp.net MVC 3 前端）构建/部署后，需要大约 15-20 秒的时间来加载，因为它会经历整个“回收应用程序池”（发布配置）。
如果这会改变人们的答案，我们确实有一个网络农场，但问题实际上是：
人们在维护窗口不可行的大型应用程序中做什么（我们是一个 24/7 非常活跃的网站），以最大程度地减少最初的影响部署后应用程序池回收的“第一次命中”？
我们使用了许多工具来分析启动时间，但似乎没有任何方法可以降低它，所以我正在寻找的是人们采用哪些技术来最大程度地减少大型启动的影响应用程序部署影响用户。
Currently after a build/deployment of our app (58 projects, large asp.net MVC 3 front end) takes ~15-20secs to load as it goes through the whole 'recycling the app pool' (release configuration).
We do have a web farm if that alters people's answers, but the question really is:
What are people doing in large scale applications where a maintenance window isn't viable (we're a 24/7 very active website) to minimize that initial 'first hit' on the app pool recycle after a deploy?
We've used a number of tools to analyze that startup time and there doesn't really seem to be any way to bring it down so what I'm looking for are what techniques do people employ in order to minimize the impact of a large application deploy affecting users.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
默认情况下 - 如果您一次更改 ASP.NET 应用程序中的 15 个文件（即使通过 FTP），则应用程序池将自动回收。您可以更改文件数量，但一旦 web.config 和 bin 文件更改，就需要回收。因此，我认为像您这样的环境的理想解决方案如下：
4 个 Web 服务器（这是任意数量）
每个服务器都有一个负载均衡器查看的 status.aspx - 使用 TeamCity 将其中 2 个服务器“离线”（脱离负载均衡器）并等待 20 秒以便过滤流量。分布式缓存将有助于解决用户体验问题
使用 TeamCity 部署到这 2 台服务器 - 运行自动化测试等，一旦您满意，将它们放回服务器场，然后将另外 2 台服务器脱机并部署到这些服务器
这一切都可以编写脚本/自动化。唯一的问题是任何不向后兼容的架构更改可能不允许新版本站点与旧版本站点并行运行 20 秒，以便负载均衡器恢复。
这是很好的老式金丝雀发布 -这里有一些模式可以帮助考虑。我还建议你读一本持续交付的书——它就像一本持续交付的圣经，让我摆脱了一些情况:)
By default - if you change 15 files in an ASP.NET application at once (even via FTP) then the app pool is automatically recycled. You can change the number of files but as soon as web.config and bin files are changed then it needs to recycle. So in my opinion the ideal solution for an environment like yours would be as follows:
4 web servers (this is an arbitrary number)
each server has a status.aspx that the load balancer looks at - use TeamCity to take 2 of these servers "off line" (off the load balancer) and wait 20 seconds for the traffic to filter across. A distributed cache will help keep user experience problems
Use TeamCity to deploy to those 2 servers - run your automated tests etc. and once you are happy put those back into the farm and take the other 2 offline and deploy to those
This can all be scripted / automated. The only issue with this is any schema changes that are not backwards compatible may not allow running the new version site in parallel with old version of the site for the 20 seconds for the load balancer to kick back in
This is good old fashioned Canary Releasing - there are some patterns here http://continuousdelivery.com/patterns/ to help take into consideration. Id also suggest a copy of that continuous delivery book - its like a continuous delivery bible and has got me out of a few situations :)
从根本上讲，您可以在部署完成后针对应用程序运行一个tinyget脚本，这将“预热”应用程序，但是如果客户在脚本运行之前访问您的网站，他们仍然会面临延迟。您目前采取了哪些措施？部署后采取了哪些步骤？
在场环境中，您也可以分阶段部署，因此使一台服务器脱离负载平衡，对其进行更新，然后在部署后将其联机，并取出另一台服务器，完成部署，然后重新引入场。您的 SQL Server 设置是如何集群的？
At the very base you could run a tinyget script against the application after completion of deployment which will "warm up" the application however if a customer hits your site before the script can run, they will still face a delay. What do you currently have in place, what post deployment steps do you have in place?
In a farm environment you could stage deployments too, so take one server out of load balance, update it and then bring that online after deployment and take the other out, complete the deployment and then reintroduce into the farm. How is your SQL Server setup - clustered?
从我的帖子复制并粘贴到此处
我们在 4 层架构上运行蓝/绿部署策略，该架构的顶部有超过 4 台服务器的网站层。由于部署架构的复杂性，我们需要一种在不干扰“实时”站点流量的情况下进行部署的方法。遵循 Fowler 的建议（但方式不完全相同），我们提出了一个解决方案，这意味着我们在每台服务器上有 2 个站点（蓝色和绿色，或者在我们的示例中为站点 A 和站点 B）。实时站点具有适当的主机标头，一旦我们部署并测试到非实时站点，我们就会翻转两个站点的标头，以便曾经实时的站点现在是非实时站点，反之亦然。其效果是，可以在工作时间内以最高的信心完成稳健的部署。
这当然会使您的配置和部署稍微复杂化，但这是值得的。我想这是不言而喻的，您想要编写部署和主机头交换的脚本。
copy and paste from my post here
We operate a Blue/Green deployment strategy on a 4 tier architecture which has a web site over 4 servers at the top tier. Due to the complexity the architecture introduced for deployments, we needed a way to deploy without disturbing any traffic to the "live" site. Following Fowler's advice, but not quite in the same way, we came up with a solution that means we have 2 sites on each server (a blue and a green, or in our case site A and site B). The live site has the appropriate host header, and once we have deployed and tested to the non-live site, we then flip the headers of the 2 sites so that what was once live is now the non-live site, and vice-versa. The effect is, a robust deployment that can be done in business hours and with the highest level of confidence.
This of course complicates your configuration and deployment slightly, but it's worth the effort. I guess it kind of goes without saying that you want to script both the deployment, and the host header swapping.
首先，除非你运行的是 Google 或更大的东西，否则凌晨 3 点 15 到 20 秒的加载时间对少数用户来说真的会产生那么大的影响吗？我想说，为消除偶尔的延迟而投入的努力将远远超过几个用户 15 到 20 秒的不便。
不幸的是，我认为这是使用 ASP.NET 的必然弊端。使用预编译站点（.DLL 而不是代码隐藏文件）会减少时间，但不一定能消除时间。
您能做的最好的事情就是使用状态通知栏之类的东西来警告用户他们在“基本维护”期间可能会遇到一些“问题”。
但即便如此，我想说，就用户体验而言，当您的网站一次需要 20 秒才能加载时，最好保持安静，让少数人指责他们的“网速慢”，而不是向所有人宣布这会很慢。
Firstly, unless you're running Google or something bigger, does a 15-20s load time at 3am for a handful of users really impact that much? I'd say the effort invested in eliminating the occasional lag would far outweigh the 15-20s inconvenience of a couple of users.
I consider it a necessary evil of using ASP.NET unfortunately. Using a pre-compiled site (.DLLs instead of the code-behind files) will lessen the time but not necessarily eliminate it.
The best thing you can do is use something like a status notification bar to warn users they may experience some "issues" during "essential maintenance".
But even then, I'd say in terms of user experience it'd be better to keep quiet and have a handful of people blame their "slow internet" when your site takes 20s to load on one occasion, than announce to all and sundry that it will be slow.
您也可以尝试这种方法： http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series。 ASPX
You can also try this approach : http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
在对您的网站一无所知的情况下，我的第一个想法是您可以将其分解为更小的网站，以便它们单独启动更快。
其次，对于您的网络场，我假设您在其前面有某种负载平衡设备，您可以在部署机器时将其从池中拉出。在您向网站发送启动请求之前，请勿将它们放回池中。您应该能够编写此脚本，这样您几乎只需单击一个按钮即可取出一台机器，部署到它，并在它备份并满意后发送请求。
without knowing anything about your site, my first thought is that you might be able to break it down into smaller sites so that they start faster individually.
second, with your web farm, i assume you have some sort of load balancing device in front of that from which you can pull machines out of the pool when they are being deployed. don't put them back in the pool until after you have sent a request against the site to get it started up. you should be able to script this such that you are pretty much clicking a button that takes a machine out, deploys to it, and sends a request after it's back up and happy.
您可以考虑使用
aspnet_compiler.exe来预编译您的应用程序，因为我认为部署后的延迟是由编译阶段引起的，而不是“整个回收应用程序池”。You can consider using
aspnet_compiler.exeto precompile your application, because I think the delay after deployment is caused by the compilation phase rather than "whole recycling the app pool".