提升网站性能的方法 (提升网站性能的ASP空间优化技巧)

提升网站性能是现代网站开发中至关重要的一个方面。随着互联网的普及和用户对网站响应速度的要求越来越高，优化网站性能成为了网站管理员和开发者的重要任务。在提升网站性能的过程中，ASP空间优化技巧是一项非常有效的工具，可以显著提升网站的加载速度和响应性能。

ASP空间优化技巧主要包括以下几个方面：

1. 压缩和缓存静态资源

静态资源包括CSS、JavaScript和图像等文件，在网站的性能优化中起着至关重要的作用。通过压缩和缓存这些静态资源，可以减小文件的大小，并减少对服务器的请求次数，从而提升网站的加载速度。压缩静态资源可以使用一些压缩工具，如Gzip，而缓存则可以通过设置HTTP头信息来实现。

2. 减少数据库操作

数据库操作是网站开发中常见的性能瓶颈之一。过多的数据库查询和更新会导致数据库的负载加大，从而影响网站的响应速度。为了减少数据库操作，可以采取一些优化措施，比如合并多个查询为一个，使用缓存技术减少对数据库的频繁访问。

3. 使用CDN加速

内容分发网络（CDN）是一种将网站内容分发到全球各地的服务器上的技术，通过就近访问的原则，加速网站内容的传输和加载速度。通过将静态资源存储在CDN服务器上，可以减小对原始服务器的请求压力，提升网站的访问速度和性能。

4. 使用缓存技术

缓存技术是一种将常用的网页内容存储在客户端或服务器上的技术，以提升网站的访问速度和响应性能。常见的缓存技术有浏览器缓存和服务器缓存。通过设置适当的缓存策略，可以减少对服务器的请求次数，加快网站的加载速度。

5. 优化图片和多媒体资源

图片和多媒体资源是网站中常见的占用带宽和加载时间的元素。优化图片和多媒体资源可以通过减小文件大小、选择适当的格式、使用懒加载等方式来实现。还可以使用CSS Sprites来减少图片的请求次数，从而提升网站的性能。

以上是ASP空间优化技巧的一些常见方法。通过合理地应用这些技巧，可以大大提升网站的性能，为用户提供更好的访问体验。在实际操作中，可以根据网站的具体情况选择合适的优化方法，并进行不断地测试和调整，以达到最佳的性能优化效果。

---

怎样优化ASP网站程序

ASP 本身并不是一种脚本语言，它只是提供了一种使镶嵌在 HTML 页面中的脚本程序得以运行的环境，而在ASP中最常用的脚本语言就是VBScript了。

虽然ASP的脚本语言很简单，但是要想让一个ASP程序能够最优化的运行也不是一件简单的事情。

现在国内的网络带宽很有限，网络十分拥挤，如何使得自己的ASP应用程序能够快速的运行就成为了每一个ASP程序员的梦想了。

那就跟随我来一同加速你的ASP程序吧！一． 有关操作数据库的优化方法我们使用ASP最主要的用途就是对数据库进行操作了，如何更快速的完成这些动作呢？1． 不要任意使用“SELECT*……”请尽量拾取你所需要的那些字段，比如，一个Table中有10个字段，但是你只会用到其中的一个字段（name），就要使用“select name from yourtable”，而不是用“select * from yourtable”。

你或许会说，我是这么做的阿，但是，如果一个table中有50个字段，你需要用到其中的23个字段的时候，你会怎么做呢？为了节省打字以及查找对应字段名称的麻烦，你就不一定会老老实实的用“select name，sex，age… from yourtable”了吧！实际证明，尽量拾取你所需要的那些字段来使用select语句将会是你的ASP程序至少加快5%左右。

2． 尽可能使用系统存储过程（针对MS SQL Server）有的时候完成一个读取操作，使用SQL语句和存储过程同样可以完成，但是使用存储过程将会大大加快完成读取操作的速度，也就提高了你的ASP程序运行的速度。

3． 注意你的游标使用方法如果你仅仅是对一个table进行读取操作，那么请你使用forward-only，read-only游标，因为这种游标读取数据库是最为快速的，尤其是你的读取数据量很大的情况下。

4． 不要打开无用的独立记录集也许你在笑了，我会打开没有用的记录集吗？是的，你当然会，比如在生成一个树型记录集的时候，你不得不打开父记录集以及对应的子记录集，甚至还有孙记录集，其实你可以使用ADO提供的Data Shaping技术来替代打开多个独立的记录集，那样会加快程序的运行速度。

（关于Data Shaping的用法可以参考ADO帮助）

ASP.NET如何进行性能优化问题

一 SqlDataRead和Dataset的选择

Sqldataread优点 读取数据非常快 如果对返回的数据不需做大量处理的情况下 建议使用SqlDataReader 其性能要比datset好很多 缺点 直到数据读完才可close掉于数据库的连接

(SqlDataReader 读数据是快速向前的 SqlDataReader 类提供了一种读取从 SQL Server 数据库检索的只进数据流的方法 它使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据 DataReader需及时显式的close 可及时的释放对数据的连接 )

Dataset是把数据读出 缓存在内存中 缺点 对内存的占用较高 如果对返回的数据需做大量的处理用Dataset比较好些可以减少对数据库的连接操作 优点 只需连接一次就可close于数据库的连接

*一般情况下 读取大量数据 对返回数据不做大量处理用SqlDataReader 对返回数据大量处理用datset比较合适 对SqlDataReader和Dataset的选择取决于程序功能的实现

二 ExecuteNonQuery和ExecuteScalar

对数据的更新不需要返回结果集 建议使用ExecuteNonQuery 由于不返回结果集可省掉网络数据传输 它仅仅返回受影响的行数 如果只需更新数据用ExecuteNonQuery性能的开销比较小

ExecuteScalar它只返回结果集中第一行的第一列 使用 ExecuteScalar 方法从数据库中检索单个值(例如id号) 与使用 ExecuteReader 方法 返回的数据执行生成单个值所需的操作相比 此操作需要的代码较少

*只需更新数据用ExecuteNonQuery 单个值的查询使用ExecuteScalar数据绑定的选择

三 数据的绑定DataBinder

一般的绑定方法用DataBinder eval 绑定不必关心数据来源(Dataread或dataset) 不必关心数据的类型eval会把这个数据对象转换为一个字符串 在底层绑定做了很多工作 使用了反射性能 正因为使用方便了 但却影响了数据性能 来看下 当于dataset绑定时 DataItem其实式一个DataRowView(如果绑定的是一个数据读取器(dataread)它就是一个IdataRecord )因此直接转换成DataRowView的话 将会给性能带来很大提升

*对数据的绑定建议使用 数据量大的时候可提高几百倍的速度 使用时注意 方面 需在页面添加 注意字段名的大小写(要特别注意) 如果和查询的不一致 在某些情况下会导致比还要慢 如果想进一步提高速度 可采用的方法 不过其可读性不高

以上的是的写法 在c#中 <@% ((DataRowView)Container DataItem)[ 字段名 ] %>

对查看页面每个执行过程状态最简单的办法 其页面的trace属性为true就可查看细节

一 使用存储过程

性能方面 存储过程提供了许多标准sql语言中所没有的高级特性 其传递参数和执行逻辑表达式的功能 有助于应用程序设计者处理复杂任务 另外 存储过程存储在本地服务器上 减少了执行该过程所需的网络传输宽带和执行时间 (存储过程已经对sql语句进行了预编译 所以其执行速度比在程序里执行sql语句快很多)

程序结构方面 从程序的可扩展性看 使用存储过程会对程序以后的修改带来方便 比如数据库的结构改变了 只需修改相对应的存储结构 和程序中的调用部分即可 这部分不属于本文探讨范围 属于程序结构设计方面 所以不在此展开

程序安全性 使用存储过程可避免SQL Injection攻击

二 查询语句的优化(针对sql server )

很多人只为目的写出sql语句 而不考虑sql语句的执行效率 在这我只提供一优化表顺序的方法 (sql语句的优化和原则将会在我的sql server 学习笔记中专题讨论)

对sql语句执行效率可用sql server 的查询分析器来查看语句的执行过程

优化表顺序 一般情况下 sqlserver 会对表的连接作出自动优化 例如 select name no from A join B on A id=B id join C on C id=A id where name= wang

尽管A表在From中先列出 然后才是B 最后才是C 但sql server可能会首先使用c表 它的选择原则是相对于该查询限制为单行或少数几行 就可以减少在其他表中查找的总数据量 绝大多数情况下 sql server 会作出最优的选择 但如果你发觉某个复杂的联结查询速度比预计的要慢 就可以使用SET FORCEPLAN语句强制sql server按照表出现顺序使用表 如上例加上 SET FORCEPLAN ON…… SET FORCEPLAN OFF 表的执行顺序将会按照你所写的顺序执行 在查询分析器中查看 种执行效率 从而选择表的连接顺序

使用SET FORCEPLAN选择表联结顺序

三 页面的优化( aspx)

主要针对几个页面属性

EnableViewState(页面的视图状态) 如果无特殊要求设置为false 使用ViewState 每个对象都必须先序列化到 ViewState 中 然后再通过回传进行反序列化 因此使用 ViewState是没有代价的 尽量减少使用对象 如果可能 尽量减少放入 ViewState 中的对象的数目 下面情况基本上可以禁用viewstate

( )页面控件 ( ascx)

( )页面不回传给自身

( )无需对控件的事件处理

( )控件没有动态的或数据绑定的属性值(或对于每个postpack都在代码中处理)

单个页面或每个页面都禁用 ViewState 如下所示 单个页面 每个页面 在 nfig 中 EnableSessionState保持默认值即可(如果页面用到sessionstate它才会占用资源) EnableViewStateMac如果无安全上的特殊要求 保持默认值

Pagelayout 页面布局模型 建议使用Flowlayout(元素不带绝对定位属性添加)

Gridlayout(绝对定位属性)由于采用绝对定位 将会比Flowlayout生产更多的代码 主要是控件的定位信息

项目发布的时候切记解除页面的Debug状态

Html语言的优化 我的建议是熟练掌握Html/javascript 少用 自动生产的代码 它会自动生成一些无用的代码

*** art navigation设置为true能让用户明显的感觉性能提高 启用此属性后对客户端和服务端影响不大 它能智能涮新需要涮新需涮新的部分

四 控件的选择

Html控件和服务器控件的选择 服务器控件带来的方便和功能上的实现是控件所不能比拟的 但是是以牺牲服务器端的资源来取得的 我个人建议 如果控件达不到所要实现的功能 而且和一些脚本语言(如javascrpt/vbscript)结合也不能实现的话 才会选择服务器控件 选择服务器控件后 也尽量对其控件优化 如取消一些页面状态等(具体看控件的优化)

服务器控件的选择 主要针对几个常用数据控件说明一下

DataGrid 自带最强大的数据显示控件 内置了对数据的修改 删除 添加 分页等很多实用功能 如果你只需对数据显示的话 尽量不要选择DataGrid(它把数据都存储在viewstate中) 也不要使用自带的分页功能 microsoft在自动分页的底层做了很多工作 虽然使用方便了 但性能开销大了

DataList 比DataGrid功能少了很多 但自定义性强了很多 特有的多行数据显示 给我们带来了很多方便 DataGrid能实现的功能 它基本能实现 所以建议使用它

Repeater 功能最少 但自定义性非常强 如果只需对数据显示 建议使用 由于减少了很多功能 对服务器的性能带来消耗最小 因此 如果是对数据显示的话 我基本上都是选择Repeater然后DataList最后DataGrid

尽量选择控件 能在客户端实现的功能就在客户端实现(熟练掌握javascript) 减少服务器的压力 数据控件选择顺序 Repeater DataList DataGrid

五 服务器控件的优化

Viewstate

控件的viewstate与页面的viewstate基本是一致的 用来保存控件的一些状态 处理原则和处理页面的viewstate一样 有兴趣的可以用Datagrid绑定数据测试下viewstate保存的数据量有多大 它所保存的数据基本和Datagrid显示的数据量大小是等同的

Ispostpack

默认false 需要产生事件的时候才需设置为true

控件的优化 主要看你对此控件的熟悉情况

对控件内部运作的原理越了解 就会对其作出合适的优化

lishixinzhi/Article/program/net/201311/13552

.Net课堂:ASP.NET常用的优化性能方法

数据库访问性能优化

数据库的连接和关闭

访问数据库资源需要创建连接 打开连接和关闭连接几个操作 这些过程需要多次与数据库交换信息以通过身份验证 比较耗费服务器资源 ASP NET中提供了连接池（Connection Pool）改善打开和关闭数据库对性能的影响 系统将用户的数据库连接放在连接池中 需要时取出 关闭时收回连接 等待下一次的连接请求 连接池的大小是有限的 如果在连接池达到最大限度后仍要求创建连接 必然大大影响性能 因此 在建立数据库连接后只有在真正需要操作时才打开连接 使用完毕后马上关闭 从而尽量减少数据库连接打开的时间 避免出现超出连接限制的情况

使用存储过程

存储过程是存储在服务器上的一组预编译的SQL语句 类似于DOS系统中的批处理文件 存储过程具有对数据库立即访问的功能 信息处理极为迅速 使用存储过程可以避免对命令的多次编译 在执行一次后其执行规划就驻留在高速缓存中 以后需要时只需直接调用缓存中的二进制代码即可 另外 存储过程在服务器端运行 独立于ASP NET程序 便于修改 最重要的是它可以减少数据库操作语句在网络中的传输

优化查询语句

ASP NET中ADO连接消耗的资源相当大 SQL语句运行的时间越长 占用系统资源的时间也越长 因此 尽量使用优化过的SQL语句以减少执行时间 比如 不在查询语句中包含子查询语句 充分利用索引等

字符串操作性能优化

使用值类型的ToString方法

在连接字符串时 经常使用 + 号直接将数字添加到字符串中 这种方法虽然简单 也可以得到正确结果 但是由于涉及到不同的数据类型 数字需要通过装箱操作转化为引用类型才可以添加到字符串中 但是装箱操作对性能影响较大 因为在进行这类处理时 将在托管堆中分配一个新的对象 原有的值复制到新创建的对象中 使用值类型的ToString方法可以避免装箱操作 从而提高应用程序性能

运用StringBuilder类

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） //显示操作结果

优化 Web 服务器计算机和特定应用程序的配置文件以符合您的特定需要

默认情况下 ASP NET 配置被设置成启用最广泛的功能并尽量适应最常见的方案 因此 应用程序开发人员可以根据应用程序所使用的功能 优化和更改其中的某些配置 以提高应用程序的性能 下面的列表是您应该考虑的一些选项

仅对需要的应用程序启用身份验证

默认情况下 身份验证模式为 Windows 或集成 NTLM 大多数情况下 对于需要身份验证的应用程序 最好在 nfig 文件中禁用身份验证 并在 nfig 文件中启用身份验证 根据适当的请求和响应编码设置来配置应用程序 ASP NET 默认编码格式为 UTF 如果您的应用程序为严格的 ASCII 请配置应用程序使用 ASCII 以获得稍许的性能提高

考虑对应用程序禁用 AutoEventWireup

在 nfig 文件中将 AutoEventWireup 属性设置为 false 意味着页面不将方法名与事件进行匹配和将两者挂钩（例如 Page_Load） 如果页面开发人员要使用这些事件 需要在基类中重写这些方法（例如 需要为页面加载事件重写 Page OnLoad 而不是使用 Page_Load 方法） 如果禁用 AutoEventWireup 页面将通过将事件连接留给页面作者而不是自动执行它 获得稍许的性能提升

从请求处理管线中移除不用的模块

默认情况下 服务器计算机的 nfig 文件中 节点的所有功能均保留为激活 根据应用程序所使用的功能 您可以从请求管线中移除不用的模块以获得稍许的性能提升 检查每个模块及其功能 并按您的需要自定义它 例如 如果您在应用程序中不使用会话状态和输出缓存 则可以从 列表中移除它们 以便请求在不执行其他有意义的处理时 不必执行每个模块的进入和离开代码

一定要禁用调试模式

在部署生产应用程序或进行任何性能测量之前 始终记住禁用调试模式 如果启用了调试模式 应用程序的性能可能受到非常大的影响

对于广泛依赖外部资源的应用程序 请考虑在多处理器计算机上启用网络园艺

ASP NET 进程模型帮助启用多处理器计算机上的可缩放性 将工作分发给多个进程（每个CPU一个） 并且每个进程都将处理器关系设置为其 CPU 此技术称为网络园艺 如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的 对象（这里只是提及两种可能性） 则为您的应用程序启用网络园艺是有益的 但是 在决定启用网络园艺之前 您应该测试应用程序在网络园中的执行情况

只要可能 就缓存数据和页输出

ASP NET 提供了一些简单的机制 它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据 另外 通过设计要进行缓存的页和数据请求（特别是在站点中预期将有较大通讯量的区域） 可以优化这些页的性能 与 NET Framework 的任何 Web 窗体功能相比 适当地使用缓存可以更好的提高站点的性能 有时这种提高是超数量级的 使用 ASP NET 缓存机制有两点需要注意 首先 不要缓存太多项 缓存每个项均有开销 特别是在内存使用方面 不要缓存容易重新计算和很少使用的项 其次 给缓存的项分配的有效期不要太短 很快到期的项会导致缓存中不必要的周转 并且经常导致更多的代码清除和垃圾回收工作 若关心此问题 请监视与 ASP NET Applications 性能对象关联的 Cache Total Turnover Rate 性能计数器 高周转率可能说明存在问题 特别是当项在到期前被移除时 这也称作内存压力

选择适合页面或应用程序的数据查看机制

根据您选择在 Web 窗体页显示数据的方式 在便利和性能之间常常存在着重要的权衡 例如 DataGrid Web 服务器控件可能是一种显示数据的方便快捷的方法 但就性能而言它的开销常常是最大的 在某些简单的情况下 您通过生成适当的 HTML 自己呈现数据可能很有效 但是自定义和浏览器定向会很快抵销所获得的额外功效 Repeater Web 服务器控件是便利和性能的折衷 它高效 可自定义且可编程

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

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

将 SQL Server 存储过程用于数据访问

在 NET Framework 提供的所有数据访问方法中 基于 SQL Server 的数据访问是生成高性能 可缩放 Web 应用程序的推荐选择 使用托管 SQL Server 提供程序时 可通过使用编译的存储过程而不是特殊查询获得额外的性能提高

避免单线程单元 （STA） 组件

默认情况下 ASP NET 不允许任何 STA 组件在页面内运行 若要运行它们 必须在 aspx 文件内将 ASPCompat=true 属性包含在 @ Page 指令中 这样就将执行用的线程池切换到 STA 线程池 而且使 HttpContext 和其他内置对象可用于 对象 前者也是一种性能优化 因为它避免了将多线程单元 （MTA） 封送到 STA 线程的任何调用 使用 STA 组件可能大大损害性能 应尽量避免 若必须使用 STA 组件 如在任何 interop 方案中 则应在执行期间进行大量调用并在每次调用期间发送尽可能多的信息 另外 小心不要在构造页面期间创建任何 STA 组件 例如下面的代码中 在页面构造时将实例化由某个线程创建的 MySTAComponent 而该线程并不是将运行页面的 STA 线程 这可能对性能有不利影响 因为要构造页面就必须完成 MTA 和 STA 线程之间的封送处理

＜%@ Page Language= VB ASPCompat= true %＞

＜script runat=server＞

Dim myComp as new MySTAComponent()

Public Sub Page_Load()

myComp Name = Bob

End Sub

＜/script＞

Response Write(myComp SayHello)

%＞Response Write(myComp SayHello)

＜/＞ 首选机制是推迟对象的创建 直到以后在 STA 线程下执行上述代码 如下面的例子所示＜%@ Page Language= VB ASPCompat= true %＞

＜script runat=server＞

Dim myComp

Public Sub Page_Load()

myComp = new MySTAComponent()

myComp Name = Bob

End Sub

＜/script＞

Response Write(myComp SayHello)

%＞Response Write(myComp SayHello)

＜/＞ 推荐的做法是在需要时或者在 Page_Load 方法中构造任何 组件和外部资源 永远不要将任何 STA 组件存储在可以由构造它的线程以外的其他线程访问的共享资源里 这类资源包括像缓存和会话状态这样的资源 即使 STA 线程调用 STA 组件 也只有构造此 STA 组件的线程能够实际为该调用服务 而这要求封送处理对创建者线程的调用 此封送处理可能产生重大的性能损失和可伸缩性问题 在这种情况下 请研究一下使 组件成为 MTA 组件的可能性 或者更好的办法是迁移代码以使对象成为托管对象

将调用密集型的 组件迁移到托管代码

NET Framework 提供了一个简单的方法与传统的 组件进行交互 其优点是可以在保留现有投资的同时利用新的平台 但是在某些情况下 保留旧组件的性能开销使得将组件迁移到托管代码是值得的 每一情况都是不一样的 决定是否需要迁移组件的最好方法是对 Web 站点运行性能测量 建议您研究一下如何将需要大量调用以进行交互的任何 组件迁移到托管代码 许多情况下不可能将旧式组件迁移到托管代码 特别是在最初迁移 Web 应用程序时 在这种情况下 最大的性能障碍之一是将数据从非托管环境封送到托管环境 因此 在交互操作中 请在任何一端执行尽可能多的任务 然后进行一个大调用而不是一系列小调用 例如 公共语言运行库中的所有字符串都是 Unicode 的 所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式 另外 一处理完任何 对象或本机资源就释放它们 这样 其他请求就能够使用它们 并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题

在 Visual Basic NET 或 JScript 代码中使用早期绑定

以往 开发人员喜欢使用 Visual Basic VBScript 和 JScript 的原因之一就是它们所谓 无类型 的性质 变量不需要显式类型声明 并能够简单地通过使用来创建它们 当从一个类型到另一个类型进行分配时 转换将自动执行 不过 这种便利会大大损害应用程序的性能 Visual Basic 现在通过使用 Option Strict 编译器指令来支持类型安全编程 为了向后兼容 默认情况下 ASP NET 不启用该选项 但是 为了得到最佳性能 强烈建议在页中启用该选项 若要启用 Option Strict 请将 Strict 属性包括在 @ Page 指令中 或者 对于用户控件 请将该属性包括在 @ Control 指令中 下面的示例演示了如何设置该属性 并进行了四个变量调用以显示使用该属性是如何导致编译器错误的

＜%@ Page Language= VB Strict= true %＞

Dim B

Dim C As String

This will cause a piler error

A = Hello

This will cause a piler error

B = World

This will not cause a piler error

C = !!!!!!

But this will cause a piler error

C =

%＞Dim B

Dim C As String

This will cause a piler error

A = Hello

This will cause a piler error

B = World

This will not cause a piler error

C = !!!!!!

But this will cause a piler error

C =

%> JScript NET 也支持无类型编程 但它不提供强制早期绑定的编译器指令 若发生下面任何一种情况 则变量是晚期绑定的 被显式声明为 Object 是无类型声明的类的字段 是无显式类型声明的专用函数或方法成员 并且无法从其使用推断出类型　最后一个差别比较复杂 因为如果 JScript NET 编译器可以根据变量的使用情况推断出类型 它就会进行优化 在下面的示例中 变量 A 是早期绑定的 但变量 B 是晚期绑定的

var A

var B

A = Hello

B = World

B = 为了获得最佳的性能 当声明 JScript NET 变量时 请为其分配一个类型 例如 var A String

使请求管线内的所有模块尽可能高效

lishixinzhi/Article/program/net/201311/11750

如何提高网页运行性能

从编码方面一、 缓存缓存是ASP.NET中提高性能的重要手段，缓存一般遵循以下原则：1）在页面中将静态内容与动态内容分割开来考虑将动态内容作成用户控件2）缓存合理的数据一般应当缓存应用程序集的数据、多个用户共同使用的数据、静态数据、生成数据需要很大开销的动态数据、DataSet以及自定义对象等。

不要缓存数据库连接对象、DataReader。

3）选择适当的方式如可以使用页面缓存指令，API等。

二、 视图状态视图状态放在页面中名为_VIEWSTATE的表单隐藏域里面，随页面一起被发送到客户端，在用户提交页面时，又被提交到服务器。

1）如果不需要视图状态，则禁用视图状态默认是允许的，如果页面不进行PostBack，如果不处理服务器控件的事件，如果服务器控件的数据每次都需要重新计算等2）尽量减少视图状态中存放的对象三、 关于页面处理（减少页面生成的时间和过程）1）应尽量减少页面文件的大小2）通过检测Page.IsPostBack减少代码执行的数量3）禁止使用Debug=“true”，减少页面生成过程中生成额外的调试信息4）使用Server.Transfer而不使用Response.Redirect，减少服务器和客户端间的往返5）尽量使用客户端验证，减少服务器和客户端间的往返6）在适当的场合使用服务器控件7）尽量避免嵌套的服务器控件四、 避免使用Page.DataBind和DataBinder.Eval五、 关于Application对象和Session对象1）使用静态属性存储数据而不使用Application对象，在Application对象里存储只读类型的数据都将回提高性能2）尽量使用InProc模式的Session，这个模式是最快的3）在Session里存储基本类型的数据减少序列化的所消耗的资源4）如果不用Session变量，使用EnvableViewState=“false”禁用5）如果不修改Session变量的值，尽量使用ReadOnly属性设置六、 关于字符串操作1）尽量使用Response.Write将结果输出到浏览器，这种方法是最快的。

不要将字符串连接在一起一次输出。

2）在字符串短并且少的情况下可以使用String.Concat方法，而在字符串长度未知，并且字符串大的情况下，使用StringBuilder对象3）不要使用strVar==“”来判断字符串是否为“”，这样它会创建额外的字符串，请使用strVar==String.Empty代替或者使用strVar.Length==0来判断4）请使用String.Compare方法进行字符串的比较七、 关于数据访问1）尽量使用存储过程返回数据，不要直接在代码中进行查询2）在数据库中只返回有用的数据结果，不要选择不使用的数据字段3）进行使用DataReader进行数据绑定，DataReader是单向只读的4）尽量一次返回多个数据集而不是每个记录集分别打开一次数据库连接进行查询5）尽量晚的打开数据库，尽量早的关闭数据库6）使用连接池提高性能7）使用ExecuteNonQuery方法执行不返回数据的操作，使用ExecuteScalar方法返回单个结果的操作，使用CommandBehavior.Sequentialaccess返回二进制数据或者大数据8）如果多次相同的查询，请使用Command.Prepare方法9）使用GetOrdinal方法预先得到索引值，使用索引值比使用字符串的列名查询数据效率更高八、 关于代码优化1）在解析基本数据类型时，使用Try方法如果解析失败，会抛出异常，使用TryParse方法则只执行Else下的语句。

2）使用AppendAllText、WriteAllBytes等方法读写文件内容可以优化性能3）将循环判定条件放在for语句外4）避免在循环里创建对象5）尽量减少装箱的次数6）不要使用例外控制程序的流程7）在循环中不要使用不变的对象属性或者字段8）使用for循环代替foreach循环遍历结合内容9）数组是所有集合中最快的，如果没有特殊需要，尽量使用数组代替集合10）了解各个集合类型的特性，选择合适的类型11）使用泛型避免减少装箱、拆箱大型网站，比如门户网站。

在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。

但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。

上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。

HTML静态化其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。

但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

图片服务器分离大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。

这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。

数据库集群和库表散列大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。

我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。

sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

缓存缓存一词搞技术的都接触过，很多地方用到缓存。

网站架构和网站开发中的缓存也是非常重要。

这里先讲述最基本的两种缓存。

高级和分布式的缓存在后面讲述。

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。

另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。

镜像镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。

在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。

也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

负载均衡负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，其中有两个架构可以参考。

硬件四层交换第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。

第四层交换功能就象是虚 IP，指向物理服务器。

它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。

这些业务在物理服务器基础上，需要复杂的载量平衡算法。

在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。

Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

软件四层交换大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。

但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

这样的架构我准备空了专门详细整理一下和大家探讨。

Internet的规模每一百天就会增长一倍，客户希望获得7天24小时的不间断可用性及较快的系统反应时间，而不愿屡次看到某个站点Server Too Busy及频繁的系统故障。

网络的各个核心部分随着业务量的提高、访问量和数据流量的快速增长，其处理能力和计算强度也相应增大，使得单一设备 根本无法承担。

在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量的需求。

于是，负载均衡机制应运而生。

负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

负载均衡有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。

负载均衡技术主要应用：DNS负载均衡 最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。

DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。

代理服务器负载均衡使用代理服务器，可以将请求转发给内部的服务器，使用这种加速模式显然可以提升静态网页的访问速度。

然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台服务器，从而达到负载均衡的目的。

地址转换网关负载均衡 支持负载均衡的地址转换网关，可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。

协议内部支持负载均衡 除了这三种负载均衡方式之外，有的协议内部支持与负载均衡相关的功能，例如HTTP协议中的重定向能力等，HTTP运行于TCP连接的最高层。

NAT负载均衡 NAT（Network Address Translation 网络地址转换）简单地说就是将一个IP地址转换为另一个IP地址，一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。

适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。

反向代理负载均衡 普通代理方式是代理内部网络用户访问internet上服务器的连接请求，客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。

反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。

混合型负载均衡在有些大型网络，由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异，我们可以考虑给每个服务器群采用最合适的负载均衡方 式，然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务（即把这多个服务器群当做一个新的服务器群），从而达到最佳的性能。

我们将这种方式称之为混合型负载均衡。

此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。

对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。

提高ASP.Net应用程序性能的十大方法[3]

这里没有足够的空间有贴代码 你可以从// rob howard net/中下载示例程序 请下载Blackbelt TechEd 的示例程序

七 页面输出缓存和代理服务

Asp net是你的界面层（或者说应该是） 它包含页面 用户控件 服务器控件（HttpHandlers 和HttpModules）以及它们生成的内容 如果你有一个Asp net页面用来输出 xml imgae或者是其它的数据 对每一个请求你都用代码来生成相同的输出内容 你就很有必要考虑用页面输出缓存了

你只要简单的把下面的这一行代码复制到你的页面中就可以实现了 <%@ PageOutputCache VaryByParams= none Duration= %>

你就可以有效的利用第一次请求里生成的页面输出缓存内容 秒后重新生成一道页面内容 这种技术其实也是运用一些低层的Cache API来实现 用页面输出缓存有几个参数可以配置 如上面所说的VaryByParams参数 该参数表示什么时候触发重输出的条件 也可以指定在Http Get或Http Post 请求模式下缓存输出 例如当我们设置该参数为VaryByParams= Report 的时候 default aspx?Report= 或者default aspx?Report= 请求的输出都会被缓存起来 参数的值可以是多个用分号隔开参数

许多人都没有意识到当用页面输出缓存的时候 asp net也会生成HTTP头集（HTTP Header）保存在下游的缓存服务器中 这些信息可以用于Microsoft Internet安全性中以及加速服务器的响应速度 当HTTP缓存的头被重置时 请求的内容会被缓在网络资源中 当客户端再次请求该内容时 就不会再从源服务器上获得内容了 而直接从缓存中获得内容

虽然用页面输出缓存不提高你的应用程序性能 但是它能减少了从的服务器中加载已缓存页面内容的次数 当然 这仅限于缓存匿名用户可以访问的页面 因为一旦页面被缓存后 就不能再执行授权操作了

八 用IIS 的Kernel Caching

如果你的应用程序没用运行在IIS (windows server )中 那么你就失去了一些很好的提高应用程序性能的方法 在第七个方法中 我讲了用页面输出缓存提高应用程序的性能的方法 在IIS 中 当一个请求到来到IIS后 IIS会把它转给asp net 当应用了页面输出缓存时 ASP NET中的HttpHandler会接到该请求 HttpHandler从缓存中把内容取出来并返回

如果你用的是IIS 它有一个非常好的功能就是Kernel Caching 而且你不必修改asp net程序中任何代码 当asp net接到一个已缓存的请求 IIS的Kernel Cache会从缓存中得到它的一份拷贝 当从网络中传来一个请求的时 Kernel层会得到该请求 如果该请求被缓存起来了 就直接把缓存的数据返回 这样就完工了 这就意味着当你用IIS的Kernel Caching来缓存页面输出时 你将获得不可置信的性能提升 在开发VS NET 的　asp net时有一点 我是专门负asp net性能的程序经理 我的程序员用了这个方法 我看了所有日报表数据 发现用kernel model caching的结果总是最快的 它们的一个共同的特征就是网络的请求和响应量很大 但IIS只占用了 %的CPU资源 这是令人惊奇的 有许多让你使用用IIS 的理由 但kernel cashing是最好的一个

九 用Gzip压缩数据

除非你的CPU占用率太高了 才有必要用提升服务器性能的技巧 用gzip压缩数据的方法可以减少你发送到服务端的数据量 也可以提高页面的运行速度 同时也减少了网络的流量 怎么样更好的压缩数据取决于你要发送的数据 还有就是客户端的浏览器支不支持（IIS把用gzip压缩后的数据发送到客户端 客户端要支持gzip才能解析 IE 和Firefox都支持） 这样你的服务器每秒能多响应一些请求 同样 你也减少了发送响应的数据量 也就能多发送一些请求了

好消息 gzip压缩已经被集成在IIS 中了 它比IIS 中gzip更好 不幸的是 在IIS 中启用gzip压缩 你不能在IIS 的属性对话中设置 IIS开发团队把gzip压缩功能开发出来了 但他们却忘了在管理员窗口中让管理员能很方便的启用它 要启用gzip压缩 你只能深入IIS 的xml配置文件中修改它的配置

除了阅读本文以外 只好再看看Brad Wilson写的<<IIS 压缩>>一文（// dotnetdevs /articles/IIS pression aspx） 另外还有一篇介绍aspx压缩基础知识的文章 Enable ASPX Compression in IIS 但是要注意 在IIS 中动态压缩和kernel cashing是互斥的

十 服务器控件的ViewState

ViewState是asp net中的一个特性 它用于把生成页面要用的一状态值保存在一个隐藏域中 当页面被回传到服务器时 服务器要解析 校验和应用ViewState中的数据以还原页面的控件树 ViewState是一个非常有用的特性 它能持久化客户端的状态而不用cookie或者服务器的内存 大部分的服务器控件都是用ViewState来持久化那些在页面中与用户交互的元素的状态值 例如 用以保存用于分页的当前页的页码

用ViewState会带来一些负面的影响 首先 它加大的服务器的响应和请求的时间 其次 每次回传时都增加了序列化和反序列化数据的时间 最后 它还消耗了服务器更多的内存

许多的服务器控件很趋于使用ViewState 如众所周知的DataGrid 而有时候是没有必须使用的 默认情况下是允许使用ViewState的 如果你不想使用ViewState的话 你可以在控件或页面级别把关闭它 在控件中 你只要把EnableViewState属性设为False就可以了 你也可以在页面中设置 使它的范围扩展到整个页面中 <%@ Page EnableViewState= false %>如果页面无需回传或者每次请求页面只是呈现控件 你就应该在页面级别中把ViewState关掉

总结

我只是提供我几个我认为有助于提高写高性能的asp net应用程序的技巧 本文提到的提高asp net性能的技巧只是一个起步 更多的信息请参考《Improving ASP NET Performance》一书 只有通过自己的实践 你才能找到对你的项目最有帮助的技巧 然而 在你的开发旅程中 这些技巧可以起一些指导性的作用 在软件开发中 这些都不是绝对有用的 因为各个项目都不一样

lishixinzhi/Article/program/net/201311/15287

提高ASP.Net应用程序性能的十大方法[2]

四 ASP NET缓存API

在写应用程序之前 你要做的第一件事是让应用程序最大化的利用ASP NET的缓存功能

如果你的组件是要在Asp net应用程序中运行 你只要把System Web dll引用到你的项目中就可以了 然后用HttpRuntime Cache属性就可访问Cache了（也可以通过Page Cache或HttpContext Cache访问）

有以下几条缓存数据的规则 第一 数据可能会被频繁的被使用 这种数据可以缓存 第二 数据的访问频率非常高 或者一个数据的访问频率不高 但是它的生存周期很长 这样的数据最好也缓存起来 第三是一个常常被忽略的问题 有时候我们缓存了太多数据 通常在一台X 的机子上 如果你要缓存的数据超过 M的话 就会出现内存溢出的错误 所以说缓存是有限的 换名话说 你应该估计缓存集的大小 把缓存集的大小限制在 以内 否则它可能会出问题 在Asp net中 如果缓存过大的话也会报内存溢出错误 特别是如果缓存大的DataSet对象的时候

这里有几个你必须了解的重要的缓存机制 首先是缓存实现了 最近使用 原则（ a least recently used algorithm） 当缓存少的时候 它会自动的强制清除那些无用的缓存 其次 条件依赖 强制清除原则（expiration dependencies） 条件可以是时间 关键字和文件 以时间作为条件是最常用的 在asp net 中增加一更强的条件 就是数据库条件 当数据库中的数据发生变化时 就会强制清除缓存 要更深入的了解数据库条件依赖请看Dino Esposito 在MSDN杂志 年七月刊的Cutting Edge专栏文章 Asp net的缓存架构如下图所示　五 预请求缓存

在前面 我提到过即使我们只对某些地方作了一个小小的性能改进也可以获得大的性能提升 我非常喜欢用预请求缓存来提升程序的性能

虽然Cache API设计成用来保存某段时间的数据 而预请求缓存只是保存某个时期的某个请求的内容 如果某个请求的访问频率高 而且这个请求只需要提取 应用 修改或者更新数据一次 那么就可以预缓存该请求 我们举个例子来说明

在CS的论坛应用程序中 每一个页面的服务器控件都要求得到用于决定它的皮肤（skin）的自定义的数据 以决定用哪个样式表及其它的一些个性化的东西 这里面的某些数据可能要长时间的保存 有些时间则不然 如控件的skin数据 它只需要应用一次 而后就可以一直使用

要实现预请求缓存 用Asp net 的HttpContext类 HttpContext类的实例在每一个请求中创建 在请求期间的任何地方都可以通过HttpContext Current属性访问 HttpContext类有一个Items集合属性 在请求期间所有的对象和数据都被添加到这个集合中缓存起来 和你用Cache缓存访问频率高数据一样 你可以用HttpContext Items缓存那些每个请求都要用到的基础数据 它背后的逻辑很简单 我们向HttpContext Items中添加一个数据 然后再从它里面读出数据

六 后台处理

通过上面的方法你的应用程序应该运行得很快了 是不是？但是在某些时候 程序中的一次请求中可能要执行一个非常耗时的任务 如发送邮件或者是检查提交的数据的正确性等

当我们把asp net Forums 集成在CS中的时侯 发现提交一个新的帖子的时候会非常的慢 每次新增一个帖子的时侯 应用程序首先要检查这个帖子是不是重复提的 然后用 badword 过滤器来过滤 检查图片附加码 作帖子的索引 把它添加到合适的队列中 验证它的附件 最后 发邮件到它的订阅者邮件箱中 显然 这个工作量很大

结果是它把大量的时间都花在做索引和发送邮件中了 做帖子的索引是一项很耗时的操作 而发邮件给订阅都需要连接到SMTP服务 然后给每一个订阅者都发一封邮件 随着订阅用户的增加 发送邮件的时间会更长

索引和发邮件并不需要在每次请求时触发 理想状态下 我们想要批量的处理这些操作 每次只发 封邮件或者每隔 分钟把所有的要发的新邮件发一次 我们决定使用与数据库原型缓存一样的代码 但是失败了 所以又不得不回到VS NET

我们在System Threading命名空间下找到了Timer类 这个类非常有用 但却很少有人知道 Web开发人员则更少有人知道了 一旦他建了该类的实例 每隔一个指定的时间 Timer类就会从线程池中的一个线程中调用指定的回调函数 这意味着你的asp net应用程序可以在没有请求的时候也可以运行 这就是后以处理的解决方案 你就可以让做索引和发邮件工作在后台运行 而不是在每次请求的时候必须执行

后台运行的技术有两个问题 第一是 当你的应用程序域卸载后 Timer类实例就会停止运行了 也就是不会调用回调方法了 另外 因为CLR的每个进程中都有许多的线程在运行 你将很难让Timer获得一个线程来执行它 或者能执行它 但会延时 Asp net层要尽量少的使用这种技术 以减少进程中线程的数量 或者只让请求用一小部分的线程 当然如果你有大量的异步工作的话 那就只能用它了

lishixinzhi/Article/program/net/201311/15286