asp.net数据优化方法

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

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

 2. 字符串操作性能优化　
　
使用值类型的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); //显示操作结果3. 优化 Web 服务器计算机和特定应用程序的配置文件以符合您的特定需要

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

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

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

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

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

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

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

请求管线内的所有模块在每次请求中都有机会被运行。因此，当请求进入和离开模块时快速地触发代码至关重要，特别是在不使用模块功能的代码路径里。分别在使用及不使用模块和配置文件时执行吞吐量测试，对确定这些方法的执行速度非常有用。

14. 使用 HttpServerUtility.Transfer 方法在同一应用程序的页面间重定向　　

采用 Server.Transfer 语法，在页面中使用该方法可避免不必要的客户端重定向。
　　
15. 必要时调整应用程序每个辅助进程的线程数　　

ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与 ASP.NET Applications 性能对象关联的 Pipeline Instance Count 性能计数器，可以在 PerfMon 中监视线程门控。当页面调用外部资源，如数据库访问或 XML Web services 请求时，页面请求通常停止并释放 CPU。如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么这个正在等待的请求将开始被处理。遗憾的是，有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。通常，如果门控因子是外部资源的响应时间，则让过多请求等待资源，对 Web 服务器的吞吐量并无帮助。为缓和这种情况，可以通过更改 Machine.config 配置文件节点的 maxWorkerThreads 和 maxIOThreads 属性，手动设置进程中的线程数限制。 　　

注意：辅助线程是用来处理 ASP.NET 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有四个或八个 CPU 的计算机，最好更改默认值。对于有一个或两个处理器的计算机，默认值就可以，但对于有更多处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。注意进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系统将 CPU 周期花在维护线程而不是处理请求上。