那性能问题到底该如何解决？以下是应用系统发布前，作为 .NET 开发人员需要检查的点。

1. 减少网页中HTTP请求：

A、将多个图片合并为一个文件，利用css背景图片的偏移技术呈现，避免多个图片的下载；

B、合并JS脚本或者CSS样式表；

C、充分利用HTTP中的浏览器cache策略，减少重复下载；

2.缓存

缓存是一种用空间换取时间的技术，通俗点也就是说把你得到的数据存放在内存中一段时间，在这短时间内服务器不去读取数据库、或是真实的数据源，而是读取你存放在内存中的数据。 缓存是网站性能优化不可缺少的一种数据处理机制，他能有效的缓解数据库压力。 ASP.NET 中的缓存主要分为：

A、动态内存缓存 （~ _ ~）

缓存目的就是把需要花费昂贵开销的计算结果保存起来，缩短了请求响应时间并提高了服务器吞吐率。

缓存命中率，如果每次都能在缓存中找到需要的数据，则是最理想的结果。

否则，cache变得毫无意义，并且还由于cache的管理逻辑增加了新开销。

页面缓存：缓存内容实际上就是动态网页输出的html。

缓存过期时间（即绝对，具体一个时间点）和缓存有效期长度（即一个时间长度，滑动）；这两种机制将缓存数据存储在磁盘文件中。

但是也可以保存在内存中。

每次请求送到动态程序，动态程序判断是否缓存，会消耗性能。如果静态化页面的话，就会提高响应速度。但是手动维护一个站点就很麻烦。这时动态内容缓存的一部分优越性便提现这一点。

在实际应用中，动态内容缓存可能是使用得最多的技术，但是并不见得所有的动态内容都适合使用网页缓存，缓存带来的性能提升恰恰与有些动态数据实时交互的需求形成矛盾，这就是一个权衡。

1. 缓存动态生成的html代码。

2. 把动态内容静态化，直接缓存整个html文件。这样就可以直接访问缓存。这时的更新策略：

1>在数据更新时重新生成静态化内容 2>定时重新生成静态化内容

3. 使用SSI（server side include）进行局部静态化。但web server的SSI功能会对静态文件的吞吐率有负面影响。

B、浏览器缓存

减少http请求，充分利用浏览器的缓存。而webapp通过http协议（更具体位置就是http header）来与浏览器协商，那些东东浏览器可以使用其缓存即可。

1. Last-Modified/If-Modified-Since

2. ETag/If-None-Match

3.Expires + Cache-Control: max-age=

1和2需要浏览器和webserver交互后，有服务器端通知浏览器是否使用浏览器缓存，而3则是在过期前直接使用浏览器缓存，这样就直接kill掉了http request。同时还需注意，在使用SSI的内容中，由于整个页面是服务器动态生成的，所以Last-Modified标记在不同的Web服务器中有不同的生成方法。

C、Web服务器缓存

这个第二点动态内存缓存有区别，前者更指缓存是否命中与否完全由应用程序决定，且缓存方式也有应用来决定；而后者更指有web服务器通过URL决定是否缓存命中，比如静态内容或者更新不太频繁的动态内容就比较时候由其缓存。

D、反向代理缓存

Web服务器隐藏在代理服务器之后。这种代理机制称为反向代理（Reverse proxy），同时，实现这种机制的服务器便成为反向代理服务器。隐藏在反向代理服务器之后的Web服务器，我们习惯称它为后端服务器（Back-end server），当然，反向代理服务器就被称为前端服务器(Front-end server)。

引入反向代理服务器的目的之一就是基于缓存的加速。我们可以将内容缓存在反向代理服务器上，所有缓存机制的实现仍然采用HTTP/1.1协议。

E、分布式缓存

使用分布式缓存避免应用服务器的内存缓存瓶颈，使其更易于扩展。当使用多台应用服务器时，分布式缓存易于内容共享。

3.数据库性能优化（泛泛而谈）

1.合理的执行计划，包括合理使用索引

2.使用慢查询分析工具，找出执行很慢的sql并优化之。

3.合理的数据库缓存，索引缓存，数据缓存等

4.更具实际需求选择合理的数据库引擎或数据库

5.反范式化设计，对查询带来优化，但增加写和更新的工作量。

6.放弃关系型数据库，针对实际情况，读写要求极高时 数据库扩展： 读写分离，按业务实施合理的垂直分区，对热点表进行水平分区。

4.使用发布版本部署应用

部署应用程序到生产环境时，要确保使用的发布版本模式，而不是调试模式。如果使用调试模板极容易发生请求超时。部署成发布版本，你将会发现速度有很大的提升。

5.避免使用 Response.Redirect

Redirect(重定向)非常麻烦，它仅用于用于从当前物理服务器开发跳转到其它服务器。如果只是在本服务器开发内页面跳转请使用 Server.Transfer 语法，这样会减少很多没有必要的客户端重定向。

6.运用 StringBuilder 类以及使用 ToString()方法

String 类对象是不可改变的，对于 String 对象的重新赋值在本质上是重新创建了一个 String 对象并将新值赋予该对象，其方法 ToString 对性能的提高并非很显著。在处理字符串时，最好使用 StringBuilder 类，其 .NET 命名空间是 System.Text。该类并非创建新的对象，而是通过 Append，Remove，Insert 等方法直接对字符串进行操作，通过 ToString 方法返回操作结果。 其定义及操作语句如下所示

int num; System.Text.StringBuilder str = new System.Text.StringBuilder(); //创建字符串 str.Append(num.ToString()); //添加数值num Response.Write(str.ToString); //显示操作结果

7.避免抛出异常

异常会导致速度变慢，并且使得应用程序页面显示异常，使得无法进行其他操作。可以使用 try / catch 使出现的异常记录到日志文件中。

8.使用 finally 方法回收资源

假如你在应用开发中大量使用其他数据库连接和访问文件，请确定在用完后关闭它们。finally 块是程序中最后被执行，因此在这里面的代码会确保一定会被执行，关闭代码一定要在这个开发方法块中执行。

10.使用客户端脚本验证

用客户端验证代替服务器开发端验证。服务器开发端数据验证将会大量消耗您的服务器开发上的资源，并且会代来大量的页面数据回传。

9.GC垃圾回收

GC如其名，就是垃圾收集，当然这里仅就内存而言。Garbage Collector 垃圾收集器，针对托管代码，以应用程序为基础，遍历应用程序在Heap上动态分配的所有对象[，通过识别它们是否被引用来确定哪些对象是已经死亡的、哪些仍需要被使用。已经不再被应用程序的对象所引用的对象就是已经死亡的对象，即所谓的垃圾，需要被回收，这就是GC工作的原理。

非托管代码不能享受一些运行库所提供的服务，例如安全和内存管理等。如果非托管代码需要进行内存管理等服务，就必须显式地调用操作系统的接口，通常来说，它们会调用Windows SDK所提供的API来实现。就最近的情况来看，非托管程序会通过COM接口来获取操作系统服务。跟Visual Studio平台的其他编程语言不一样，Visual C++可以创建非托管程序。当你创建一个项目，并且选择名字以MFC，ATL或者Win32开头的项目类型，那么这个项目所产生的就是非托管程序。总而言之，非托管代码是运行在公共语言运行库环境(CLR)的外部，由操作系统直接执行的代码。非托管代码必须提供自己的垃圾回收、类型检查、安全支持等服务；它与托管代码不同，后者从公共语言运行库中获得这些服务。.Net非托管代码，比如数据库连接，使用后要自己释放资源，不然也会造成不正确释放的一些问题。

（C++是自己管理内存，每new一个对象，就要在使用完之后delete对象，不然会造成内存泄漏）

既然.Net托管代码是GC自动管理内存，那么，我们对GC的利用就是要让运行后代码引用的那段内存，成为满足垃圾回收的对象，成为内存垃圾，才能让内存尽快地被系统自动回收掉，为正在运行的程序腾出更多的可用内存空间。

10.及时清空内存数据

内存中的List大对象用完后在保证数据正确的情况下，清空List,再把List指向NULL，可直接减少大内存占用时间、加快内存回收

11.避免递归函数/嵌套循环

在任何编程语言中都需避免嵌套循环和递归函数，以提高性能。

12.调用多个操作时，请使用多线程

问题出现时，单线程卡在此问题上长时间运行。因此，可以使用多个线程以提高应用程序的响应速度。

13.将 SqlDataReader 类用于快速只进数据游标

SqlDataReader 类提供了一种读取从 SQL Server 数据库检索的只进数据流的方法。如果当创建 ASP.NET 应用程序时出现允许您使用它的情况，则 SqlDataReader 类提供比 DataSet 类更高的性能。情况之所以这样，是因为 SqlDataReader 使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。另外，SqlDataReader 类实现 IEnumerable 接口，该接口也允许您将数据绑定到服务器控件。有关更多信息，请参见 SqlDataReader 类。有关 ASP.NET 如何访问数据的信息，请参见通过 ASP.NET 访问数据。

14.做负载均衡和服务器加成

负载均衡不应该仅仅被看作是实现可扩展性的一种手段。尽管它肯定提高了可扩展性，很多时候它增加了 Web 应用程序的性能，因为请求和用户都散发着多个服务器。

结论： 以上是一些性能调整的提示。性能调优不是一天两天的工作，而是一个反反复复的过程。对于网站开发人员来说，在编写 ASP.NET 应用程序时注意性能问题，养成良好的习惯，提高应用程序性能，至少可以推迟必需的硬件升级，降低网站的成本。