性能

1.我们能从哪些方面对系统的性能进行提升？

  编码级别：比如资源的释放
  页面级别：页面的缓存策略、页面的大小直接决定了客户端访问网站的速度和网络流量
  架构级别：一个好的架构能提升系统性能，而架构也可能称为整个系统的杀手
  配置和部署：一个同样的系统可能在两个相同硬件配置的服务器上产生明显的性能差异，由于网站是需要IIS进行解析的，网站所有的流量都要经过IIS              这个卡，如果IIS的配置不当的话对网站造成的性能影响是致命的

 <-----------------编码级别性能优化---------------->
2.数据访问

  ***数据连接：
 
  与数据库建立连接时非常耗费资源的(需要耗费验证等),好在有了数据库连接池，打开和关闭数据库连接不会真正访问数据库建立连接，不过连接池的  连接数是有大小限制的，如果每一次使用连接都长时间占用的话，最后会导致连接超出连接池的限制，因此，应该：
 
  尽量晚打开连接，尽量早关闭连接
  优化SQL语句或者存储过程，尽量缩短查询运行时间
  不同的连接字符串会导致不同的连接池

  ***数据查询：

  Select记录的时候，只返回需要的字段，不要Select * 把所有字段都返回，数据越多对于数据库服务器的压力也就越大，对于分布式程序还会占用更    多的网络流量
  尽量使用DataReader来进行数据读取，DataReader是只读向前形式读取数据的，DataReader性能比DataSet高 
  使用DataReader的时候尽量一次返回多个记录集，而不是为每个记录集打开一次数据库连接进行查询

  ***数据库优化
 
  一个表中的记录不要太多，把历史记录存入其他的表
  为需要搜索的字段建立索引，必要时可以建立全文索引(索引是以空间换取查询效率)

3.字符串操作

  用StringBuilder进行大量字符串拼接比String省时
  如果需要把字符串向客户端输出，可以直接输出而不用拼接后再输出

4.释放资源
 
  使用using来自动释放对象(Using定义了一个代码块，并且可以在代码块结束时释放对象)
  对于实现了Dispost模式的类型都可以使用using来确保它能被释放，对于数据库连接、文件连接和网络连接等非常重要的资源，我们都可以使用using来确保资源能释放

5.其他优化

 
  不要依赖异常(异常是不可预先感知的错误，不要用异常来“化解”已知的错误，应该通过预先的判断来避免异常的发生，而不是明知道异常可能会发生利用捕获异常来屏蔽可能的错误)
 
  使用泛型集合代替普通集合(能避免装箱拆箱操作，提高性能)
  不要大量使用反射

 

 <-----------------页面级别性能优化---------------->
1.页面缓存

2.视图状态

  服务器控件使用视图状态来保存控件的状态，但是某些大数据量的服务器控件会产生大量的ViewState代码，使得页面加载时间增加，网络负载增加，如果我们确信不需要和某个服务器控件进行交互，就可以通过设置控件的EnableViewState属性为false来关闭控件的视图状态，甚至可以直接关闭整个页面的视图状态(<%@ Page EnableViewState="false"%>)

3.页面加速

  尽可能把几个图片合并成一个图片来减少向Web服务器请求的次数
  尽量不要使用表格进行布局，特别是不要把整个页面放在一个大表格中，使用这个表格来定义整个页面。因为浏览器只有读到了一个标记的结束符后才  会呈现，如果把整个页面放在一个大表格中的话，那么只有等整个页面全部加载完毕后才会呈现
  尽量重复利用页面中的标签，如果页面中的很多代码是相似的，可以使用JS在客户端拼HTML代码而不要直接由服务器返回
  分离CSS，尽量把CSS分离到单独的文件中，而不要在每个页面的顶部都生成一段CSS代码，CSS文件能被客户端缓存，使用独立的CSS文件能减少页面的  数据量
  页面始终是由HTML代码构成的，千万不要使用Word文件直接生成HTML文件，那样的代码不但臃肿而且难以修改，ASP.NET程序员会使用大量的服务器控   件，服务器控件生成的代码页非常臃肿，笔者推荐大家使用一个叫CSS Control Adapter的文件来格式化由服务器控件生成的HTML代码

4.其他优化

  减少不必要的服务端事件(比如清空表单内容的草所，可以使用一个不回发的客户端按钮来实现，对于安全等级不高的一些操作完全可以使用客户端脚    本代替服务端操作，比如全选一个GridView中的所有记录等，即减轻了服务器压力又提高了用户体验)
 
  使用Page.IsPostBack来减少不必要的处理

 <-----------------构架级别性能优化---------------->

1.数据缓存

  双缓存：一个缓存更新的时候另外一个缓存提供数据。双缓存的方案在很多地方都有应用
 
  创建一个永不过期的缓存
  定期从数据库中获取最新的数据，把数据存放在一个容器中，比如DataSet。在这个过程中原先的缓存还是有效的
  把DataSet加入原先的缓存中替代原来的数据(这个过程是瞬间的)
  始终要记住：
  数据缓存应该用于补偿修改的数据，经常更新缓存会给数据库带来大量压力
  由于数据结构的问题，数据库中的10MB记录缓存到Cache中可能会增加到50MB左右，注意内存的占用
  缓存只适合数据的读取，使用DataSet存放缓存数据，然后通过DataSet的机制搜索数据性能非常差

2.分布式程序

  对于分布式程序来说，各个组件之间的通信形式决定了整个系统的性能

  对于单个机器上的应用来说，下面三个指标通常决定了整个程序的性能：
  磁盘操作时间、内存占用大小、CPU占用时间

  而对于分布式程序来说，网络对于程序性能的影响可能比上述三者都大，因此，需要尽量减少在网络上传递的数据的量，尽量改善通信方式，比如：
  在跨网段的情况下使用Web服务通信
  在同一个子网内使用Remoting Tcp 通道进行通信
  在同一个机器上使用Remoting Ipc通道进行通信

  不过，分布式程序同样也是提高性能的措施，对于一个大型系统来说，把一个系统的压力分布到多个物理服务器上，虽然增加了通信的事件，但是服务  器的压力减少了，程序的响应速度加快了。是否要分布，如何分布，还是要根据每一个项目自身的情况来决定

3.分布静态资源

  Web服务器不仅仅处理页面请求，还会处理图片、JS和CSS等静态资源的请求，往往图片请求的数据量非常大而且主要集中在磁盘上

  对于大型系统，我们可以单独把系统内的所有静态资源分布到独立的服务器上，然后把对这些资源的URL连接直接指向这个服务器，这样，Web服务器IO   上的压力一下子能减轻很多

  说到静态资源还需要注意一点，如果你正在使用URL重写的话，记得把图片单独放在一个虚拟目录下，否则URL重写模块会对图片请求进行处理，系统    性能将大大降低

4.其他优化

  状态机制：不要把大量的数据存放在Session等状态对象中，Session是每个用户独立的，假设一个用户占用100K的数据，10000个用户在线将占用1G的服务器内存。Session有三种模式，其中InProc的模式是最快的(存储在内存中而且不需要序列化和反序列化操作)

 <-----------------配置与部署性能优化---------------->

1.网站部署

  发布前禁用调试，否则应用程序性能会受到很大的影响

  避免将错误定向页设置为同一个网站的某一个页面，因为在网站过于繁忙导致没有足够的处理线程的时候会发生异常，这个时候再把错误页设置为本网  站的某个页面将会导致恶性循环，设置为其他网站的错误页面能解决这个问题    

2.网站部署

  预编译：能避免首次访问网站编译带来的性能损失，使用IDE的发布操作能很方便地进行预编译
  HTTP压缩：在IIS中配置HTTP压缩能减少30%的网络流量，对于CPU占用不高而网络带宽有限的网站来说，可以采用压缩来减少页面加载时间