在用ASPNET开发网站的时候性能是永远需要考虑和关注的问题性能不仅仅只是程序代码执行时候的速度而是涉及到方方面面的东西
就拿ASPNET的一个请求来讲从浏览器向服务器的ASPNET网站发送请求开始一直到最后整个页面呈现在我们面前其中请求经过的每一个步骤都是有不同的调优方式的而且调用的方法也很多不仅仅只是常见的缓存多线程异步等
文章决定从两个大的方面来讲述调优
前台调优主要包含如何尽量的减少http请求从http请求开始到如何加载js css如何压缩传输的数据等
后台调优分析ASPNET请求的处理过程并在每一步给出相应的调优方法而且在代码组织架构和数据库的操作上面给出调优的方法
记得在刚刚开发网站的时候一提到提高性能最容易也是最快想到的就是缓存而且在微软官方的Best Practice的一些文档中也是建议层层缓存（在数据存储层DALBLLUI等都要缓存）然后在网站中就缓存遍地开花最后的确实不尽人意
另外的一个常见的优化针对数据库的如尽量减少子查询使用join联接在常常需要查询的字段上面建立索引确实这些是很通用也不错的一些规则
而且还有一个体会就是在优化性能的时候如果选择优化代码和数据库往往优化数据库的一些操作带来的效果会更加的好很可惜的是在项目中（至少在我开发的一些项目中）数据库仅仅就只是一个数据的存储设备而已仅此而已没有发挥出数据库的强大作用所以还是建议对数据库的内部查询和存储的机制要熟悉毕竟很多时候开发人员也担任了DBA的工作（很多公司没有正式的DBA）
而且在项目中我们设计数据库的时候特别是表字段的时候是需要有些考虑的很多人建议表字段的长度不要太长这也是大家常见的建议但是为什么？
其实这就需要懂得一些数据库的内部存储机制了在数据库（SQL SERVER ）保存的时候数据是以页为最小的单位的每一页有K的大小如果你的一个表中的数据超过K那么这个表的数据就要分几个页面保存这样在对数据进行查询的时候就要跨页查询了跨页是需要性能消耗的如果数据都在一个页面上那么速度肯定快些
所以要优化网站就得知道性能消耗在哪里
当优化的一个网站的时候不是盲目的一概而论的一般来说有两种情况
网站已经存在了并且运行了现在要优化
正在从头开发一个新的网站
如果是第一种情况那么首先要找出网站性能的瓶颈从前台的请求的到后台的请求处理一直到最后页面的呈现都要一步步的审查
如果是第二种情况可能情况就稍微好一点并且网站现在完全由我们控制所有在开发和设计的过程中就可以采用很多的优化原则来优化
优化不一定就是代码重写或者做些很大的改动优化时一点点的累积的就好比代码的重构一样都是一个积累的效果比如是在页面一开始的时候载入js脚本还是在整个页面的最后载入js脚本有时候往往就只是简单的调整一下载入的文件或者异步的载入脚本或者通过CDN传输脚本等等方法性能就提升了
性能的提升也不是没有代价的有的代价很小例如只是把脚本的载入放在页面最后大的代价就是例如买些服务器设备如Content Delivery Network（CDN）来把静态的文件（jscssimage）传送到客户端所以说优化需要权衡策略
不知道大家是否有过这样的体会当看着自己开发出来的系统性能很好的时候自己是很自信的相反如果系统很慢有时真不想说这个系统是自己做的
