ASP.NET 3种编译模式压力测试

http://hi.baidu.com/yangczcz/item/455089047ee1c717cd34ea12

前段时间，由于工作需要，对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动态编译是不错的选择。