前段时间,由于工作需要,对ASP.NET的3种编译模式进行了简单的LoadRunner压力测试。包括ASP.NET WebSite站点动态编译,WebSite站点预发布,以及WebApplication预编译release三种模式在并发用户数200,500,100的三种情况下响应总时间均值,First buffer Time均值,CPU峰值。
为了尽量让数据客观、公正,又能让测试数值不至于“扎堆”,我选择了我们公司一个中型项目,把比较有代表性,并且相对业务复杂的首页分别做成websitecode(动态编译)、WebsiteRelease(预发布)和Webapplication(Release发布)三种项目,在公司相对比较独立的测试环境中,用LoadRunner进行测试。由于时间关系,只整理了并发用户数200,500,100的三种情况下的数据,可能并不能完全精准的说明什么,只希望能给出某些启示。
以下给出详细数据
响应总时间均值
个人分析:从以上数据(图表)可以很明显看出,Website预分布方式在随着并发用户数量增加的情况下,服务总时间是有相对优势的,平均是1秒左右:)当然在并发用户200及以下,它跟webapplication方式没有明显区别,但Website动态编译却表现最差:(
First buffer Time均值
个人分析:Frist Buffer Time是我个人最关注的数据,因不在网络传输中有这样那样的不可控和不可预计的因素,所以这个时间最能客观描述三种编译模式的首次访问时间优劣。以上面的数据和图片中,我们很明显看出Website是那么的表现“异常”,当然这个我们不难想像。但让我们“小意外”的是,大概在并发800以下,webapplication居然比website预发布的模式稍差:(
CPU峰值
个人分析:以上是瞬时CPU峰值,可以看出Website预发布方式的CPU最让人揪心,其次是是Webaplication,最次是website动态编译,而且website动态编译在并发500以下,貌似没有CPU的上升。
总结:自从最早接触.net1.1以来,就一直用webapplication方式进行项目架构、设计,并习惯于把所有的CS打包到一个统一的DLL中。自从vs2005发布,做了一看多的website项目,无奈中用websiterelease的方式开发一年,而且随之发现网站的随时更新不可能每天用websiterelease发布,于是还用了一个好像名叫web develpment插件工具,还好,没有多久vs2005sp1替代了这个东西。随之,也于website动态站点告以byebye。
跟很多开发前辈、兄弟一样,本人对website动态编译有种说不出来的打从心底里面出来的莫名的抵制,毕竟它的“宽松式”项目管理理念让本来就要严谨的项目开发变得好像不那么靠谱,就想某个东西被卡在喉咙!!但往往跟它PK的时候,总是说不出一个所以然。而且很多时候唯一能说服人的,就是编译!今天通过以上数据,我们可以看出,其实无论什么编译模式,都有优有劣。
按我们公司测试部数据换算,账大概是这样算的,1000并发用户的情况,大约是每天1亿的PV,如果你的公司团队,技术人员是20以上,PV是1000万级的,毫无疑问,请选择Webapplication,无论是它cpu的表现稳定性,瞬时响应稳定性。但如果你公司是3人以下技术人员,每天访问10万以上,website动态编译是不错的选择。
南晓斌
2010.11.1