JK.*_*JK. 16 deployment asp.net-mvc performance web-deployment-project visual-studio
我目前使用Web Deploy,http: //learn.iis.net/page.aspx/346/web-deploy/来发布我的MVC2应用程序.它曾经运作良好,但现在它已经达到我无法继续使用它的程度:
当MVC应用程序很小并且只有少数用户时,它很容易发布.只需在Visual Studio中右键单击该项目,然后选择"发布".而且因为只有少数用户很容易找到没有人使用该网站进行快速更新的时间.
然后应用程序变得更大,并有更多的用户."发布"操作开始时间越来越长,偶尔会超时.即使我在部署之前回收了应用程序池,它仍然需要很长时间.
此外,当没有人使用该网站时,更难找到时间,因此可以在不影响任何人的情况下完成更新.
然后"发布"操作每次都开始计时,我不得不根据之前未解决的问题切换到手动部署:Visual Studio 2010 - Web部署超时 - 该怎么办?
现在手动部署需要更长时间,从5分钟到20分钟.并且用户数量显着增长,因此部署总是会影响某人(响应时间慢,超时,站点不可用等)
那我该怎么办?有没有比使用Web部署更好的替代方案?
编辑:
今天的部署花了18分钟才发布了49个已更改的文件.这种情况很荒谬,是我们网站目前最大的弱点之一.因此,我希望能够解决这个问题,从而获得了不错的奖金.
还有一些可能导致解决方案的问题:
回答答案:
回复:http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html这正是我进行部署的方式,也是一种理想的方法.Web部署可以正确识别哪些文件已更改,但它会超时并且不会发生发布.解决方案中大约有2500个文件,可能需要很长时间才能确定哪些文件发生了变化?或者可能是发布的超时值很短,只需上传15mb的zip文件即可使用所有时间.
我确实可以完全控制服务器,它确实支持Web部署.实际上有2台服务器:主服务器和冗余服务器,我们会在第一次服务器崩溃时做好准备.因此,任何解决方案都必须易于部署到多个服务器(Web部署是理想的,直到它停止工作).
为每个版本创建一个新文件夹,然后只是将IIS更改为指向该新文件夹的建议听起来像是在发布期间会导致更短的停机时间/慢速时间.但这是一个非常手动的过程,我更喜欢更自动化的东西.
编辑#2
我已经设法缩小它,并找到它确切的缓慢 - 但不是为什么.这来自部署日志:
[9/02/2011 12:11:56 a.m.] Performing synchronization pass #1.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/1' is applicable to 'iisApp/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'Add write permission to App_Data Folder/1' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data' because of its scope.
[9/02/2011 12:11:56 a.m.] Source createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True']). Update pending.
[9/02/2011 12:11:56 a.m.] Update operation on createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) skipped because of rule CreateApplicationRule.
[9/02/2011 12:11:56 a.m.] Source filePath (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data\Create.sql) does not match destination (Default Web Site/virtual-dir/App_Data\Create.sql) differing in attributes (size['259691','259697'],lastWriteTime['02/08/2011 10:45:20','02/06/2011 03:48:16']). Update pending.
[400 lines of file updates skipped, time expired 2 seconds ....]
[9/02/2011 12:11:58 a.m.] Delete operation on filePath (Default Web Site/v2/zzz_app_offline.htm) skipped because of rule DoNotDeleteRule.
[9/02/2011 12:11:58 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:11:58 a.m.] Updating setAcl (Default Web Site/virtual-dir/).
[9/02/2011 12:13:47 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:13:47 a.m.] Updating setAcl (Default Web Site/virtual-dir/).
[9/02/2011 12:17:11 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data) does not match destination (Default Web Site/virtual-dir//App_Data) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:17:11 a.m.] Updating setAcl (Default Web Site/virtual-dir//App_Data).
[9/02/2011 12:17:11 a.m.] The dependency check 'DependencyCheckInUse' found no issues.
[9/02/2011 12:17:11 a.m.] The synchronization completed in 1 pass(es).
Run Code Online (Sandbox Code Playgroud)
缓慢的原因是"Updating setAcl"组件.我正在检查开发盒和服务器盒的ACL,看看有什么不同.但是,将ACL从开发框复制到服务器框似乎是一个非常糟糕的主意!我已经在服务器上设置了ACL.
我首先尝试隔离发生超时的位置。您提到了一个包含 2,500 个文件的 15MB zip,我觉得它并不是特别大。您是否尝试过在 Visual Studio 中创建部署包然后直接在服务器上运行它?这将消除网络延迟,这是超时时一个非常基本的变量。
至于为什么需要上传包含整个应用程序的 zip,您需要记住更改内容的实际标识以及随后部署到 IIS 中的所有操作都发生在服务器上。这不是本地计算机上的 Visual Studio 或 msdeploy 负责的。
至于为什么不直接手动复制更改的文件,您引用的我的博客文章中对此进行了总结,但总之,这是费力且容易出错的。这意味着您需要有意识地思考“我的 2,500 个文件中的哪些文件刚刚发生了更改”,而不是简单地说“使我的目标站点与我的开发版本相匹配”。您没有提到是否要发布 web.config,但显然配置转换是简单的 CTRL-C 然后 CTRL-V 方法很麻烦的另一个重要原因。
尝试直接从 SVN 进行更改也是有风险的。您的第一个问题是,如果您要发布适当的更改,您需要对要更新的修订版的完整性和准确性有完全的信心。然后,您需要尝试将这些同步到目标,并且又回到上一段中提出的相同问题。另一个大问题是版本控制目标代码总是令人讨厌;您将永远处于与项目中其他人发生冲突的状态,而 VCS 根本不打算以这种方式运行。
我的建议是专注于解决问题的根本原因 - Web 部署超时 - 而不是简单地尝试解决症状。从长远来看,仅手动发布更改或搞乱 IIS 绑定只会给您带来更多麻烦,并在短期内带来更多工作。了解如何共享创建包的结果,将其复制到服务器,然后在本地执行,我们将从那里获取它。一旦按照设计工作,您应该会看到部署时间不超过几分钟,站点中断时间以秒为单位。
顺便说一句 - 您可能还想添加 PC 和服务器之间的延迟类型以及通过 HTTP 传输 15MB 文件通常需要多长时间。
| 归档时间: |
|
| 查看次数: |
2897 次 |
| 最近记录: |