【原创】构建高性能ASP.NET站点 开篇

 

构建高性能ASP.NET站点 开篇

 

  前言:有段时间没有写ASP.NET的东西了,心里总是觉得缺少了什么,毕竟自己对ASP.NET还是情有独钟的. 在本系列文章中,准备比较全面的讲述ASP.NET的性能的优化,从前台到后台,以后本列文也看作为大家的一个手册来查询!

 

 

  系列文章链接:

  构建高性能ASP.NET站点 开篇

  构建高性能ASP.NET站点之一 剖析页面的处理过程(前端)

  构建高性能ASP.NET站点之二 优化HTTP请求(前端)

  构建高性能ASP.NET站点之三 细节决定成败

  构建高性能ASP.NET站点 第五章—性能调优综述(前篇)

  大型高性能ASP.NET系统架构设计  

  构建高性能ASP.NET站点 第五章—性能调优综述(中篇)

  构建高性能ASP.NET站点 第五章—性能调优综述(后篇) 

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(上篇)—识别性能瓶颈

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下前篇)—简单的优化措施

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下后篇)—减少不必要的请求

  构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析

  构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

 

 

 

本篇的议题如下:

网站优化需要考虑的方面

 

网站优化需要考虑的方面

 

在用ASP.NET开发网站的时候,性能是永远需要考虑和关注的问题,性能不仅仅只是程序代码执行时候的速度,而是涉及到方方面面的东西。

 

就拿ASP.NET的一个请求来讲,从浏览器向服务器的ASP.NET网站发送请求开始一直到最后整个页面呈现在我们面前,其中请求经过的每一个步骤,都是有不同的调优方式的,而且调用的方法也很多,不仅仅只是常见的:缓存,多线程,异步等。

 

本系列的文章决定从两个大的方面来讲述调优:

前台调优:主要包含如何尽量的减少http请求,从http请求开始,到如何加载js, css,如何压缩传输的数据等。

 

后台调优:分析ASP.NET请求的处理过程,并在每一步给出相应的调优方法,而且在代码组织,架构和数据库的操作上面给出调优的方法。

 

记得在刚刚开发网站的时候,一提到提高性能,最容易也是最快想到的就是缓存,而且在微软官方的Best Practice的一些文档中也是建议:层层缓存(在数据存储层,DAL,BLL,UI等都要缓存)。然后在网站中就缓存遍地开花,最后的确实不尽人意。

 

另外的一个常见的优化针对数据库的:如尽量减少子查询,使用join联接;在常常需要查询的字段上面建立索引。确实,这些是很通用,也不错的一些规则。

 

而且还有一个体会就是,在优化性能的时候,如果选择优化代码和数据库,往往优化数据库的一些操作带来的效果会更加的好,很可惜的是:在项目中(至少在我开发的一些项目中),数据库仅仅就只是一个数据的存储设备而已,仅此而已,没有发挥出数据库的强大作用。所以还是建议对数据库的内部查询和存储的机制要熟悉,毕竟很多时候开发人员也担任了DBA的工作(很多公司没有正式的DBA)。

 

而且在项目中我们设计数据库的时候,特别是表字段的时候,是需要有些考虑的,很多人建议表字段的长度不要太长,这也是大家常见的建议,但是为什么?其实,这就需要懂得一些数据库的内部存储机制了:在数据库(SQL SERVER )保存的时候,数据是以为最小的单位的,每一页有8K的大小,如果你的一个表中的数据超过8K,那么这个表的数据就要分几个页面保存,这样在对数据进行查询的时候,就要跨页查询了,跨页是需要性能消耗的,如果数据都在一个页面上,那么速度肯定快些。

 

所以,要优化网站,就得知道性能消耗在哪里。

 

当优化的一个网站的时候,不是盲目的一概而论的,一般来说有两种情况:

1. 网站已经存在了,并且运行了,现在要优化。

2. 正在从头开发一个新的网站。

 

如果是第一种情况,那么首先要找出网站性能的瓶颈,从前台的请求的到后台的请求处理,一直到最后页面的呈现,都要一步步的审查。

 

如果是第二种情况,可能情况就稍微好一点,并且网站现在完全由我们控制,所有在开发和设计的过程中就可以采用很多的优化原则来优化。

 

优化不一定就是代码重写或者做些很大的改动,优化时一点点的累积的,就好比代码的重构一样,都是一个积累的效果。比如,是在页面一开始的时候载入js脚本,还是在整个页面的最后载入js脚本,有时候往往就只是简单的调整一下载入的文件,或者异步的载入脚本,或者通过CDN传输脚本等等方法,性能就提升了。性能的提升也不是没有代价的,有的代价很小,例如只是把脚本的载入放在页面最后,大的代价就是,例如买些服务器设备,如Content Delivery Network(CDN)来把静态的文件(js,css,image)传送到客户端。所以说,优化需要权衡策略。

 

不知道大家是否有过这样的体会:当看着自己开发出来的系统性能很好的时候,自己是很自信的,相反,如果系统很慢,有时真不想说这个系统是自己做的。

 

本篇是系列开篇,只是闲谈了一些优化的一些话题,实际的知识没有讲多少,希望大家见谅。

下篇开始,我们就开始优化之旅,敬请关注! :)

 

版权为小洋和博客园所有,欢迎转载,转载请标明出处给作者。

   http://www.cnblogs.com/yanyangtian

 

 

 

 

posted @ 2010-07-16 15:56  小洋(燕洋天)  阅读(18824)  评论(41编辑  收藏  举报