Configure an Application Pool to Recycle at a Scheduled Time (IIS 7)

IIS默认的应用程序池回收时间是29小时,这个时间,有点“神秘”,不排除在业务繁忙期间。因此指定在凌晨会更靠谱些。有的小伙伴写VB脚本,再计划任务,感觉不如直接使用appcmd命令直接解决指定时间回收的需求。

image

For example, to schedule an application pool named Marketing to recycle daily at 3:00 PM, type the following at the command prompt, and then press ENTER:

appcmd set apppool /apppool.name: Marketing /+recycling.periodicRestart.schedule.[value=’15:00:00′]

For example, if you want the Marketing application pool from the previous example to recycle at 5:00 PM, type the following at the command prompt and then press ENTER:

appcmd set apppool /apppool.name: Marketing /recycling.periodicRestart.schedule.[value=’15:00:00′].value:17:00:00

源自:https://technet.microsoft.com/en-us/library/6c74bc0a-cf98-4ac3-93c2-3991c09502fe

IIS站点不间断更新服务(热部署)IDEA

最近做应用发布的工作比较多,考虑到白天会有第三方平台(跨境购)推送订单过来,一般白天也不做部署更新。如果白天要做部署,应该如何做呢?

方案一:本身工程结构不做调整,增加一个第三方平台接口路由中转。

由于第三方平台接口相对是稳定的,意味着接口路由器也是稳定的,接口路由器,有点像Channel Interface(Not every body known this),本身仅请第三方请求做中转,并将请求持久化下来。在做更新的时候,万一有订单、商品等请求过来,可以使用接口路由器重发报文。这样子,应用站点就可以任性的随时更新了,不用等到一个特定时间去部署更新。而且,怎么选时间去部署,都有丢报文的风险。

方案二:调整工程,抽离引擎代码、业务代码,大DLL分解成小Dll,拆分,拆分

这种做法与接口路由是有神似的地方,找出变化点,抽离出来。目前来看,工程build之后一个大大的api dll,内部系统、brother系统、第三方系统接口全在一起,内部做个小调整,部署还要影响第三方系统接口的正常访问。这个是一个问题点。另外,针对第三方平台的工程组成,至少分离出报文接收+报文处理,报文接收的调整可能性非常小,实时更新报文处理组件的时候,如造成异常,还能找到报文。

调整自然有好有坏,这么拆拆拆,会拆出一堆小工程出来。一堆小组件,一堆小引擎。

方案三:部署自动化,Package可以不断的发布到一个缓冲池里,凌晨的时候自动释放。

这种方式,要求精心制作Package,能用自动验证Package是否正常发布,毕竟是自动完成。这种方式有点穿越,站在了不同的时间轴上。对于研发来说,发布,上传了Package,应用程序并不实时更新,但是可以当成“完成了”发布。这种方案同样需要研发一套Package标准+更新引擎。

方案四:大名为“云部署”、“云应用”

将Package部署包制作完之后,放到一个应用市场中,研发人员不管更新了,由业务人员依据业务情况更新。这种方案同样需要研发一套Package标准+更新引擎。这种方案,在软件客户超过1个,比较省心。如果达到几十上百,那应该是不错的部署更新方案了。

Select Update形成的死锁ABC

事务(进程 ID 60)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。

查资料的大意,select使用了非聚集索引,会形成一个S锁,而update修改的列是非聚集索引的列,于是针对这个非聚集索引增加了一个X锁,然后就死锁了。

我也被绕晕了,请自行查看原博主的文章详细了解。对于什么是聚集索引,什么是非聚集索引,偶也转载了一篇通俗易懂的文章 。就是上一篇啦!

由于博主明确注意要经过允许后才转载,Balabala,来2个链接好了。

参考解决方案 :

http://blog.csdn.net/lishehe/article/details/42279147

http://blog.csdn.net/lishehe/article/details/42303457